Re: [CCAMP] [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 inventory base model)

[Alexander L Clemm <[e-mail]>]

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 <[e-mail]> *On Behalf Of *Alexander L Clemm
> *Sent:* Thursday, September 7, 2023 4:59 AM
> *To:* maqiufang (A) <maqiufang1=[e-mail]>; 
> [e-mail]
> *Cc:* [e-mail]; opsawg <[e-mail]>; [e-mail]
> *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 15^th
>     ,  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
>
>     [e-mail]
>
>     https://www.ietf.org/mailman/listinfo/opsawg
>