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 <opsawg-boun...@ietf.org> *On Behalf Of *Alexander L Clemm
*Sent:* Thursday, September 7, 2023 4:59 AM
*To:* maqiufang (A) <maqiufang1=40huawei....@dmarc.ietf.org>;
inventory-y...@ietf.org
*Cc:* ivy-cha...@ietf.org; opsawg <opsawg@ietf.org>; 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
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