Session Date/Time: 17 Mar 2026 06:00
Qiufang Ma: Hello, everyone. I think it's time. So it's 2:00 PM. Let's get started. Hello everyone. Good morning, good afternoon, good evening, wherever you are. Thanks for joining us. This is the IETF 125 IVY working group meeting. My name is Qiufang, and my co-chair Daniele is sitting next to me, and our AD Mahesh is sitting in the room as well.
So, this is the Note Well slide. This is actually a set of rules and policies that you are expected to follow when you participate in the IETF. IETF participants are expected to behave in a professional manner and extend our respect and courtesy to our colleagues. And if you are aware of any IETF contributions that is covered by any patents or patent applications that are owned by you or someone else, you have the responsibility to disclose that. So for more details, if you're not really familiar with these, please feel free to take a look at a couple of documents given in this slide. And for advice, please feel free to reach out to chairs or ADs if you like.
So the meeting tips. Please be aware that this session is being recorded. For in-person participants, please make sure to sign into the session via the Datatracker or scanning the QR code in this session so that we can track your presence. And please, we suggest you to use the Meetecho lite client to join the queue and also participate in the show of hands to give a polling result. And please also, if you are use the onsite version, just keep your audio and video off. For remote participants, make sure your audio and video are off unless you are actively speaking. Use a headset is strongly recommended.
The note-taking, please, we need one or two volunteers to help us take notes. Just the discussion needs to be captured. So, please feel free to help.
So our session today will be one hour and a half, and the materials is available. So this is, again, this is a reminder to work remote because we only have three meetings for a year. Most of the time we are working remote. So we remind the working group to make good use of the mailing list. Any working group consensus is determined on the mailing list. And mailing list is used for make the decisions and discussions. You can use it to resolve the open issues of your draft, review, change to other working group documents, and also introduce your new drafts, as well as the discuss the potential new working group items and topics.
So we can arrange virtual interims as needed or periodically. So if you would like to see some topic being discussed, you can make request to working group chairs and we will arrange that as needed. And we could also have the informal working group resources, the working group Webex meeting. Any working group member can make request to chairs and we will arrange that as well. Please be aware that these meetings are completely public and everyone is anyone can join that discussion. The meetings will also be announced on the working group list.
So here is our agenda today. As usual, we don't have a very packed agenda, but we always use the the whole session to discuss this. So after the chairs' presentation, I think Bo, as the leading authors will present the inventory location and the inventory topology work. These are the working group items that we expect could be cross the finish line as soon as possible. And also followed by Aihua to present the the passive network inventory work. This is also, I think it has been discussed for a lot of times, but maybe there is some like the discussion definition or scope that needs to be agreed. So Diego will present the entitlement inventory because Diego is busy with working as the delegate for the other the other session now, so he has requested to be scheduled later. And then I think Italo will give a report on the Hackathon project on the network inventory related implementation.
Any agenda bashing? Okay. The working group status.
Daniele Ceccarelli: Thank you. So this is going to be short. This is an update on the status of our drafts. Most of them will be presented during during our session, so I will not waste your time repeating what you will hear after that. So the first one, the core model, that's that will not be presented today because we are very close to the finish line. The draft has been submitted to the IESG, so we can we can say that we are close to end the work on that. Or better, end the work on the 1.0 version, because we agreed at a certain point that there were more and more and more things to be added. We decided to have a 1.0 version that it will now be delivered to the IESG for publication, and the working group decided to work on a new version to cover the things that have been left out.
Then we have the network inventory topology, which is in agenda. It will be presented, but the draft is pretty stable and it's probably the next one in our in our backlog to be ready for the working group last call and to be shipped to the IESG. The inventory location is on agenda. The inventory software part is not in agenda. I don't know if Bo is willing to give us an update on the status of the draft. Thank you.
Bo Wu: Bo Wu from Huawei. Yes, the software inventory has not been updated since last IETF meeting. And the model and the draft is pretty much mature. The last issue we found out is example, and we another point is that we need to update the reference to the base inventory because something, some attributes has been changed. That's the one. Yes.
Daniele Ceccarelli: Okay, cool. Thanks a lot. And then finally, we have the entitlement inventory, which is in agenda and Diego will present later today. We don't have any liaison, nor incoming nor outgoing since since last meeting. So that's it for for the intro. We can move to the first presenter. You show the slides? I can do that. No worries, no worries. Just a second. I need to pass control to the chair. Yes.
Presentation: Network Inventory Location Updates with IVY Monday Side meeting
Bo Wu: Good afternoon everyone. I'm Bo and on behalf of all my co-authors and contributors, I will give an update on this network inventory location model.
So here is a summary of the changes since last IETF. In this version 5, we resolved five major issues and although we still have two open issues from Med's review comments, that is the two open issues I will talk about. We in this version 5, we resolved five major issues. I will work it through one by one.
The first one is unclear data authority. Previous version we define we don't define the clear authority of this location data. It could be like from inventory OSS or the controller itself. But in this version 5, we define controller as a single source of truth of this model. That means controller only report the data directly to inventory OSS and this model will not support read-write configuration attributes.
And the next major issue is bidirectional reference risk. You can see the figure below the table. In the last revision, we have both reference bidirectional references here. One is the base inventory augmenting with the location or rack ref, and also the location can referring to the network elements' chassis reference. And we think that may leads to risk reference risk if there's a two definition two reference there and be configured. So in the version 5, we only keep unidirectional reference only, that means only have location to network elements.
And the third issue is caused by the second change because we remove the location ref and rack ref from the network elements, that made the non-rack deployment has no location links. The examples of non-rack network elements could be AP access points or some pole-mounted devices.
And the fourth one is operational guidance. We have limited description how to use this location model and in version 5 we added explicitly said that the this model will be specific to the scope of controller to inventory interface. And on the example ones, we also added two JSON examples, one is access points, the other is distributed switches. So that is overall of this the five major changes.
And this is the overall module updates. The left one is the old YANG module and the right one is the new one. And you can see that in the 04 version we still have the reference to the base inventory that is read-write of augmentation to the base inventory. Now we remove that to be consistent with base inventory. Base inventory doesn't need to be support read-write attributes definition. And on the the major two YANG module changes in version 5 is the architecture one, you can see that all the attributes is read-only one. And the other major changes is that you can see I mentioned there's non-rack network elements reference that we added a contain-chassis under the location list to cover that use cases.
So I will move on to talk about the two open issues. The first one is about the read-only versus read-write approach. The first option is a read-write approach. This approach supports like inventory OSS can config location data into the controller. And the inventory OSS is an external system to the controller, that's quite typical use case of the network controller. And location data is supposed can also support the location data cannot be discovered by the network controller, that's previous version.
In the second approach is read-only, that is the current version 5 supported. So I also put the two figures to show what's the difference of the two approaches. The version 5 one, you can see that the specific scope of this location model is between a network controller and inventory OSS, and together with network base inventory location data is to report the enrichable information to the inventory OSS. And the assumption of a possible implementation could be that there has been already some automatic RFID tooling can give this location information to network controller. And another implementation is that the network controller support GUI interface that administrator can manually setting the location data into the network controller. So that is the current version 5 supported.
But we received a comment from Brad. His concern is that access network are planning driven. That means the data, the location data is mainly the authority of the location data is from planning OSS. So on the right, I show the picture of the of the access network use case that I understood from the Brad's text. And he's suggesting that the location is not only supporting the read-only, but also the read-write attributes that inventory OSS can send the location data directly to controller. But if location module support this approach, that may leads to inventory location data conflict, that's a possible conflict because network controller also supports location from people manually set or from also from RFID tooling. So in that way, network controller needs to resolve the conflicts. So that's a issue we understand from Brad's review.
And I would like to give the IVY Monday side meeting discussion on how to resolve this issue. The based on the discussion understanding, we actually identified two distinct use cases. One is actual location data for reporting to inventory OSS, and the other is intent-based install and deployment. So we think this location model this is not specific to location model, this is to base network inventory model also. So our proposal is that we still think the the current model and current use cases is also a correct one that network controller should report base inventory and together with location data to the inventory OSS. But in the future, we can defines a intended based install and deployment model to to support this intent-basis use cases. So I like to hear the opinion from working group.
Daniele Ceccarelli: So your proposal is to start read-only, and then in a second phase change it and make it read-write?
Bo Wu: Yes, that's our like the outcome from the side meeting's proposal.
Daniele Ceccarelli: Okay. Is there any question here? Any anyone willing to share an opinion on whether we should continue with the read-only approach or in a second phase should we go and allow for writing? I I have some doubts about the the planning the planning thing in the sense that, so the provisioning of a service is intent based, but I don't I don't understand what is the intent-based part in a location. Location is location, so where is the intent?
Bo Wu: There's a discussion, I think Italo, you mentioned that the there could be you plan the network elements will will be installed in the a site, and then the work order is sent to that and the network elements is boot up, then it will be connected to the controller and then you send out the configuration.
Daniele Ceccarelli: Okay, but then there is the problem of possible misalignment between the the OSS and the controller. It's something that doesn't just apply to location, but potentially applies to everything that that can go read-write, right?
Bo Wu: Yes, the whole inventory package.
Daniele Ceccarelli: So, the plan is to have this phase 1 and phase 2 read-only, read-write just for the location, or in general apply it also to other areas?
Bo Wu: I understand it also applies to the base inventory and software inventory and also entitlement also, the four the four the one.
Daniele Ceccarelli: Okay. And how are you thinking to address potential misalignment issues? One of the two is the source of truth and the other one needs to align or what is is there any mean to solve these problems that you're thinking of?
Bo Wu: The Brad mentioned that we could specify our use case in the model and see that this is only for the like base inventory and location data that discover already being maintained by network controller. But other than that, it's not belongs to not in the scope of current base inventory and also the location model.
Daniele Ceccarelli: We have Aihua and Italo in the queue. Do you want to take the questions now, comments? Or at the end? Now is okay?
Aihua Guo: Yeah, I just wanted to add that we had discussions about this yesterday's side meeting was um basically we agreed to consider two things. One is the the current progress of the basic inventory draft. It's and also there's a huge demand, very good, very strong demand to get it published so it can be adopted by also other organizations, right? So that's the consideration why we wanted to move forward with the first release of being read-only. But then also realized that in the in the next phase, we so location is one thing that according to the use case need to have the write capabilities, but then also I'd like to also mention about passive inventory which is the same thing, same situation. Um and also and and I wanted to point out that um if we eventually also um put use the model passive inventory as a part of the base above the pass base network inventory, um the fact that base inventory becomes read-only will restrict um what we can do with passive inventory. Um so basically these um the passive inventory as well as the location um needs to be um we need to do um a revision of the base network inventory to support write mode so we can continue with.
Daniele Ceccarelli: Okay. And in case of misalignment between between the two entities with write write? You you keep it as out of scope, or you are planning to mandate a I don't know, a behavior? One is always right and stuff like that.
Aihua Guo: We well, we touched upon a few options. Um I think we are still under discussion. It's not really, we don't have a solution yet. But the minimum is you can we can push it outside of the scope of the document because it's the controller would have to deal with all those inconsistencies anyway, right? If we find a better way to standardize that, which I don't think it will be for a particular model, but for a for a for a for a method in maybe can talk to netmod and yeah but we haven't.
Daniele Ceccarelli: Given you are at the beginning of this discussion, can you move the discussion to to the mailing list, please? I mean, everyone that is interested in this discussion gets on the calls etc. but I mean, in the mailing list we have more chances to to reach a wider audience.
Aihua Guo: Yeah, that was one of the requirements we had yesterday.
Italo Busi: Italo Busi, Huawei. Yeah, I'm just to clarify I fully agree with your comments. This is something we need to discuss, and that's one of the reason why we we proposed to go into the two phases. We also noticed that this issue are not only for location, applies also to base inventory as well as to passive inventory. So one idea could be maybe to do in the revision of the base inventory, go to read-write and have all this operational consideration because it's it's very simple to make a config true. The complexity is what you say, could what happens if there is and there we will discuss all of them and the idea was let's go ahead with this draft as it is, and once we have the base inventory majorly write, we can re-align also this draft with that one.
Mahesh Jethanandani: So, Mahesh speaking as a contributor. So, I had similar questions as Daniel is, one is what are the two phases? Is it like we publish a version of the draft, then we go through a BIS version? And now we're talking about dependency between models. I think that's a lot of churn, if I might say so, that you would be going through. Because now you have to follow the same sequence. You have to go back to the base inventory, change it, that would then allow the other models to also change. And more than me actually, I want to turn to the operators. Uh, we have a few operators in the room. What do you think about um as you think about the model, do you feel that churn is desirable or what how would you like to see this? Sorry, if I'm putting you on a spot.
Bo Wu: Now we'll move on to the next one?
Daniele Ceccarelli: We have Brad that is trying to speak. Italo is still in the queue.
Brad: I was just going to answer the question of I think the churn's good if you end up with a usable result, right?
Qiufang Ma: Sorry, can you repeat, Brad?
Daniele Ceccarelli: He said that the churn is desirable or at least acceptable if it leads to something that is usable.
Brad: Yep, correct.
Italo Busi: Italo Busi. I want to reply a bit to Mahesh. I don't think it's a big churn. It's an evolution because moving from read-only to read-write is not backward compatible, so everything which works which assume that the the server is read-only will continue to work. It's just that you enable new applications. So it's just like adding new attributes or adding new capabilities to the system. It's not a it's not a non-backward compatible change that requires you to do retrofit, so it's it's in line with the idea of having a face to face. Otherwise, we need to finish everything before we can publish and we can deploy. So it's it's more around going into phase, but adding stuff.
Mahesh Jethanandani: I will agree that on on the aspect of YANG whether it's backward compatible change, yes, that's that's not where the problem is. It's in the ability of the working group to then turn around and quickly publish all the changes together. Just this, you know how it takes time in IETF to publish anything. That's where my concern is.
Daniele Ceccarelli: I know. Yes, I agree with that. But I mean, the reason why we we had this approach of phase 1 and phase 2 is that in the meanwhile we deliver it, it's usable, and so the new version phase 2 will just allow new use cases.
Bo Wu: Kinda looking forward for veloce. Yes.
Nigel Davis: Yeah, just wanted to just support what Italo said and and just a quick point as well. I don't think Brad said the churn was desirable. I think he said the churn was acceptable but anyway. So um but yeah, no, I want to support Italo on that that that um we we need to deliver stuff. Um it's critical we do that, and this is a useful staging point in my opinion. Um the second thing I was going to say is as we move forward into the the world of LLMs which we're sort of in now, I think some of these transitions will be become more straightforward actually, because we'll get a lot of support in validation of models and and you know looking at mappings and mapper generation and so on from that um environment. So I think we're moving into a different space where hopefully we can move a bit faster with some of the stuff here.
Daniele Ceccarelli: Thank you. Please, Bo.
Bo Wu: I'll move on to the next one. This one is quick. This this open issue is also from Brad. The current rack attributes only define some rack dimensions, but Brad commented rack could also need some classification attributes to support security workflow or work orders to support like different rack has different case and needs different work orders. So the authors is proposing that we add this rack classification as read-only to the current YANG model and and yesterday in yesterday's side meeting, Brad mentioned this is can solve his concern in some degree, so we also like to hear if there are other opinions on this. So if there's good with this, we can directly add it here.
Daniele Ceccarelli: I see there's no comments on this. So, I think Brad is also online so. Continue.
Qiufang Ma: I was suggesting to ask the question on the mailing list too to get more. But yeah, let's do that.
Brad: Yeah, it's basically just the characteristics of the rack, right? Because there's different types of rack and you get security racks that are lockable, right? So generally in Australia three different version in terms of Class A, Class B, and Class C racks, but um that's really where the question originated from.
Bo Wu: Thank you, Brad.
Daniele Ceccarelli: Bo started. We don't have many answers, but at least there is a consensus.
Bo Wu: Thanks. Thank working group for this feedback on this.
Daniele Ceccarelli: I mean, in any case, I would ask again on the mailing list to reach who was not who's not here today.
Bo Wu: Yes. So I think this is our last slide and we will our next step is that we will finalize the discussion on these two on the mailing list also, and then if it goes smooth, we will working group last call before next IETF, not 127. Yeah.
Qiufang Ma: Are there any any other comments? Otherwise, we will move to the next presentation. Me again.
Presentation: draft-ietf-ivy-network-inventory-topology
Bo Wu: So, on behalf of my co-authors and contributors, I will also give the update of this inventory topology model. This is just give some quick recap on what this inventory topology is. You can see that on the left hand side, there is a group of inventory models, and the topology actually is a separate one. It augments the topology with inventory references to support some use cases such as service provisioning or some simap what-if that kind of use cases. And we also provide a link to track all the open issues here. You can check if you can, you have your comments on on this document.
And here is a major summary of the key changes over version 6. There are two issues identified by the authors. One is read-only. We now change several attributes into configurable attributes. That is to support manual configuration for non-discoverable resources, such as the example could be a CE and PE interfaces and some lease line links. And we also add a section operational consideration to give the usage of the this topology model. And we also resolved the two open issues. One is remove reverse navigation, that is inventory to topology. This open issue is is raised by Italo and so in this model, we will focus on only on topology to inventory use cases. And the second one is about the cable name leaf issue. It's also be raised by Italo because this attributes may have some overlap with a passive inventory model. I see Olga you mentioned you you like to comment? Okay. Thanks. Okay, I will go on.
So, here is the overall of inventory topology tree and this new version incorporate all the comments from Italo, Oscar, Aihua and Olga. I I think thanks for your all helpful comments to improve this. And you can see that we remove several redundance may have some redundancy from the definition. You can see we removed all the network elements, base inventory's augmentation that is node ref, network ref, because that can be derived from topology to inventory. And second, you can see that we remove cable name, because I will talk about that in the next slide. This have some overlap with the passive inventory definition. And you can see that on the new YANG structure, we have several attributes change to the read-write, that is the node can referring to network elements reference and also link type and also the termination point to referring to the port component. That's a major changes.
The first issue that we resolved in this version is bidirectional navigation between topology and inventory. We used to have like bidirectional feature definition and support bidirectional reference. In this version, we change to one-way only because there's a discussion on the mailing list between Italo and the authors. The concern is that the two feature defined that could be have some interoperability concern and if there are both reference from topology to inventory and there could be inconsistency reference risk. So that's the reason we we recommends to change one-way only. So that way we can simplify the YANG structure and simplify the implementation to avoid two features definition. So, if there's no I like to hear some feedback on this open issue resolved. Whether have some concern of the we now have only one-way only.
Olga: I think I think it's a great proposal. I completely agree with you. Sorry, I raised my hand for the end, so if somebody has some comments in between, please jump. Thank you. Thank you.
Bo Wu: And this is bidirectional one, and then we remove cable name. Before we have cable name defined to support the like direct cable connection between the two network elements. In this way, in some implementation there's may not have a cable list inventory developed, so we think cable name can also give some information on the how this two network elements directly connected. But that may leads to some confusion if there's a passive inventory defined, what will be the cable name is. Is that part of passive inventory's cable attributes? And the other thing is that when we use a cable name, that has a assumption that cable has already been have a inventory list of cables. So we agree that this may have some overlap with passive inventory, and we are expecting if passive inventory define the cable inventory can augmenting the topology model with the cable references. Either not directly to the link, because if there's like the figure showed on the right underneath, that if there are two FDT between NEs and there will be several segment of cables. If there's only one cable name, that will not give the track good tracking information of the cables if there's several cable segment between network elements. So that's a reason we we also propose to change this. So that is cable name.
And the other issue I didn't mentioned because I we we haven't resolved this in the document. That is whether nodes and network elements of base inventory is that one-to-one mapping, or is multiple-to-one mapping. So currently in in the YANG model definition, we directly explicitly define that there is a one-to-one mapping between the node and the network elements, and also the port to the termination point to the port component. And we think this can simplify the mapping and we think if there's a multiple-to-one, it could be being defined in like Layer 2, Layer 3, TE topology. Those topology can support abstract like several virtual topology, so it doesn't needs to be defined in inventory topology. So the authors' proposal is that to keep one-to-one mapping in the model and we will explicitly add the text that this document specifies one-to-one mapping, and will also add the data text to see that the many-to-many abstraction are intentionally excluded from model that will be handled in other topology models. So, if there's no opinion or comment on this, I think that's all from my presentation. And we think we ready. Olga, please.
Daniele Ceccarelli: Let's move to the comments. Olga is the first.
Olga Havel: Hi, thank you. We should have probably presented here, we did a hackathon on the knowledge graph where we imported SIMAP, we imported base inventory, passive inventory, and topology inventory YANG. And semantically, for the base inventory, there were no issues, all traceability is there, and we were able to connect everything. Of course, we don't have for passive topology, there is no link there, you know, so I know that you are planning maybe to do it. We had three comments in general about it.
The preference would be why would you have two different topology inventories? Why wouldn't you put it in a single one? Like, you know, whether it's passive or non-passive from the perspective of topology, it would be then identifiable through the type of the device or NE. So that was the first comment, like so what we would need is extending the node for the passive device, although we don't the preference would be that it's single type of the entity, network element or device that incorporates both of them. Because why would you model them differently if you have some base commonality between them like ID, name etc, you know? So but so that's our recommendation, but we were not involved in modeling. So so this is just a kind of high-level comment.
The second thing is we need relationship from link to cable. Like type I don't know it it's descriptive, but it's not really, we need a ref to the cable. And the third comment would be why does the cable have A end and B end? When we already have the link between nodes in topology. So in that respect, there is a duplication. If I ask Copilot what's inventory, what's topology, it tells me inventory is list of assets, topology is the how they are connected. So from my perspective, what we have in the top-level cable, A-side and Z-side, is something that we should have in the topology. So these are the high-level comments, so maybe we can we will present like and share on the mailing list the hackathon results, but I already shared everything at the side meeting yesterday, so.
Bo Wu: I'm not sure, I'm not sure the comment is to this model or it's to passive inventory.
Olga Havel: It's both. For passive and this model. Like one comment is that the reason I don't understand the reason why this doesn't include connection to the passive inventory. I think this should be generic inventory topology, inventory relation. And if you have model passive device as network element, you would have a NE. If you model the other things as components, you would already have it. And then the link would need a ref to the cable ID. And then the comment about passive inventory is why do you have A and Z when it's already in the topology? Why do you have topology in the inventory?
Bo Wu: I think for I think our authors has discussed this. We think this is a general one, because the passive inventory is one type of inventory. I mean the cable. And there could be like a Wi-Fi SEED, right? And also there could be lease line inventories. That would I think there's more than passive inventory there will be if there's a other cases, then they can augment this general topology to enrich this.
Olga Havel: Yeah, but we do need traceability, you know? I want traceability for physical to service, I want traceability for service to physical. If possible. So if I don't have that semantic relationship to cable and passive device, I cannot figure out where the problem may be.
Bo Wu: We suggest this is will be part of passive inventory. Like passive inventory may also have a module that augmenting the topology.
Daniele Ceccarelli: Just clarify and point I would There are two aspects here. The first one is that passive inventory is currently not within the adopted documents here in IVY. So this is just a procedural stuff. The other point is that we say that we at least in this document, we focus on the basic nodes that allow us to glue the inventory and topology. And what we say in this document is that if there are other extensions to the base model, it's up to this document to define the navigation from there to the topology. So that augmentation should be done in the passive document. And this is actually already documented in the document. So your point is valid, but it should not be handled here, and it's up to the passive topology to show how it will be doing that navigation. So the augmentation should be done there. So it's not optimal, but that's what we have today, and we just need to build on start on step-by-step. At least the recommendation we are providing here, yeah yeah there are other layers in which we'll be needing to have the navigation. Please when you are defining new augmentation to the base model, if you need the navigation to be there, consider also to have the augmentation in those extensions. That's a basic recommendation that we are giving here, and it's really good that you are raising this point so that everyone is aware about about this.
Olga Havel: So you are saying if there is no passive topology passive inventory at all, only cables, they would be modeled in the passive inventory and your relationship will not have a link to the to the physical?
Bo Wu: Not to the cable one. Yes, only network elements and termination point port components.
Daniele Ceccarelli: That's consistent with what we put in our document for the last part.
Olga Havel: Yeah, but logically doesn't make sense, but okay.
Daniele Ceccarelli: Yeah, I know. But this is a mix between the scoping of the work and and this is also the phased approach that we have agreed early on. So yeah, I think that this is not optimal, but this is what we have today and we just need to start step-by-step. At least the recommendation we are providing here, yeah yeah there are other levels in which will be needing to have the navigation. Please when you are defining new augmentation to the base model, if you need the navigation to be there, consider also to have the augmentation in those extensions. That's a basic recommendation that we are giving here and it's really good that you are raising this point so that everyone is aware about about this. It's not optimal, but that's what we have.
Bo Wu: Thanks, Olga. If you can send this comments, good comments to the mailing list, will help to clarify this. Thanks.
Bo Wu: So any other comments? I think this is our last slide and we will our next step is that we will finalize the discussion on these two on the mailing list also, and then if it goes smooth, we will oh it's our planning is that working group last call before next IETF, not 127. Yeah. I think any other comments? Otherwise, we will move to the next presentation.
Presentation: YANG Data Model for Passive Network Inventory
Aihua Guo: Yeah, this is an update on the individual draft for passive network inventory as we have touched upon a few times. Um, so the status update, we have published a 03 version of the draft, which does only one change to make adjustment to the front-page author list, per IETF guidelines. And also we have discussed this on the last IETF that basically we had a consensus that the work for passive inventory modeling is in the scope of IVY. And there were also comments received from from the last discussion, basically the definition of the passive inventory needs a bit more clarification before the working group adoption. Um, but otherwise we have the document with the changes in a stable state.
Um, so the discussion about the definition of passive inventory, basically we so there are um there is a description in the current version which describes about what a passive infrastructure is referring to. Um but probably it did not spell out clearly about the definition for passive inventory, while at the same time we also have in the base model which defines what network inventory is about. Basically a collection of data for network devices and their components.
And so, we had a couple of discussions and so here we make like an initial proposal which is just a starting point for discussion and we definitely will will go through all those discussions on the weekly calls and on the mailing list. But basically what we are thinking is a passive inventory is it contains a collection of inventory objects which is related to the network infrastructure that are not powered and has no direct management communication and they are used to realize the underlying physical infrastructure, which by definition carrying signals throughout through a network, right?
And then some further descriptions about what passive inventory might include. It could include elements like optical cables and fiber segments and and all those typical elements that consists of the supporting infrastructure that does not actively process or forward or control the network. And so this is the the basically the the initial proposal, but as said we need to discuss it and formulate this in the in the draft. With that, I think yeah, I can stop here. Maybe we can have some quick discussion and comments.
Mahesh Jethanandani: Mahesh speaking as a contributor. I like this a lot better than coming in without knowing exactly what was being considered. So, just one maybe it's only a nit on my part, was trying to understand the third line that says "that are used to realize the underlying physical infrastructure." The only clarification I would like is, so you have two cables, the one is that is actively connected to and being used between two boxes, and a cable that's just sitting there. Are both in scope, or it's only the one that is being actively used?
Aihua Guo: That's a good point. I I think I I mean as a contributor I would say um all this used or unused cables um should be part of the inventory.
Mahesh Jethanandani: So if you have a 100 cables sitting in a closet somewhere?
Aihua Guo: Yeah. Now we're saying we need to document all of those.
Daniele Ceccarelli: Well, I mean, it's if the operator choose to track that in the inventory, yes.
Aihua Guo: I think I mean it's optional. Maybe you have one unused that you want to track and 100 unused you don't care about, maybe. Because typical, you know, you have an operator which has cable laying around very geographically, you know, stretched through multiple regions, right? That was there, it was not it might not be connected to the network, but that was one of the assets that they, oh I shouldn't call it assets, but that's the element that they are really interested in keeping it.
Mahesh Jethanandani: So um it really what I guess I'm trying to get to is the intent. So if the intent as you say is these objects are maintained for purposes such as identification, location, connectivity, and life cycle management, an actively used cable certainly will count as that, but how is something that's sitting in a closet being identified, for example? I mean, you will be naming all of those cables, um you will have definition for a language for them of where they are located?
Aihua Guo: Well, you don't well you don't necessarily need to track those, but but in the case that you need to track those that are still not deployed or or not connected, right? You you might as well do this with the inventory.
Mahesh Jethanandani: Okay. So it's basically it's totally optional. You have the right to basically you have it's still in scope, but depending on your use case, you might want to track all those unused cables. Okay. I mean, I'll let the working group decide if they want it or not.
Aihua Guo: Okay. Um so let me get to the next one. Yeah, it's just our next steps would be just like said to discuss the definition and incorporate into the into the into the work. And also we have seen quite a very strong interest with very good support to consider this work as um being standardized. And there's also because the passive passive inventory is widely managed or considered in particularly in for access domains because there are a lot of passive passive elements between within the access network. So basically we would consider um well request the working group for for the adoption of this work once we have addressed the the definition. And there are also there are still a couple of other open issues. Basically we still need to discuss whether we should model the passive device as a special case of network elements, which means to augment um to make this model augment the base network model, which is not the case today because passive device is still modeled as an individual um as a separate um form of device. But those work can still be carried even after working group adoption as part of the working group process. So we have a GitHub repository and then we um we discuss and we plan to discuss this work during the use the IVY design team slot Wednesday 10 to 11. Anyone can are more than welcome to join the discussion. That's it.
Daniele Ceccarelli: Other comments? No. Thank you, Aihua. The next one is the entitlement entitlement management. I think Diego has yeah. Thanks for coming on time.
Presentation: A YANG Module for Entitlement Inventory
Diego Lopez: I'm sorry, I was asked to act as delegate in the in the sustain group. Uh well basically this is an update on the on the entitlement inventory draft and basically what we have been working is trying to be worth of having the adoption. That there is a quite thorough update of the document, including that we have added a new author that is sitting over there in the to my left. And well basically the the original document what we were and we were discussing and we get some some questions and and comments is that well it was just basically trying to define the basic concepts and the and the general trees that could be used. Once that we seem that we got a consensus of the group that this was something that it was worth, what we have done is precisely review this in depth and come with a with a detailed a detailed and complete module definition, updating everything and providing a set of examples trying to illustrate why things may be or well to illustrate how things can be extremely simple or how things can be get complicated if you have a a complex situation of a multi-vendor environment of different pieces of software and hardware and try to illustrate what are the what are the main um the main considerations that you have to make and how this can be implemented using the uh the model.
So, we have trying to make a much focused definition taking into account the feedback from the different discussions on the mailing list and direct interactions that we have on what is a what is capability, what is entitlement, what is a what is an entitlement is installed, what is a restriction, what we do we mean when we talk about assets. The capability model has been somehow streamlined and we have made a we have defined a clear extension pattern and a more detailed formal definition. You know that there is ongoing work that won't be presented in this in this IETF because Nigel that is our main author has been busy with other other stuff, but he is we are working with him in a more detailed formal definition of the whole about capabilities and how we can work reason with that. So but what we have done is taking a practical I believe to capabilities and what a capability is that is enough and is not incompatible and this is something that we are coordinating with with Nigel to to guarantee that this is keeps being compatible. And we have made as part of the of the work in the model definition etc. we have managed to have a more precise anchoring of entitlements and how these are they are connected to the to the base models.
Something something that is important apart from the model, apart from the detailed tree, apart from this is that we propose as well a sort of a five maturity level on how this could be adopted from a very very base thing that is well you you have your collection, the collection of your entitlements that is part is one of the integral parts of your inventory, you have a collection of licenses or or permissions to execute certain software or tokens or whatever. This is from that basic model to the highest maturity is what you only you're not only aware of which are the entitlements, where are they installed, how are they used, which are what are those entitlements entitling you to do, but as well analyzing which are the requirement the sorry the restrictions and how that can be can impact the the different entitlement. So from from the first level in which you have a centralized set of entitlements and well you expect that everything will will go right till the moment in which you you say what you know is precisely what you have in each individual element and how they are restricted in in the particular use. These are the five maturity levels that are analyzed. They are I mean they build one on top of the other, so the idea is that you can you can be at at maturity level 3, and that implies that you can address two and one and and reply to the to the questions that appear there that are basically what is associated with each one of of these levels.
The model is totally new. I well I was watching Bo presenting the changes etc. of the of the topology etc. the I have not make any changes I mean illustrating this because the model is totally rewritten, there is new identifiers etc. so it's something that it's basically the message is it's new and it has the is based on the same idea that we are talking about entitlement as a you hold the entitlements are part of the of the inventory and the different elements that there are are can be associated by reference or implicitly explicitly. And that is something that let me say this is the this is the tree as it is seen, the model is detailed in the in the document and will be for sure open to discussion.
And we have been working on eight different examples that cover well we have a different degrees of complexity of complexity in terms of modeling. Ideally should not be very complex to understand what is what is intended in each one of the examples, but the idea is to the modeling can be more complicated because we are talking about modeling more complex real relationships. And if you look at the well the key concepts that are you have there the well the title we have assigned, the complexity we believe that they have in terms of modeling, the key concepts around and something that I we believe is the most important thing is which are the operational questions that that you have that comes from from real operational experience as well trying to run a multi-vendor widely widely widespread infrastructure. And for example something things that can be can be critical, things like well what are the good if we we start with the understanding what we prefer with a to an entitlement and what refer to a to a network asset, but things that are more complex like for example upgrades and dependencies or how to to manage pool licenses or how to unify trying to unify mechanisms with from different vendors. So you you understand what you can do though even in the case that you have different specific formats coming from the vendors. So this is uh this is there in the text, trying to clarify it. For sure, right now and this is something that we were discussing before coming here whether this should be part of an appendix or not because they are examples. This is something that we can discuss when when the document matures.
With this, we consider that the document is essentially completed. Everything that we wanted to have in the document is now in on the document in the document, should not need from our side much more detail or or or extensive work in creating more more YANG or more or more trees or concepts. And what we believe is just to a an in-depth review of everything once we pass the conceptual level and now we are in the let's say concrete more concrete level. So any comments that comes from the working group? The YANG doctors, I guess the YANG doctors we will have many things to say my and for sure well I don't know about the nominating a shepherd etc. so let's go I mean what we expect is that from this moment on start the more formal process of validating what the document is there. And well once everything is there, we hope we will be able for a last call. Shepherd is a bit early, but for the rest is okay. Well, that depends, I was appointed a shepherd on of a document when it was it was just adopted, so that.
Kent Watsen: Kent Watsen. Um, I'm a bit I apologize if this has been discussed before, but um I was hoping to see in this work, I thought it'd be in this work, maybe somewhere else, but um stepping back from licenses and just talking about capabilities of a device. Um, let's pick a device that does VPNs. Uh, so it might have a variable called max_num_vpns, and that is a variable that could be um the value could be changed. Um, I would imagine that variable, the value to exist in a system datastore. I know Qiufang is the one of the authors of system datastore. Um, but I would think it'd be in the system datastore. The system is aware there's a value called max_num_vpns. How does the value get set? Well, it could be set based on the hardware. If it's a low-end device like a like an X-100, it can do 100 VPNs, if it's an X-1000, it can do 1000 VPNs. So it's hardware-based. Or, maybe it's running the uh 1.0 version of the code and and that version allows you to do um, you know three VPNs, but now you get the 2.0 version and you can do five VPNs. Or, um a physical card is inserted, and because the physical card is inserted, now you can do 10,000 VPNs, right? None of this is related to licenses. However, you could purchase a license that says plus 100 VPNs, plus 500 VPNs. So the ability to modify the value. So so all this I'm thinking, okay, uh I'm expecting there to be a variable defined in the system datastore that's modifiable based on hardware type, um software version, operating system version, presence of other system resources and potentially licenses that have been installed. Um, is this in in scope of this work, or is it
Diego Lopez: Of this document no, of the other document that I mentioned yes.
Kent Watsen: more capabilities than entitlement.
Diego Lopez: And it doesn't um we we just decided to to split this because the discussion on capabilities was somehow making very complex this idea of having an inventory of the of the licenses.
Kent Watsen: Okay, so in that other document, does it speak to the variable existing in system datastore?
Diego Lopez: Yeah, that's the idea.
Kent Watsen: Okay, perfect.
Diego Lopez: So it's uh right now it's a 00 or a 01, so it's uh.
Kent Watsen: Okay. Then with this document, um I was trying to read the YANG very quickly and uh it was a little bit of an eye chart, but is it the case that the entitlement, the license can like plus 100, plus 500?
Diego Lopez: It should, yeah yeah yeah yeah. Adding adding.
Kent Watsen: Adding and.
Diego Lopez: And if not, we would have miserably failed and then you you will tell us, you will tell no no I mean no but this that's the idea precisely. Because originally we started precisely from that point say, well no, let's think about we have assets, we have capabilities, we have very abstract things that can be uh enabled by licenses or can be enabled as you said, by a hardware update or whatever. And then we we enter the problem that is something that the group or our our understanding of what the group wanted was something practical, quick, the same way that we have the base model and we wanted and for us, and I can I can speak for um for Camilo, my colleague that is working in NTT and myself, it was something I mean this kind of in the inventory as what is the the economic things that you have is very important to say, well I have paid for this licenses, I want to to have it.
Kent Watsen: Completely great.
Diego Lopez: But but you're right, totally right and that's why we are we're thinking about the capability model.
Daniele Ceccarelli: It seems you found the first reviewer.
Yuan Yuan: Hi, I'm Yuan Yuan and first time to come to this IVY meeting here and I have a quick question about like the five levels you mentioned on your slide. So should like the five slides be in a strict ordering of picking or or the the operators can pick based on their need and not?
Diego Lopez: Well, the idea is that the it's should that is as it is um if it is planned is that that yes, you need to to get to four, you you need to go over three, two and one.
Yuan Yuan: Okay, I I thought it was like the operators can pick based on their need and not necessarily.
Diego Lopez: No, well the idea is that the the model is designed so once you have the let's say um for supporting capability reporting, you need I mean capability reporting in the in the restricted capability uh environment that we are talking about, no what Kent was asking for, you need to be aware to be aware of which are the general entitlements you have plus which entitlements are available or installed in each network device. Otherwise you cannot say I can do this or that. So the idea is that they are they are they are stacked, so to say.
Yuan Yuan: Thank you very much.
Daniele Ceccarelli: When you stand up, we are all scared.
Presentation: Hackathon on YANG data model for network inventory
Italo Busi: Okay, I'm presenting on behalf of the members to the members of the Hackathon. We had a Hackathon during Saturday and Sunday this week on testing the IVI data model. And we would like to present a bit of the results. So what was the Hackathon built upon? Was built upon a network and a network and a controller from Huawei, which were in a living in a living lab, so there was a live network. And also there was an inventory from China Unicom, who were who were retrieving data from the Huawei controller. And then we had we extracted the JSON code, we handed to to Ciena, and they did a similar job on their own inventory role. And we showed some that there is a way to to get common the the same data from from to show the same data getting from from the same YANG data model source.
The what we showed that was basically we implemented uh in the in the in the Hackathon an old version of the draft, which was actually the latest working group document in C-CAMP before we moved the work in the IVY. But most of the definitions there are already common to the current model. And the network environment the test was about four nodes with some some modules and ports and transceiver modules inside. And there was a some shown in the in the China Unicom orchestrator there was a a screen where you can see what are the network elements that have been retrieved from the controller, as well as all the components that are on the on the rich network element. We registered a video, if you are interested, you can see more details if you go to the YouTube, and there is a a live demo on this stuff. And then after that we sent the JSON code to to Nigel and he shown this into Ciena.
There was a some minor work they had to do because they had to adapt the old version into a new version, so there was an an adaptation of the models different version of the model, but the changes were quite minor minor because the the two models are very close together and they were able to show more or less exactly the same they were were show exactly the same data that were retrieved through the YANG data model. And we have two screenshots also in these two slides. Okay, so so the list of the team members, so the people who worked on the Hackathon.
Unfortunately I have I had to prepare the the PDF, the the tool screwed a little bit up. We have a Hackathon we have a GitHub project repository where you can see the JSON code and the presentation that was presented in the Hackathon wrap-up. And we have you already the full video on YouTube already mentioned. And now the plan is to have further work in IETF. So what are the conclusions after this? We think that the model we proved that the model is quite mature, so uh we are we are on the right track and uh also the adaptation of read between an old and a new a new version required minimum efforts, which is also good. And we also now we the plan is to have another Hackathon IETF 126. We are collecting interest. We will discuss this plan for the Hackathon in the next week's call on Wednesday, so anybody is welcome to join. And I think Nigel will be the main driver for the next Hackathon.
Daniele Ceccarelli: Please, Nigel.
Nigel Davis: Yeah, that's right. Exactly, thanks Italo and um yeah we haven't actually posted any information about the Hackathon yet so um we will be doing that on the Hackathon site obviously for um IETF 126 he says trying to remember the number I'm not very good not very good with numbers today. Um but yeah, so the intention is to pull in other vendors to work with us. Um we're looking for um operator support for this as well obviously, because we don't want to just do the Hackathon for the sake of it, so we want to make sure the operators are um are on board and and in fact want to um sponsor without money obviously our activity. Um and we're um we've got a structure similar to the one we showed here. This was a from our perspective, thanks Italo, thank you. From our perspective um um yeah, so thank you. So the we're aiming for multiple controller roles and multiple inventory roles in the um 126 Hackathon, so we can sort of try out some other pieces and um also look at comparison with between IVY and TAPI to see if there are things that we want to introduce into IVY that um we've got in TAPI or alternative things we'd like to take out of TAPI because they're not necessary. But um and there's a a line of sight to further work beyond that as well, which we'll um plow into that that Hackathon. And the um the aim is to do a similar sort of test, but to add further data in etc. so it's um hopefully it'll from my perspective it was a very good I'll call it a dry run, it was a you know wet-ish dry run because we had actual proper data and so on but so we didn't connect as you can see the dotted line on there we actually just took the JSON file and plugged it in just behind the connection part of our adapter um and and as Italo said with a tiny bit of work to deal with the um version differences um between our um implementation and the Huawei implementation, it was um we got the right output. There's a couple of mappings you'll notice if you look at it in detail that we got the same field, the same value in several columns of our table, but we we felt it was maybe slightly ambiguous with respect to what we were displaying as to which way we should map it, so we just did a bit of an over map but um but it was um it was very very straightforward really to deal with, not to downplay the designers' work because he did he was um in India and up till pretty late until we when we got the JSON initially, but um it didn't take him very long once once we got the JSON to get it running reliably, so it was good. Very good.
Daniele Ceccarelli: Thank you. Thanks a lot. Thank you. And I think that's it. Thank you everyone. Have a very good rest of the week, end of the day. Thank you. When you stand up, we are all scared. Except.