ietf-ivy-wg / network-inventory-yang

Other
1 stars 3 forks source link

How would this work with a rfc8348 stack? #64

Open jccardonar opened 1 week ago

jccardonar commented 1 week ago

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

italobusi commented 5 days 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/

italobusi commented 4 days ago

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.

italobusi commented 4 days ago

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:

See also ietf-ccamp-wg/ietf-network-inventory#6