[IVY] Re: Where to define the components list (was RE: Issue related to the need to add contains-child entity to the base inventory model (ietf-network-inventory module))

["Daniele Ceccarelli (dceccare)" <[e-mail]>]

Hi Nigel,

I’m not saying it’s not applicable to whatever environment, I’m wondering what are the blocks that gather inventory information in the network, process it, put it together and expose it. I would expect the NMS/SDN controller to be one of the most common scenarios but not the only one, there are other options, I don’t disagree.

What I’m proposing is exactly what you said below: “We could limit the work today to provide a model for application to the device/controller level and argue that this is always only dealing with assemblies that are installed and can be controlled (and hence relates to the somewhat broken concept of NE).”…but once again, this is a contributor input, I’d like to hear other opinions from the WG.

..and I think your proposal below: “We could perhaps build the component model part (that represents the boards etc.) as an independent model unit that can then augment the NE when applicable but that can augment other structure. “ is not different from mine with the core model and core model ++.

Thanks
Daniele

From: Davis, Nigel <ndavis=[e-mail]>
Sent: Thursday, May 15, 2025 10:39 AM
To: Daniele Ceccarelli (dceccare) <[e-mail]>; Italo Busi <[e-mail]>; Prasenjit Manna (prmanna) <[e-mail]>; Sergio Belotti (Nokia) <[e-mail]>; [e-mail]
Subject: RE: Where to define the components list (was RE: Issue related to the need to add contains-child entity to the base inventory model (ietf-network-inventory module))

Hi,

I was assuming that the model we are building would also be applicable in digital twin, planning, inventory management etc. (i.e., not just at the device/controller level). For planning and any forward-looking capability (including some aspects of digital twin) there is a need to have a view of available physical resources, not just those installed. For repair and inventory management systems, there is an absolute need to know of physical things that are not installed.

We could limit the work today to provide a model for application to the device/controller level and argue that this is always only dealing with assemblies that are installed and can be controlled (and hence relates to the somewhat broken concept of NE). But if we do that, I would like to see us model in such a way that the genuinely physical portion of the model (an NE is not really physical) representing racks, boards etc. is readily detachable from the model of the NE.

We could perhaps build the component model part (that represents the boards etc.) as an independent model unit that can then augment the NE when applicable but that can augment other structure. By this approach we would be enabling future use without excessive scope at this stage. This would be a relatively small change to the model at this stage but would open up significant future opportunity.

Kind regards,

Nigel

From: Daniele Ceccarelli (dceccare) <dceccare=[e-mail]<mailto:dceccare=[e-mail]>>
Sent: 15 May 2025 09:08
To: Italo Busi <[e-mail]<mailto:[e-mail]>>; Davis, Nigel <[e-mail]<mailto:[e-mail]>>; Prasenjit Manna (prmanna) <[e-mail]<mailto:[e-mail]>>; Sergio Belotti (Nokia) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [**EXTERNAL**] RE: Where to define the components list (was RE: Issue related to the need to add contains-child entity to the base inventory model (ietf-network-inventory module))

Hi Italo,

My input as a contributor.
The question to be asked is, where is this model applicable? I would expect this model to be used by an NMS or an SDN controller to export the inventory through its NBI. Why would an NMS or an SDN controller know about spare parts? That’s a piece of information that would most likely come from another source.

One solution could be to have the SDN/NMS use the core model to export what is there in the network and a different source use a core model ++ version to export the spare parts and what is planned to be deployed.
The core model++ would have a structure identical to the core model but only focusing on the spare parts and the planned roll-outs, with the addition of a piece of information saying if a part is installed in the network or not, and if not either say if there is a planned roll-out date or not (in the latter case is a spare part).
No one prevents a single NMS/SDN controller to export both the core model and the core model++.

Would this make sense?
Thanks
Daniele


From: Italo Busi <Italo.Busi=[e-mail]<mailto:Italo.Busi=[e-mail]>>
Sent: Wednesday, May 14, 2025 5:56 PM
To: Davis, Nigel <ndavis=[e-mail]<mailto:ndavis=[e-mail]>>; Prasenjit Manna (prmanna) <[e-mail]<mailto:[e-mail]>>; Sergio Belotti (Nokia) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [IVY] Where to define the components list (was RE: Issue related to the need to add contains-child entity to the base inventory model (ietf-network-inventory module))

Hi Nigel,

I think the following comment is a bit independent from the other comments, so I would like to start a new thread to discuss it:


On network element (device)…  I am concerned that we have bound the component to the device. We will need to deal with components that are in spare holdings and that are being returned to the manufacturer or are still in their box. It is important that the lifecycle of the component is independent of where it is. I think we should remove component from the hierarchy in network element. The network element is a collection of components, a component can remain in the inventory even when it is not in a network element or is moved from one network element to another.

I would like to get more feedbacks from the mailing list if there are requirements to report within the network inventory also components (e.g., boards) which are not installed within a network element

From a design perspective, I would agree with you that moving the list of components outside of the network element would be at least future proof (doing this in a future version of the model would be an NBC change)

What is scaring me about this change is that this will drive requirements to understand in which network element a component is installed as well as to understand which are the components installed into a network elements which, based on previous discussions, would lead to the definition of a lot of redundant leafrefs ☹ (consider that a component can be within another component which is recursively within another component and so on until a component which is within a network element)

Another question: when a component is moved, all its non-FRU child components will moved together with the parent component. What about the FRU sub-components? In other words, can component not being installed in a network element still contain FRU child components?

How should we track the position of a component when not being installed in a network element?

Just my initial thoughts and doubts …

Italo

From: Davis, Nigel <ndavis=[e-mail]<mailto:ndavis=[e-mail]>>
Sent: mercoledì 7 maggio 2025 15:56
To: Prasenjit Manna (prmanna) <[e-mail]<mailto:[e-mail]>>; Italo Busi <[e-mail]<mailto:[e-mail]>>; Sergio Belotti (Nokia) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: Issue related to the need to add contains-child entity to the base inventory model (ietf-network-inventory module)

Hi all,
­­
I have a broader concern regarding ­­slot and also network element. The component is to tightly tied to the network element and the slot is too weakly associated with the component.

On slot… I have talked on the solids/holes (I used the term spaces before as a result of earlier work, but hole is clearer) pattern model. In this a solid thing (circuit pack, chassis etc.) can have holes in it. A slot is a hole. A hole has a lifecycle that is fully dependent on the solid that it is in (the hole cannot be standalone 😊). This pattern model was derived in TM Forum during a process of unification of several models of equipment. It has subsequently been used a the basis for the equipment model in ITU-T G.7711, ONF TR-512 and ONF/LF TAPI. In these models the slot is a subordinate part of the equipment, i.e., part of the data structure of the equipment and not an independent thing.

In the ivy model we currently have slot as a separate component and hence as a separate inventory item. Slot can then have all the properties of other inventory items (serial number etc.). But a slot does not have an independent life and never has a serial number etc. It would appear far more appropriate to have the representation of holes (with its limited set of properties) as a list item in the component where each slot is a member of that list (with a key, as Italo noted).

We can use a generalized term like hole or space or a specific term like slot. I have used hole here, but any other term would do.

Using a rough shorthand this would then be:

- component
   - ids
   - type
   - details
   - occupies-holes [
     - component/hole
   ]
  - has-holes [
    - hole
      - id {this could be the position}
      - type
      - position
      - details
    ]


Changing hole to slot


- component
   - id=A
   - type=chasis
   - details
   - occupies-holes
      - component=X/hole=Y
      - component=X/hole=z
   - has-holes
     - hole
         - id=1
        - type=slot
         - position
         - details
      - hole
        - id=2
        - type=slot
        - position
        - details
….

On network element (device)…  I am concerned that we have bound the component to the device. We will need to deal with components that are in spare holdings and that are being returned to the manufacturer or are still in their box. It is important that the lifecycle of the component is independent of where it is. I think we should remove component from the hierarchy in network element. The network element is a collection of components, a component can remain in the inventory even when it is not in a network element or is moved from one network element to another.

Considering both network element and slot together the model changes to
[cid:[e-mail]262A80]

Here the black “has” relationships are list structures within the component and the “occupies” and “is in” relationships are references.

I have added in component has component for the non-field-replaceable components. Of course, there is a challenge with this model in that it has a recursive list with component lists component. Although this should not be a fundamental issue, it is not achievable in YANG.As the depth of non-fru nesting is probably going to be at most 3, this could be an explicit 3 deep structure instead of a recursive listing. Alternatively, the non-fru could be a referenced independent component, but this would clutter then inventory with items that are not removeable and should not be explicitly listed.

Incidentally, the non-FRU components can have serial number etc. and may also offer slots.

Kind regards,

Nigel



From: Prasenjit Manna (prmanna) <prmanna=[e-mail]<mailto:prmanna=[e-mail]>>
Sent: 07 May 2025 12:56
To: Italo Busi <Italo.Busi=[e-mail]<mailto:Italo.Busi=[e-mail]>>; Sergio Belotti (Nokia) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [**EXTERNAL**] [IVY] Re: Issue related to the need to add contains-child entity to the base inventory model (ietf-network-inventory module)

+1 for make the “parent” data node a list. This will solve the purpose.
IMO, this is a clean approach without defining any new leaf.

Regards,
Prasenjit

From: Italo Busi <Italo.Busi=[e-mail]<mailto:Italo.Busi=[e-mail]>>
Date: Wednesday, 7 May 2025 at 4:50 PM
To: Sergio Belotti (Nokia) <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [IVY] Re: Issue related to the need to add contains-child entity to the base inventory model (ietf-network-inventory module)
Hi Sergio,

Thanks for triggering this discussion on the list. Let me add few additional thoughts of mine hoping to trigger more feedbacks from the WG

I do strongly prefer design choices that avoid duplicating information in the YANG DS as much as possible, so my preference is not to add the “contains-child” information to the base inventory model

I do not see other scenarios that the current model (specifying only one parent and one parent-rel-pos) cannot address other than multi-slot boards, so my preference is to find a solution to address this use case avoiding adding redundant information

The alternative solution proposed during the previous weekly call (i.e., defining the “parent” data node as a list) looks to me a good starting point but could be improved

For example, we have not discussed which key to use for the list since both the parent and the parent-rel-pos data nodes are optional and I see scenarios where it is useful to have both optional

Considering that for the multi-slot boards, the parent-rel-pos is not needed, one possibility is to update the definition of the parent data node to be a leaflist and condition the presence of the parent-rel-pos only when the parent leaflist has  no more than one element

I would avoid defining a list with no key since I am not sure that adding the key in a future version to support configuration would be a BC change

My 2 cents

Italo

From: Sergio Belotti (Nokia) <[e-mail]<mailto:[e-mail]>>
Sent: mercoledì 23 aprile 2025 16:41
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; Aihua Guo <[e-mail]<mailto:[e-mail]>>; Italo Busi <[e-mail]<mailto:[e-mail]>>; Wubo (lana) <[e-mail]<mailto:[e-mail]>>; Davis, Nigel <[e-mail]<mailto:[e-mail]>>; Oscar González de Dios <[e-mail]<mailto:[e-mail]>>; Victor Lopez (Nokia) <[e-mail]<mailto:[e-mail]>>
Subject: Issue related to the need to add contains-child entity to the base inventory model (ietf-network-inventory module)

RFC8348 provides for any component a data node called “parent” representing the component that physically contains this component, the “parent-rel-pos” representing the relative position with respect all the sibling components,  and also “contains- child” data node representing the name of the contained component.
In our IVY ietf-network-inventory module we also have parent and parent-rel-pos data nodes and  we are wondering if we should align with RFC8348 adding contains-child as well.
The problem seems that the presence of contains-child provides duplication of information.

Let's consider for example a chassis with four slots. This is the way it will be represented with the current YANG model:

Let’s
- chassis-A
- slot-1
  - parent: chassis-A
  - parent-rel-pos: 1
- slot-2
  - parent: chassis-A
  - parent-rel-pos: 2
- slot-3
  - parent: chassis-A
  - parent-rel-pos: 3
- slot-4
  - parent: chassis-A
  - parent-rel-pos: 4

n this case, the list of children component contained by chassis-A is duplicated information:

- chassis-A
  - contains-child: [
    - slot-1
    - slot-2
    - slot-3
    - slot-4
  ]

But during our weekly calls it was also raised the use case in which a board can occupy two slots (e.g. slot 2 and slot 3 in our example).
In this case without the contained children information it seems difficult to model this scenario.

According to RFC8348, only one parent would be selected:

- module-B
  - parent: slot-2

This information is not sufficient to understand that module-B is occupying two slots nor which slots in the list (e.g. the two slots are slot 2 and slot 3 or slot 1 and slot 2).

In this case, reporting the contained children would resolve the ambiguity:

- chassis-A
  - contains-child: [
    - slot-1
    - slot-2
    - slot-3
    - slot-4
  ]
- slot-1
  - parent: chassis-A
  - parent-rel-pos: 1
- slot-2
  - parent: chassis-A
  - parent-rel-pos: 2
  - contains-child: [ module-B ]
- slot-3
  - parent: chassis-A
  - parent-rel-pos: 3
  - contains-child: [ module-B ]
- slot-4
  - parent: chassis-A
  - parent-rel-pos: 4
- module-B
  - parent: slot-2

During the last call we had before Easter, an alternative solution proposed was to make the “parent” data node a list.
In this case in our example we would have :

- module-B
  - parent: [ slot-2, slot-3 ]

We would solve the problem of double slots occupied by module-B without the need to introduce “contains-child”.

While we probably need more time to investigate  on this alternative solution to solve the identified use case, more analysis would be also considered if there are other scenarios which requires reporting the “contains-child” in addition to the one identified in this open issue.

We’d like to trigger some discussion on the IVY mailing list to get more feedback and suggestion about this topic.

Thanks

Sergio (on behalf of other co-authors/contributors)