Open jccardonar opened 1 week ago
See a similar discussion on how to model these configurations using RFC8348 in Netmod WG list: https://mailarchive.ietf.org/arch/msg/netmod/GSesWMmFyhxBz56UqL0GojgtEoE/
2024-09-18 Base Network Inventory weekly call
The model is quite flexible to support at least three options to model multi-chassis NEs:
ne
chassis (1)
chassis (2)
chassis (3)
ne
chassis (1)
chassis (1)
chassis (2)
ne
stack (1)
chassis (1)
chassis (2)
chassis (3)
The second option is not straightforward (chassis contained within chassis) but can be used to model Optical NE configuration with a main shelve and multiple subtended sub-shelves, in line with ONF TR-547 requirements.
The three options allow expressing different hierarchical relationships between the different chassis and it seems worthwhile keeping this freedom as an vendor specific option.
However, it is useful to provide some clarification (explicitly stating that the second option is also possible) within the I-D.
I do not know why issue https://github.com/ietf-ccamp-wg/ietf-network-inventory/issues/6 has not been transferred to this repository but I have closed it as superseded by this issue and added a reference to the previous issue and discussion in the description of this issue:
Network elements could be grouped into a single "virtual" element that manages all resources of the encompassing different hardware chassis.
In simple words, two chassis, like two or more switches, can be connected and behave as a single one.
This is tackled in rfc8348 with the stack component. It would be nice to have guidelines on how this should be modeled in this new model.
For reference, in one specific implementation of openconfig in this type of system, all interfaces of the child chassis are listed as orphans under /components. There is no reference of the child chassis, or its line cards. For an inventory solution, we do need the actual hardware list.
See also https://github.com/ietf-ccamp-wg/ietf-network-inventory/issues/6