[IVY] Re: [External] Re: Base inventory for logical chassis [Commercial - Anyone]

["Davis, Nigel" <[e-mail]>]

Hi Brad,

How about a lightweight power network model (using RFC8345 topology) with termination points representing the power supplies etc. Thoughts welcome.

Nigel

From: Brad Peters <bradpeters=[e-mail]>
Sent: 12 May 2025 00:19
To: Davis, Nigel <[e-mail]>; Italo Busi <[e-mail]>; Phil Bedard <[e-mail]>; Tony Li <[e-mail]>; Gabriele Galimberti <[e-mail]>
Cc: Daniele Ceccarelli (dceccare) <[e-mail]>; [e-mail]
Subject: [**EXTERNAL**] Re: [External] [IVY] Re: Base inventory for logical chassis [Commercial - Anyone]

Hi Nigel,

I potentially agree that it probably needs to be somewhere but where is the question. If you look at a use case where potentially a NOC operator receives events where all even chassis in a multichassis pizza style switch are off line it probably indicates that the power rail has failed. You could probably make that assumption but that would also imply that the operator has the knowledge of the central office build. Assumptions could result in rolling the wrong trucks with incorrect equipment to enable the rectification. That is what was proceeding through my mind. Functionally every second chassis has a common power rail. How do the events from the equipment and the inventory correlate such that an assumption is not required? ie. ideally you want system to system automation and no manual human intervention.

I was just placing it out there for consideration as to where it should exist......


Cheers.



Brad

________________________________
From: Davis, Nigel <ndavis=[e-mail]<mailto:ndavis=[e-mail]>>
Sent: Friday, 9 May 2025 7:11 AM
To: Brad Peters <[e-mail]<mailto:[e-mail]>>; Italo Busi <[e-mail]<mailto:[e-mail]>>; Phil Bedard <[e-mail]<mailto:[e-mail]>>; Tony Li <[e-mail]<mailto:[e-mail]>>; Gabriele Galimberti <[e-mail]<mailto:[e-mail]>>
Cc: Daniele Ceccarelli (dceccare) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: [External] [IVY] Re: Base inventory for logical chassis [Commercial - Anyone]


EXTERNAL SENDER – Be cautious opening Links and Attachments

Hi Brad,



Thanks for this. This is indeed one of the many resilience strategies. It is only fully visible from the outside of the chassis and, as you allude to, is power function resilience as opposed to physical resilience (all resilience is functional). Pulling back a bit again, I don’t think ivy should be addressing this as it is not an “inventory” consideration, but I do think it should be addressed somewhere (and this should include the in chassis power redundancy (which we touched on in TR-512/G.7711)).



Thoughts?



Regards,



Nigel



From: Brad Peters <bradpeters=[e-mail]<mailto:bradpeters=[e-mail]>>
Sent: 08 May 2025 21:29
To: Davis, Nigel <[e-mail]<mailto:[e-mail]>>; Italo Busi <[e-mail]<mailto:[e-mail]>>; Phil Bedard <[e-mail]<mailto:[e-mail]>>; Tony Li <[e-mail]<mailto:[e-mail]>>; Gabriele Galimberti <[e-mail]<mailto:[e-mail]>>
Cc: Daniele Ceccarelli (dceccare) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [**EXTERNAL**] Re: [External] [IVY] Re: Base inventory for logical chassis [Commercial - Anyone]



HI Nigel,



Just noting the response below regarding modelling resiliency at a functional level rather than physical, in many installations of multi-chassis style routers/switches in a central office environment, the power for each chassis is taken from a different power run within the facility. This reduces the chance of a single failure effecting the complete operations. I suspect this could be considered a physical resiliency model. From a functional aspect dual redundant supplies in modular equipment, as you suggest provides resilience within the chassis.



Just one of the options I think you were referring to.



Cheers.



Brad

________________________________

From: Davis, Nigel <ndavis=[e-mail]<mailto:ndavis=[e-mail]>>
Sent: Thursday, 8 May 2025 6:49 PM
To: Italo Busi <Italo.Busi=[e-mail]<mailto:Italo.Busi=[e-mail]>>; Phil Bedard <[e-mail]<mailto:[e-mail]>>; Tony Li <[e-mail]<mailto:[e-mail]>>; Gabriele Galimberti <[e-mail]<mailto:[e-mail]>>
Cc: Daniele Ceccarelli (dceccare) <dceccare=[e-mail]<mailto:dceccare=[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [External] [IVY] Re: Base inventory for logical chassis



EXTERNAL SENDER – Be cautious opening Links and Attachments

Hi,



Stepping back a bit (yesterday I was buried in the detail), there are further complexities. There are at least two considerations for main: (1) core telecom functions and (2) management/control functions. It is possible that one chassis is main from the perspective of (1) but two chassis are equal for (2).



When we looked at the equivalent within a chassis during the development of the physical model for TR-512 in ONF, when considering “equipment” protection (which is actually not protection of the physical, but protection of the functional) we recognised that there were at least four functions (telecom, management/control, power and timing) and that these could each be partitioned and could each use different resilience strategies (active/standby (with hot and cold versions of standby), active/active, load sharing etc.). We noted that different partitions of a particular function type could use a different strategy. We concluded that the resilience needed to be modelled at the functional level. In some trivial cases it could be represented as a coarse Boolean, but… The work in progress discussion on this is covered in ONF TR-512.6 (Physical) and the corresponding Annex F in ITU-T G.7711 (F2.2 in the latest).



I suspect the power and timing tend to be resilient within a chassis as opposed to between, but there is no fundamental reason why the resilience could not also be distributed between chassis.



One final thought, if we are doing raw physical inventory, the idea of a main shelf is not (very) relevant. It is only when we start to consider functionality (e.g., how we communicate about the details of a shelf (management/control) etc.) or physical assembly (which is more about cabling and how the chassis is mounted (order etc.)) that the biases start to emerge. We need to be very careful not to stray into functional modelling (although we do need to do a model of management/control and of power and of functional resilience for these two and functional resilience of the functions that support the telecoms capabilities – none of these are ivy in my opinion). Physical assembly may be more relevant to ivy, but that is then not about main shelf, but physical topology.



Regards,



Nigel



From: Italo Busi <Italo.Busi=[e-mail]<mailto:Italo.Busi=[e-mail]>>
Sent: 08 May 2025 07:03
To: Phil Bedard <[e-mail]<mailto:[e-mail]>>; Tony Li <[e-mail]<mailto:[e-mail]>>; Gabriele Galimberti <[e-mail]<mailto:[e-mail]>>
Cc: Daniele Ceccarelli (dceccare) <dceccare=[e-mail]<mailto:dceccare=[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [**EXTERNAL**] [IVY] Re: Base inventory for logical chassis



Phil, Tony,



Thanks for following up on this discussion



In the previous discussions we analyzed cases where the main chassis is configured by the operator and where the main chassis is automatically selected by some process within the NE and noted that the boolean flag can cover both scenarios since it is reporting which is the main shelf regardless of how it is configured/selected



I think it also works when the main chassis is selected dynamically (including the active/standby case described by Phil): in this case, the Boolean flag is changing value dynamically within the operational DS to reflect the changes in the NE



I was not aware of the active/active configuration described by Phil but I agree that in this case, more than one chassis can have the Boolean flag set to True. We may consider this when writing the draft text not to assumed that only one chassis can have mail flag set to True



I was also not aware of the no main chassis configuration described by Tony but since the mail flag is optional, I think that in these cases the main flag may simply be omitted



Italo



From: Phil Bedard <[e-mail]<mailto:[e-mail]>>
Sent: mercoledì 7 maggio 2025 18:54
To: Tony Li <[e-mail]<mailto:[e-mail]>>; Gabriele Galimberti <[e-mail]<mailto:[e-mail]>>
Cc: Italo Busi <Italo.Busi=[e-mail]<mailto:Italo.Busi=[e-mail]>>; Daniele Ceccarelli (dceccare) <dceccare=[e-mail]<mailto:dceccare=[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [IVY] Re: Base inventory for logical chassis



Similar to Tony’s second scenario, there exists equipment deployments where you have active/standby parent nodes with a sub-shelf (or better known as a “satellite”) connected to both of those parent nodes.  Today using proprietary models, the sub-shelf/satellite inventory only shows up on the active parent node. The “main” node will change on active/standby switchover.



My take is the flag would get set/cleared based on whichever node was the active parent.  How that gets detected and populated in the model is outside the scope of the inventory model IMO, but is a use case to keep in mind.



A case where you have an active/active configuration, both nodes would be “main” nodes in the context of the sub-shelf/satellite.



Thanks,

Phil



From: Tony Li <[e-mail]<mailto:[e-mail]>> on behalf of Tony Li <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, May 7, 2025 at 07:45
To: Gabriele Galimberti <[e-mail]<mailto:[e-mail]>>
Cc: Italo Busi <Italo.Busi=[e-mail]<mailto:Italo.Busi=[e-mail]>>, Daniele Ceccarelli (dceccare) <dceccare=[e-mail]<mailto:dceccare=[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [IVY] Re: Base inventory for logical chassis



How does one model a multi-chassis system where there is no ‘main’ chassis?  Or where the concept of ‘main’ relocates dynamically?



T





On May 7, 2025, at 5:36 AM, Gabriele Galimberti <[e-mail]<mailto:[e-mail]>> wrote:



I agree with and sustain the Italo proposal.



Having a boolean flag is the best indication to identify the chassis role.



Regards,



Gabriele



Da: Italo Busi <Italo.Busi=[e-mail]<mailto:Italo.Busi=[e-mail]>>
Data: mercoledì 7 maggio 2025 alle ore 14:06
A: "Daniele Ceccarelli (dceccare)" <dceccare=[e-mail]<mailto:dceccare=[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Oggetto: [IVY] Re: Base inventory for logical chassis



Thanks Daniele



In order to move forward the work, my proposal is to start adding the information of which chassis is the main chassis as a Boolean flag



Anybody who thinks it is outside the scope of the base inventory model, would have time before WG LC to raise a comment and propose to move the definition elsewhere (indicating also where it is better moved)



Anybody who thinks it should be an enumeration, would have time before WG LC to raise a comment and propose the list of the possible enumeration values to be considered



Italo



From: Daniele Ceccarelli (dceccare) <dceccare=[e-mail]<mailto:dceccare=[e-mail]>>
Sent: lunedì 28 aprile 2025 17:43
To: Italo Busi <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: [IVY] Re: Base inventory for logical chassis



Hi Italo,



Trying to revamp the discussion with my inputs.

Please see in line.



Thanks

Daniele



From: Italo Busi <Italo.Busi=[e-mail]<mailto:Italo.Busi=[e-mail]>>
Sent: Thursday, April 17, 2025 10:10 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [IVY] Re: Base inventory for logical chassis



Hi all,



We have had some follow-up discussion focusing on the hierarchical scenario which is quite common in optical networks



The term sub-shelf seems more applicable to the scenario in slide 13 of the IETF 122 since in this case it represents a part of the entire shelf.



Considering the concerns raised during the IETF 122 meeting on the scenario in slide 13 and that modelling this scenario does not seem a blocking issue for the WG LC of the base inventory model, we would suggest to create a new issue to address this scenario and mark it as an issue candidate for future revision or augmentation.



Instead, in slide 14, there are different shelves with different hierarchical role (e.g., main shelf and subtended shelves). The terminology of main shelf/chassis and subtended shelf/chassis seems more appropriate for describing this scenario.



This scenario can be modelled as a flat list of chassis (numbered as 1, 2, 3, …) as already discussed for the stacked chassis scenarios (the cables between them can be reported in the passive inventory model).



The different chassis have different role in the hierarchy where the main shelf is the chassis/shelf is the one providing access to the management system.



Is this approach acceptable by the IVY WG?

[[DC]] sounds good to me.



We have also some doubts about the modelling of the main/subtended chassis we would like to get feedbacks from the WG:



  *   is there a need to report, within the network inventory, which chassis is the main chassis?

[[DC]] I would say it doesn’t hurt. In the sense that it should be possible to say which is the main chassis, but it’s not mandatory to have one.



  *   if yes, how to represent this information: as a flag indicating the main chassis or as a role enumeration (main, subtended) indicating the role of each chassis?

[[DC]] if there are multiple roles I’d go for the enumeration, but the only one that comes to my mind is the main one, hence the flag should be enough.



It has been noted that in the optical networks, the main chassis is usually configured by the operator while, from previous discussion, it seems that in the Ethernet switched networks the main chassis is usually automatically selected by some process within the NE. However, this difference is not inherently technology-specific but just common implementation options in different network environements. We think that the models should support both implementation options regardless of the technolog.



Note that this difference would have no impact on the first version of the base inventory model since everything is RO (the configuration of the main shelf can only be performed at device level and at the network level). However, this difference may become relevant in a future RFC updating the first version with some RW capability.



Thanks, Italo (on behalf of co-authors/contributors)



From: Joe Clarke (jclarke) <[e-mail]<mailto:[e-mail]>>
Sent: venerdì 21 marzo 2025 02:29
To: Italo Busi <Italo.Busi=[e-mail]<mailto:Italo.Busi=[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [IVY] Re: Base inventory for logical chassis



Thanks, Italo.



From: Italo Busi <Italo.Busi=[e-mail]<mailto:Italo.Busi=[e-mail]>>
Date: Thursday, March 20, 2025 at 10:49
To: Joe Clarke (jclarke) <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: Base inventory for logical chassis

Hi Joe,



If I understand correctly your example, they can be reported in the network inventory as a single NE containing two chassis (chassis in position 1 is the "Switch 1 Chassis" and the chassis in position 2 is the "Switch 2 Chassis") or as a single NE containing one stack component which contains two chassis:



ne

  chassis (parent-rel-position=1)

  chassis (parent-rel-position=2)



ne

  stack (parent-rel-position=1)

    chassis (parent-rel-position=1)

    chassis (parent-rel-position=2)



It seems that reporting the stack component is not needed (even if not precluded) in this specific case since the fact that the two chassis components are under the same NE implies that they behaves as a single logical switch. The stack components can be more useful when there is a need to report more than one group of chassis (stacks) within the same network element



[JMC] Yeah, I think you’re right.  In this case, option one feels more correct.



Our plan is to provide some examples/guidelines in the draft about this scenario



We have not reported this scenario in the slides because we had no issues to discuss but maybe it would have been better to add one slide clarifying that in this scenario we have no issue other than writing text to describe the example and the guidelines



Do you think that this proposal addresses the scenario you have described?



The doubts we have is about multi-chassis configurations where there is some hierarchy with one chassis begin the main chassis/shelf and the other being secondary chassis/sub-shelves.



[JMC] Got you.  However, even in this case, from a redundancy standpoint, there is one primary and one secondary chassis.  I don’t know that bit needs to be reflected in inventory, though.  Maybe even in your multi-chassis case, you don’t need to reflect hierarchy as much as you need to reflect the inventory.  The hierarchy can be left to other layers (like redundancy).



Joe



At the beginning, we were thinking to report this configuration as one NE containing one chassis component representing the main shelf which contains multiple chassis components representing the sub-shelves:



ne

  chassis (parent-rel-position=1)

    chassis (parent-rel-position=1)

    chassis (parent-rel-position=2)



However, we later discovered that sometimes the term sub-shelf can be interpreted as a logical partitioning of the slots within a single chassis.



So now, we have the doubt about whether the configuration above is reporting three physical chassis where one is the main shelf and the other two are the sub-shelves or a single physical chassis where its slots are logically partitioned into two sub-shelves.



I think this summarizes the discussion we have had in the base inventory weekly calls, as reported in github:



https://github.com/ietf-ivy-wg/network-inventory-yang/issues/64 [github.com]<https://urldefense.com/v3/__https:/github.com/ietf-ivy-wg/network-inventory-yang/issues/64__;!!OSsGDw!K5eS7ntiS6WFcCL0YbzHnA4cINwAsfKwphs0rqu2q-Ff8glxzpa9V_-YowJviiYb0S7_OYHFU5BpObQQKNY0h6sV_aA$>



Italo



From: Joe Clarke (jclarke) <jclarke=[e-mail]<mailto:jclarke=[e-mail]>>
Sent: mercoledì 19 marzo 2025 04:23
To: [e-mail]<mailto:[e-mail]>
Subject: [IVY] Base inventory for logical chassis



I almost came to the mic for the shelf/sub-shelf discussion, but I don’t know the best way to solve this.  To give you a concrete example, here at the IETF, our core switch is actually two switches (two Cisco Catalyst 9500s) in a virtual switch shelf.  That is, even though they are two, fully functional, fully FRUable switches, they behave as one chassis (in this configuration).



When that happens, we see this for “show inventory”:



NAME: "Switch 1 Chassis", DESCR: "Cisco Catalyst 9500 Series Chassis"

PID: C9500-48Y4C       , VID: V02  , SN: FDO25…

…

NAME: "Switch 2 Chassis", DESCR: "Cisco Catalyst 9500 Series Chassis"

PID: C9500-48Y4C       , VID: V02  , SN: FDO25…



The interfaces get renumbered so that those on switch 1 are Twe1/X/Y and those on switch 2 are Twe2/X/Y.



How would the base inventory model handle this?  I think that in this case, if I were to do a <get-data> on this chassis, I’d get an inventory set that would reflect the logical nature of the chassis as if this were a modular chassis with different switch “linecards”.  Interfaces/ports would be named as I would find them in the ietf-interfaces module.  Is that what is being proposed in the base inventory?



Joe





--
Inventory-yang mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>