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
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
