Hi Alex, all, It seems to me you mentioned two IVY models, one is the BASE inventory model with minimum inventory attributes, and the other seems to be the CORE inventory model, which is the major requirements as charter B. Hardware/Software components including licenses. Am I correct?
In addition, you also mentioned that the CCAMP "network-hardware-inventory" may develop independently, as the requirements seems different from the IVY core model, since the equipment room is only for the indoor RACK location, not for the outdoor location. I also have the same doubts. Is the goal of CCAMP inventory same as IVY CORE inventory model? Last Wednesday CCAMP inventory weekly call, I explained the following use cases from draft-wzwb-opsawg-network-inventory-management and proposed the merged network inventory model : 1. Virtual devices, such as vCPE, vPE, vBNG, etc. 2. Software components, including device platform software, software patch, boot-rom, bootloader, etc. 3. Site as a location option 4. License list 5. Terms of network inventory, including network inventory, network element, and components 6. The merged network inventory model Here is some feedback and summary got on the call: 1. Some authors say virtual device, and software components are not considered, as the purpose of CCAMP inventory is to meet ACTN Packet Optical integration (POI) requirements for optical and IP multi-domain TE cases etc, https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-poi-applicability#section-4. 2. Some author shared the inventory information of Cisco vPE, indicating that virtual devices share the same inventory attributes just as physical devices: RP/0/RP0/CPU0:ron-srpce-791#show inventory all Wed Sep 6 14:50:04.239 UTC NAME: "0/0", DESCR: "Cisco IOS-XRv 9000 Centralized Line Card" PID: R-IOSXRV9000-LC-C, VID: V01, SN: B3BC8301B42 NAME: "0/0/0", DESCR: "N/A" PID: PORT-1G-NIC, VID: N/A, SN: N/A NAME: "0/0/1", DESCR: "N/A" PID: PORT-1G-NIC, VID: N/A, SN: N/A NAME: "0/0/2", DESCR: "N/A" PID: PORT-1G-NIC, VID: N/A,SN: N/A NAME: "0/0/3", DESCR: "N/A" PID: PORT-1G-NIC, VID: N/A, SN: N/A NAME: "0/0/4", DESCR: "N/A" PID: PORT-1G-NIC, VID: N/A, SN: N/A NAME: "0/0/5", DESCR: "N/A" PID: PORT-1G-NIC, VID: N/A, SN: N/A NAME: "0/0/6", DESCR: "N/A" PID: PORT-1G-NIC, VID: N/A, SN: N/A NAME: "0/RP0", DESCR: "Cisco IOS-XRv 9000 Centralized Route Processor" PID: R-IOSXRV9000-RP-C, VID: V01, SN: 59D4943FFB2 NAME: "Rack 0", DESCR: "Cisco IOS-XRv 9000 Centralized Virtual Router" PID: R-IOSXRV9000-CC, VID: V01, SN: 76E77892EA1 3. The author has previously discussed the extension of sites and licenses. 4. The authors and contributors took a quick look at the merged model, and we plan to continue the discussion on this week. Thanks, Bo Wu From: OPSAWG <[email protected]> On Behalf Of Alexander L Clemm Sent: Thursday, September 7, 2023 4:59 AM To: maqiufang (A) <[email protected]>; [email protected] Cc: [email protected]; opsawg <[email protected]>; [email protected] Subject: [OPSAWG] Getting rid of network-hardware-inventory container for straightfoward model alignment that satisfies both hardware inventory needs and generalization/extensibility goals (was: Re: [inventory-yang] poll for network inventory base model) Hi all, I have been looking at both of the inventory models that have been proposed and think that they are actually closer than it might seem and that it should be relatively straightforward to align them. The main obstacle seems to the top container object "network-hardware-inventory" in draft-ietf-ccamp-network-inventory-yang. Is this data node really important? It seems to serve not particular function, other than serving as a container for equipment room and network-elements. However, both could easily stand on their own; there does not seem to be a compelling reason that instances would need to be prefixed with "network-hardware-inventory/". By removing this object, we get in effect two separate modules - one for equipment-room, the other for network-elements. This makes sense anyway, as only network-elements are items subject to inventorying and equipment-room can stand on its own, providing auxiliary information independent of actual inventory (plus allowing for network elements to be housed also outside equipment rooms (Plus, depending on use case, not every network element may not be located in an equipment room with racks/rows/columns, but possibly in other locations eg roadside etc). The structure of network-elements now very much resembles the same structure as we have in draft-wzwb-opsawg-network-inventory-management. Yes, the list is defined in the model, instead of reusing / augmenting the list of nodes, but this is a detail - the main thing is the structures are aligned. The main difference from this point out concerns the actual parameters that are actually included. Both models have a set of parameters in common. draft-ietf-ccamp-network-inventory-yang includes a couple of additional hardware parameters, while draft-wzwb-opsawg-network-inventory-management includes additional subtrees for licenses etc. It would seem that it would be straightforward to define the common set of parameters as part of the base model, then define additional augmentations to incorporate other aspects of inventory as needed. Hardware inventory models would make the start, of course, as this has the most pressing need of being defined; at the same time the model structure provides the hooks and implies a design pattern that will allow other aspects of inventory (virtual network elements, licenses, etc) to be added in an integrated fashion as needed. As a broad sketch, the resulting model structure would then be composed of base inventory model (defining the network-elements list with very few very basic data nodes, perhaps just name and asset tag) , augmented with a hardware inventory model which adds augmentations for the hardware parameters and components hierarchy and a separate equipment room model. This covers everything that we have in draft-ietf-ccamp-network-inventory-yang. Then, IVY can add a model for virtual network element inventory (augmented in per the same pattern as the hardware model), license inventory, and anything else, per the additional stuff that we have in draft-wzwb-opsawg-network-inventory-management. So, in that sense I don't think we have to make a hard choice between 1 and 2, but merge and in the course make some alignments to both. For example, one could start with draft-ietf-ccamp-network-inventory-yang, modifying it to remove the network-hardware-inventory container and splitting the remaining module in two (for equipment-room and network-elements, both of which will now be top-level containers). Remaining modifications can be made from there. I guess this makes me a proponent of option 3, but with the caveat that this would not need to restart from scratch - really an option 4 that says merge (for overall structure and common parts, which in this case is possible) and split the remaining difference. --- Alex On 8/27/2023 11:21 PM, maqiufang (A) wrote: Hi Working Group, It’s now time to start considering how to move forward with the inventory base model. We have two different documents that could be used as a starting point for our work or, in case the working group believes none of them is “good enough”, we can start a brand new ID. In case the latter option is chosen, Daniele and I will write a -00 version including just the table of content and what we’d like to be covered in each section. The document will then be handed over to a pool of authors which will bring it till the WG adoption. Hence, we will have a 3 weeks polling starting today. We decided to make it a bit longer than usual because this time the working group is requested to review two drafts instead of one. This mail starts a 3 weeks polling, terminating on September 15th, where we would like the working group to express your preference among: 1. Adopt draft-ietf-ccamp-network-inventory-yang-02 in IVY and evolve it to become the network inventory base model 2. Adopt draft-wzwb-opsawg-network-inventory-management-03 in IVY and evolve it to become the network inventory base model 3. Start a brand new document from scratch as described above In the week after the closure of the polling (between September 18 and 25) we will have an IVY interim meeting to discuss the issues/concerns raised during the polling ( A separate mail will be sent). Thank you, Qiufang and Daniele _______________________________________________ OPSAWG mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
