[CCAMP] Getting rid of network-hardware-inventory container for straightfoward model alignment that satisfies both hardware inventory needs and generalization/extensibility goals (was: Re: [OPSAWG] [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
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg