# Agenda for the IETF 118 IVY WG meeting {#agenda-for-the-ietf-118-ivy-wg-meeting} ## 1. Introduction (10 mins) {#1-introduction-10-mins} chairs Session introduction & WG status ## 2. A YANG Data Model for Network Inventory (15 mins) {#2-a-yang-data-model-for-network-inventory-15-mins} draft: https://datatracker.ietf.org/doc/html/draft-y3bp-ivy-network-inventory-yang-00 **Presenter: Chaode Yu** **Marisol:** I think that the entitlement should cover more than just the network inventory at the hardware software level. **Daniele:** So you are you are suggesting to call it differently. So, like, inventory entitlement, as opposed to some you're layering entitlements in something like that. Is this your proposal? **Marisol:** Yeah. Initially, when we were, part of the ops are working group, we were calling it license and we had a discussion to rename it. We agreed to call entitlement to the concept that we are bringing in DMLMO **Chaode Yu:** the feature is about the controller or application, not the hardware and software inside the network element? **Marisol:** Feature is the capability of the network device, it could also be in an application level. **Nigel Davis:** Wanted to see if you would consider the expectation/intention aspect. e.g., you can say that a particular component is expected in a place, and the wrong component is there. Will you cover that in the framework? **Chaode Yu:** Are you considering aligning with tapi? **Nigel:** Not necessarily aligning with tapi. A feature in tapi that allows you to identify what should be present in a particluar place. **Chaode Yu:** consider it as our next step. **Nigel:** You mention power. Consider temperature and other environmental features as other augments. **Bo Wu:** With base inventory model, WG seems to agree that the terms should be defined in a base model. A framework section could be added to give the whole picture and another section about the terms(e.g., how the entitlement could be mapped to the network layer allowance). **Diego Lopez:** General commment: what makes me uneasy is the terminology misuse. Believe that inventory is about static data and not about the dynamic properties of the network model -- we have topology models, routing models, etc for that. At the end, the inventory will be linked with other models, but trying to avoid requiremrnt creep. Reporting the cables (green cable, red cable) connecting devices is ok since it is the physical element but this is not topology. **Benoit:** I'm going to present in the last session. The last slides in my slides are going to address the same point about topology. I fully agree with Diego that the topology means higher level. Don't want to fall into the trap of doing everything. We should all have the same keys so we can go from one model to another. **Kireeti Kompella:** Agree with Benoit that pointers should be easy -- eg should use the same key. Do we want other things in the inventory aside from the topology -- eg what vlans does this device support, what ip addresses are available? Or is the inventory is just the physical/virtual devices in the topology? **Daniele:** This is a question for the WG. **Kireeti Kompella:** For the state of the device, if you look at RFC8345, you have mostly devices that are in the network whether physical or virtual. But also useful to have devices that are planned to be in the network. So being able to model that would be useful. Is that in the plan? **Daniele:** When we wrote the charter we were considering what is in the network, what was in the network and optionally, what will be in the network. **Nigel:** I agree on the topoogy point but think you might be talking about cables which are physical. To clearify the reason why I raised the temperature point, I wasn't intending temp to be a fundamental part of the equipement model, but was intending it to be treated the same way as power, etc. **Oscar de Dios:** 2 points. First, if we want to cover what is planned, this will lead us to mutiple inventories, want to stick to one inventory view about what we're currently having. Second, cross references are expensive. The pointer should be in topology and point to what we have in inventory. **Daniele:** Repond to the first point: this doesn't mean everything needs to be in the same module, we can cover what we have now and augment it in the future. **Italo:** In the ccam draft in the inventory we focused on the physical elements and capabilities, and then in the toplogy we reference. Idea is to navigate from the topology to the inventory. **Alexander Clemm:** To me the relevance of this model is to provide the common anchor point. But I wouldn't necessary put all this functionality in that. eg when you talk about cables that's a completely different animal because you're talking about facility management, etc. Similarly concerning the aspect of "is something expected to be there", this is important but doesn't necessarily belong in this document. Needs a state model, etc. **Rob Wilton (AD hat):** In terms what the WG spends its time on, this is the one piece of work that's obviously clearly in charter. Should spend as much time as we need to to progress this work. **Rob Wilton:** On this model, I'd like to understand how to extend it. In terms of the component class augmenting it would mean all the components would have these properties. So may be good to have a choice statement so that (eg) you wouldn't see hardware properties in a software component. **Chaode:** There is a choice-based structure in the base model. **Rob:** Oh, I didn't see it. **Olga Havel:** There are other drafts in other WGs concerning different layers. My concern is if we have different drafts in different WGs, we won't have a consistent approach. **Chair:** Are you proposing which WG? Or maybe this is a question for Rob. **Rob:** I want to focus on core inventory work first. Get that base model done, then consider WG rechartering to bring that into scope. **Olga:** No I'm talking about moving inventory out of ivy and into the WG doing topology. **Rob:** Not sure about that. **Kireeti Kompella:** There is a draft in CCAMP WG called network hardware inventory, plan for how to manage that draft? **daniele:** Inventory for optical, but would dependent on this core model. Quick comment: figure in section 3 is good, but moving on with the documents, turn that into examples. We cannot mandate the future extensions. ## 3. A YANG Network Data Model of Network Inventory Software Extensions (10 mins) {#3-a-yang-network-data-model-of-network-inventory-software-extensions-10-mins} draft: https://datatracker.ietf.org/doc/html/draft-wzwb-ivy-network-inventory-software-00 **Presenter: Bo Wu** **Daniele:** Regarding the WG adoption, our first priority now is the network inventory core model. Will adopt others after that one is adopted. **Joe Clarke:** You have OS. Feels to me like it should be part of the base inventory. Don't want to conflate it too much, but hardware runs software and it feels like maybe it could be part of the base. ## 4. A Network Inventory Topology Model (10 mins) {#4-a-network-inventory-topology-model-10-mins} draft: https://datatracker.ietf.org/doc/html/draft-wzwb-ivy-network-inventory-topology-00 **Presenter: Bo Wu** **Italo Busi:** I think youre'a addressing 2 requirements: (1) the need to have a physical topology view and (2) to be able to navigate from topology to inventory. Would suggest you split the model to have a more flexible way to address these requirements (eg without needing to implement physical topology) **Bo:** will consider that. **Olga Havel:** First comment, the naming of network inventory topology may be confusing and too generic. Second, maybe reuse the pattern of you how do attributes, eg doing what OSPF/ISIS does. Also agree with the previous point that we may want to go straight from L2/L3 to inv without physical. The third thing is about the interface, we need a generic approach to connect interface at all layers. **Aihua Gao:** My understanding is you can have multiple network elements that form the same node. The current Yang model has a 1:1 leafref. **Bo:** I could make the model more flexible than a 1:1 mapping. **Diego Lopez:** Consider changing the naming. Make it clear that the physical inventory is the root that everything points to, when talking about network elements. **Oscar:** I would avoid using the term "port" because people might misunderstand or think it's just a physical port. **Chair:** Do you have a suggestion? **Oscar:** Some related work in ccamp. Might be some terminology we can use from there. **Chair:** (Responding to Bo's summary) This work is in the charter. ## 5. A YANG Network Data Model of Network Inventory Entitlement/License (10 mins) {#5-a-yang-network-data-model-of-network-inventory-entitlementlicense-10-mins} draft: https://datatracker.ietf.org/doc/html/draft-wzwb-ivy-network-inventory-entitlement-00 **Presenter: Bo Wu** **Chair:** Would be helpful for the rest of the presentation if you make it clear the difference between allowances and entitlements. **Bo:** Clarified on slide 4. **Chair:** Is the difference the level of abstraction? **Marisol Palmero:** I'd like to highlight a couple of things. The linkage that we do with the features/functionality with the base model is to the asset. The arrow should go through the asset. **Marisol:** In the almo modules, what we are looking at is the data model. Whether it's the controller level, the orchestrator level, that's an implementation detail. **Bo:** Right now we don't have a standard definition of network features. So in that way, the model augments the base inventory model. **Diego:** With almo they're trying to focus on the lifecyle of the network services that are provided and how you build those services and make them available to users. A feature is what you're interested in providing, eg optical connectivity end-to-end, etc. Feature is what you're interested in, and you're connecting it to assets. With features, the question is what those assets are able to provide. **Bo:** Can L2VPN or L3VPN be a feature? **Diego:** We're not tying to change the modelling of the VPN itself. We're tying to say "to provide this VPN you need this set of elements". **Bo:** I'm not clear what the granularity of that feature is. **Diego:** You're assuming that there's a set of controllers, network elements, etc that's not standardized. Almo can be used by a network controller or not. We're trying to model the lifecycle of a set of services, that's all. We're not proposing a concrete architecture for managing the data model. **Bo:** In IETF we have model classification. Not sure where the model can be located. **Diego:** Can you explain to me where the entitlement model fits? When talking about the service, network and device models, a feature can happen in the network model or the service model. We are not trying to model a device or a particular service. We're trying to model what you need to deal with to provide a particular service or network. **Bo:** I'm not sure that issue is concerned with my draft. **Diego:** I'm saying that, I believe it does not concern your draft, but you mentioned the almo model. We're trying to model the lifecycle of building a particular sercice. This is similar in some extent to saying you have services, subs-services, and a hierachy to manage the assurance of such services. This has the same philosophy as the SAIN model. **Bo:** I agree. **Chaode:** In my understanding, a feature could also be some other stuff, eg the feature defined in the domain controller. Currently I don't see any draft to define a feature on the controller level. If the entitlement wants to cover the feature/lifecycle of the domain controller this entitlement could be a separate data model. **Diego:** Yes, they are independent. In one case, the controller knows about what the device can do; in the other case it's about whether you can provide a service with the pieces you have. **Daniele:** when you compare the trees it is not clear why (e.g., is it because the scope is the same and you are trying to to see which one is better, or they have different scopes). Clarifying the scope is important to understand who does what and where. ## 6. A YANG model for Power Management (15 mins) {#6-a-yang-model-for-power-management-15-mins} draft: https://datatracker.ietf.org/doc/html/draft-li-ivy-power-01 **Presenter: Ron Bonica** **Jan Lindblad:** Applaud this initiative. The direction you're pointing is excellent. Some technical yang-related problems as menitoned on the list. There are other initiatives elsewhere and it would be nice to integrate with them. Suggest to join the IETF e-impact (IAB program) mailing list ASAP. **Qin Qu:** Lot of other relevant efforts, side meetings, etc. The model for the traffic planning you define, is it a network model or a device model? **Ron:** Network level. But maybe you have a point and it should be at the device level. **Qin:** (Some points about whether certain items should hang off the interface) **Ron:** Take it to the list, I welcome suggestions. **Daniele:** When we speak about power consumption, is there a difference between a device model and network model? **Ron:** I don't see the difference, but maybe there is a dif **Marisol:** The power consumption is given by the network elements. Ron, we are working on another draft, it's called power presented in OPSAWG. Jan mentioned other initiatives. We have some overlapping concepts. Should discuss whether to unify the approach. Appreciate it's hard to do this for such a wide area. **Chaode:** power consumption value is quite dynamic, do you want to use it to report in real time? **Ron:** Power consumption is dynamic, but not incredibly dynamic. Yes there's dynamic behavior but not very much. **Chaode:** The current model is working on the power management solidifying the dependency relationship between power elements. But we have a lot of other features, eg service configuration, performance monitorying. Do we need to have another draft/model to define that dependency? **Ron:** I don't think so. There aren't that many service-reliant components. It would just make the model too complex. **Chaode:** Maybe you could define the dependency in the more generic approach? **Oscar de Dios:** What belongs to ivy? In inventory, what I'd like to see is that information that is independent of what is happening. I would suggest splitting off other parts. **Chair:** Good question. Inventory means power consumption according to the datasheet. Maybe other power elements don't fall under inventory but might be something to discuss as part of rechartering. **Rob Wilton:** I don't have an answer as to where this work belongs. But I want the power management stuff to happen quickly. **Samier:** I agree there is a mixture of things here. Maybe some elements fit better in other places. **Chair:** If there is a static power value read from the device, but the user can configure power save mode, that might be confiusing. **Kireti:** I think this work fits here in terms of the fine-grained nature of power management while TE or global optimization for power would probably belong elsewhere. Let's start by understanding what the capabilities of the device are and what the components take, then move on to the second aspect of how we can optimize. ## 7. Asset Lifecycle Management and Operations: A Problem Statement and YANG Data Model (10 mins) {#7-asset-lifecycle-management-and-operations-a-problem-statement-and-yang-data-model-10-mins} draft: https://datatracker.ietf.org/doc/html/draft-palmero-ivy-ps-almo-00 https://datatracker.ietf.org/doc/html/draft-palmero-ivy-dmalmo-00 **Presenter: Marisol Palmero** **Bo:** (Request for clarification about whether/how the model augments the base inventory model. Agreed to follow up on the list) ## 8. Mounting YANG-Defined Information from Remote Datastores (10 mins) {#8-mounting-yang-defined-information-from-remote-datastores-10-mins} draft: https://datatracker.ietf.org/doc/html/draft-clemm-netmod-peermount-02 **Presenter: Alexander Clemm** **Daniele:** It seems that this work belongs to Netmod. **Alex:** yes but IVY could make use of it for the inventory model **Robert:** I think this work belongs to Netmod. **Qin Wu:** Today we use telemetry to reterive all data from your device, you propose now to read the state data from the device directly? **Alex:** Indepent of the network telemetry. This is an operational specification. ## 9. Modeling the Digital Map based on RFC 8345: Sharing Experience and Perspectives (10 mins) {#9-modeling-the-digital-map-based-on-rfc-8345-sharing-experience-and-perspectives-10-mins} draft: https://datatracker.ietf.org/doc/html/draft-havel-opsawg-digital-map-01 **Presenter: Benoit Claise** **Kireti:** L2/L3 inventory here, L1/L0 in CCAMP. **Daniele:** Agreed with you as CCAMP chair. **Italo:** Confused because I have to manage the inventory of a shelf board, what is the difference between the fact that this board is playing a L0/L1 functionality and L2/L3 functionality? **Daniele:** Whatever is common fits into L2/L3, technology specific goes to CCAMP. **Rob:** (talk about the WG generally) Lots of people and lots of interests. Let's focus on the charter and get the core model done, then we can have a discussion about what the charter should expand to.