Re: [OPSAWG] [Inventory-yang] Getting rid of network-hardware-inventory container for straightfoward model alignment that satisfies both hardware inventory needs and generalization/extensibility goals
Hi Alex, all, Thanks for your detailed clarification. I think your suggestion makes a lot of sense to me. An independent NE location model can be extended for various outdoor and indoor scenarios, and the separate network inventory model can apply to more general network scenarios. Thanks, Bo Wu From: Alexander L Clemm Sent: Tuesday, September 12, 2023 2:25 AM To: Wubo (lana) ; maqiufang (A) ; inventory-y...@ietf.org Cc: ivy-cha...@ietf.org; opsawg ; cc...@ietf.org Subject: Re: [Inventory-yang] [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 invento... Hello Bo, all, to your question: With the two inventory models, I was referring to the two models in the two drafts as per the poll, i.e.: (1) draft-ietf-ccamp-network-inventory-yang-02 (ietf-network-hardware-inventory) (2) draft-wzwb-opsawg-network-inventory-management-03 (ietf-network-inventory) To recap the point I was trying to made: I think both models are closer than it may initially appear. The main obstacle to aligning is the top-level container in ietf-network-hardware-inventory, "network-hardware-inventory". This object seems to serve no particular purpose, so could be easily removed. In doing so, "equipment-rooms" and "network-elements" would become top level objects, separable into separate modules (both of which can be specified in the same draft, of course). It will make sense for equipment-rooms to stand on its own anway since this contains _location_ information - this information can of course be referenced by items in the inventory, but the rooms by themselves are not part of the network-hardware-inventory (as the current model seems to suggest) and locations other than rooms are conceivable in some cases. So, not only will removing the top-level container make ietf-network-hardware-inventory facilitate alignment, but it will also arguably result in a "better" model. Looking forward to continued discussions --- Alex On 9/11/2023 2:19 AM, Wubo (lana) wrote: 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
Re: [OPSAWG] [Inventory-yang] Getting rid of network-hardware-inventory container for straightfoward model alignment that satisfies both hardware inventory needs and generalization/extensibility goals
Hello Bo, all, to your question: With the two inventory models, I was referring to the two models in the two drafts as per the poll, i.e.: (1) draft-ietf-ccamp-network-inventory-yang-02 (ietf-network-hardware-inventory) (2) draft-wzwb-opsawg-network-inventory-management-03 (ietf-network-inventory) To recap the point I was trying to made: I think both models are closer than it may initially appear. The main obstacle to aligning is the top-level container in ietf-network-hardware-inventory, "network-hardware-inventory". This object seems to serve no particular purpose, so could be easily removed. In doing so, "equipment-rooms" and "network-elements" would become top level objects, separable into separate modules (both of which can be specified in the same draft, of course). It will make sense for equipment-rooms to stand on its own anway since this contains _location_ information - this information can of course be referenced by items in the inventory, but the rooms by themselves are not part of the network-hardware-inventory (as the current model seems to suggest) and locations other than rooms are conceivable in some cases. So, not only will removing the top-level container make ietf-network-hardware-inventory facilitate alignment, but it will also arguably result in a "better" model. Looking forward to continued discussions --- Alex On 9/11/2023 2:19 AM, Wubo (lana) wrote: 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-managementand 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 *On Behalf Of *Alexander L Clemm *Sent:* Thursday, September 7, 2023 4:59 AM *To:* maqiufang (A) ; inventory-y...@ietf.org *Cc:* ivy-cha...@ietf.org; opsawg ; cc...@ietf.org *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
