search

ietf-ccamp-wg / ietf-network-inventory

3 stars 5 forks source link

Management of NEs with multiple racks #7

Closed italobusi closed 1 year ago

italobusi commented 3 years ago

Evaluate whether there is a requirement to manage NEs composed by multiple racks and how to manage them.

italobusi commented 3 years ago

Possible solution using the approach in ietf-ccamp-wg/ietf-network-inventory#2 (assuming that no rack and no shelf is defined for the top-level component):

image

Co-authored-by: agva123 agva123@gmail.com

italobusi commented 2 years ago

Network Inventory weekly call (October 6, 2021)

The requirement to support NEs with multiple racks has been confirmed

There is also a requirement to support NEs with multiple shelves on different racks

The example in https://github.com/italobusi/ietf-network-inventory/issues/7#issuecomment-903087782 seems not correct: to be reviewed and fixed

italobusi commented 2 years ago
  • [x] @agva123 @italobusi Check how to support NEs with multiple racks as well as NEs with multiple shelves on different racks and fix the example
components
  - stack
    // position: ne
    children:
    - stack-1
    - stack-2
  - stack-1
    parent: stack
    parent-position: 1
    // position: ne/r=1
    children:
    - shelf-1-1
    - shelf-1-2
  - shelf-1-1
    parent: stack-1
    parent-position: 1
    // position: ne/r=1/sh=1
  - shelf-1-2
    parent: stack-1
    parent-position: 2
    // position: ne/r=1/sh=2
  - stack-2
    parent: stack
    parent-position: 2
    // position: ne/r=2
    children:
    - shelf-2-1
  - shelf-2-1
    parent: stack-2
    parent-position: 1
    // position: ne/r=2/sh=1

Same solution if the NE contains shelves from multiple racks

Co-authored-by: agva123 agva123@gmail.com Co-authored-by: italobusi italo.busi@gmail.com

italobusi commented 2 years ago

Network Inventory weekly call (October 13, 2021)

In the RFC8348 there is no rack component type. The stack is a logical combination of multiple shelves in the same or different racks.

Jeff: could be interested to have some examples to understand what they had in mind

There is some confusion between the stack and the rack definition

General rules when rack and shelves are reported:

Updated example:

components
  - network-element
    class: stack
    // position: ne-name
    children:
    - rack-1
    - rack-2
  - rack-1
    class: stack
    parent: network-element
    parent-position: 1
    // position: ne-name/r=1
    children:
    - shelf-1-1
    - shelf-1-2
  - shelf-1-1
    class: chassis
    parent: rack-1
    parent-position: 1
    // position: ne-name/r=1/sh=1
  - shelf-1-2
    class: chassis
    parent: rack-1
    parent-position: 2
    // position: ne-name/r=1/sh=2
  - rack-2
    class: stack
    parent: network-element
    parent-position: 2
    // position: ne-name/r=2
    children:
    - shelf-2-1
  - shelf-2-1
    class: chassis
    parent: rack-2
    parent-position: 1
    // position: ne-name/r=2/sh=1

Note: based on the general rule, the example of issue ietf-ccamp-wg/ietf-network-inventory#6 could be updated as follow, when reporting rack and shelf:

components
  - network-element
    class: stack
    // position: ne-name
    children:
    - rack-1
  - rack-1
    class: stack
    parent: network-element
    parent-position: 1
    // position: ne-name/r=1
    children:
    - shelf-1
  - shelf-1
    class: chassis
    parent: rack-1
    parent-position: 1
    // position: ne-name/r=1/sh=1
    children:
    - sub-shelf-1-1
    - sub-shelf-1-2
    - sub-shelf-1-3
  - sub-shelf-1-1
    class: chassis
    parent: shelf-1
    parent-position: 1
    // position: ne-name/r=1/sh=1/s_sh=1
  - sub-shelf-1-2
    class: chassis
    parent: shelf-1
    parent-position: 2
    // position: ne-name/r=1/sh=1/s_sh=2
    children:
    - sub-shelf-1-2-1
  - sub-shelf-1-2-1
    class: chassis
    parent: sub-shelf-1-2
    parent-position: 1
    // position: ne-name/r=1/sh=1/s_sh=2/s_sh=1
  - sub-shelf-1-3
    class: chassis
    parent: shelf-1
    parent-position: 3
    // position: ne-name/r=1/sh=1/s_sh=3

It has been noted that reporting the rack (as well as the shelf contained in it) number in this case is optional. An alternative approach is to report directly starting from the shelf-1 as the root:

components
  - shelf-1
    class: chassis
    // position: ne-name
    children:
    - sub-shelf-1-1
    - sub-shelf-1-2
    - sub-shelf-1-3
  - sub-shelf-1-1
    class: chassis
    parent: shelf-1
    parent-position: 1
    // position: ne-name/s_sh=1
  - sub-shelf-1-2
    class: chassis
    parent: shelf-1
    parent-position: 2
    // position: ne-name/s_sh=2
    children:
    - sub-shelf-1-2-1
  - sub-shelf-1-2-1
    class: chassis
    parent: sub-shelf-1-2
    parent-position: 1
    // position: ne-name/s_sh=2/s_sh=1
  - sub-shelf-1-3
    class: chassis
    parent: shelf-1
    parent-position: 3
    // position: ne-name/s_sh=3
italobusi commented 1 year ago

2023-02-15 Network Inventory weekly call

italobusi commented 1 year ago

[x] @italobusi @YuChaode Check whether these examples are already covered with the examples in Examples of VDF scenarios #55

While reviewing the examples in https://github.com/ietf-ccamp-wg/transport-nbi/issues/111, I am not sure we have a common understanding about the statement "Rack belongs to NE"

IMHO, there is a difference between a rack that belongs to a NE (single-rack or multi-rack NE) and the cases where all the shelves of a multi-shelf NE are (accidentally) located on the same rack(s) and fully it/them

I have prepared few slides to describe my thoughts about this difference, for further discussion/review:

multi-rack-NE-questions-00.pptx

aguoietf commented 1 year ago

In my view, A rack belongs to a NE == All shelves on that rack belong to the same NE, and the rack is not shared by other NEs. If you allow multiple NEs to share the same rack under such cases, then how can one find all the shelves on that rack that actually belong to this NE, if the NE only points to the rack? This applies to both the cases for single-rack NE and multi-rack NE.

Or maybe I missed something?

On Mon, Feb 27, 2023 at 2:00 PM italobusi @.***> wrote:

[x] @italobusi https://github.com/italobusi @YuChaode https://github.com/YuChaode Check whether these examples are already covered with the examples in Examples of VDF scenarios ietf-ccamp-wg/transport-nbi#111 https://github.com/ietf-ccamp-wg/transport-nbi/issues/111

While reviewing the examples in ietf-ccamp-wg/transport-nbi#111 https://github.com/ietf-ccamp-wg/transport-nbi/issues/111, I am not sure we have a common understanding about the statement "Rack belongs to NE"

IMHO, there is a difference between a rack that belongs to a NE (single-rack or multi-rack NE) and the cases where all the shelves of a multi-shelf NE are (accidentally) located on the same rack(s) and fully it/them

I have prepared few slides to describe my thoughts about this difference, for further discussion/review:

— Reply to this email directly, view it on GitHub https://github.com/ietf-ccamp-wg/ietf-network-inventory/issues/7#issuecomment-1446888551, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATZSF5GGSRXNKTQTYWMYJ4LWZT2VLANCNFSM5CRU7YYA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

italobusi commented 1 year ago

2023-04-26 Network Inventory weekly call

Slides from Italo: https://github.com/ietf-ccamp-wg/ietf-network-inventory/files/10843102/multi-rack-NE-questions-00.pptx

Nigel: there are examples of multi-rack NEs in the old switching technologies. There are also cases where a NE is delivered as a single rack. The key issue is whether the NE has details information about the rack: in particular if the rack has some circuitry embedded in the rack with some serial-number

There are cases where also the chassis is not part of the NEs where multiple NEs can be hosted in the same chassis: in this case, the NE will not know in which slot it is plugged in

We need to be careful in order not to overlay constraint the inventory model

Detectable information is information that can be checked by the NE (e.g., the slot a board is located within a shelf that belongs to the NE) while non-detectable information is information that cannot be checked by the NE (e.g., the room location) and the boundary may vary depending upon the specific construction of the NE (note that the boundary can also be different if the same type of NE is deployed differently)

We can discuss next week how this flexible structure has been partly supported in TAPI and investigate even further improvements

Italo: maybe it is better to decouple the splitting based on the type of NE to avoid proliferation of ways to manage the same NE type depending the way it is installed. Some additional information can be added to the information that is not always detectable to indicate if it has been detected or not

Sergio: can we say that what is detectable can be subject of software updated?

Maybe the difference could be between what is detectable by the software internal information and what can be detectable only through external information if available

italobusi commented 1 year ago

Slides updated based on the discussion on 2023-04-26: multi-rack-NE-questions-01.pptx

sergiobelotti commented 1 year ago

Slides updated based on the discussion on 2023-04-26: multi-rack-NE-questions-01.pptx

  • slide 2 updated with the option to indicate r=1 as the rack location
  • slide 3 added with possible changes to the model to address the comments discussed during the call

@italobusi What is the meaning of green value (e.g. in slide 3 r=2 ) vs. the red one (e.g. same slide 3 rack 1-1) ? thanks.

italobusi commented 1 year ago

@italobusi What is the meaning of green value (e.g. in slide 3 r=2 ) vs. the red one (e.g. same slide 3 rack 1-1) ? thanks.

I am struggling with the terminology to properly describe the legenda

The green values are the "component location" within the network-element (following the r/sh/slot/port string pattern while the red values are the "relative position" of e.g., the rack within the room (row and column) or the shelf within the rack (as shown in the slides presented at IETF 116)

sergiobelotti commented 1 year ago

@italobusi What is the meaning of green value (e.g. in slide 3 r=2 ) vs. the red one (e.g. same slide 3 rack 1-1) ? thanks.

I am struggling with the terminology to properly describe the legenda

The green values are the "component location" within the network-element (following the r/sh/slot/port string pattern while the red values are the "relative position" of e.g., the rack within the room (row and column) or the shelf within the rack (as shown in the slides presented at IETF 116)

@italobusi I see your problem ! but your clarification is completely fine with me. Maybe saying green --> component location (e.g. within Network Element) , red --> relative position (with respect parent component e.g. rack for shelf,, equipment room for rack )

italobusi commented 1 year ago

2023-05-10 Network Inventory weekly call

Slides reviewed and updated during the discussion: multi-rack-NE-questions-02

The detailed changes to the model needs further discussion pending confirmation of the requirements to be addressed

italobusi commented 1 year ago

2023-05-24 Network Inventory weekly call

[x] Italo: check with the operators if there are requirements to manage cases where the rack belongs to the NE and where the shelf does not belong to the NE

Jeff: for me the rack is not part of the NE but the NE can be spread over multiple racks

Nigel: I have see a variety of equipment types

The difference between the left and right figures in slide 2 of multi-rack-NE-questions-02 is that in the right figure the NE owns the rack and it is aware of the rack while on the left figure the NE is not aware of the fact that its shelves are located on the same rack

Fabio: in the cases where the rack belongs to the NE, the rack contains only one shelf and not multiple shelves

Nigel: better not to restrict the model and define a list which can have only one element

Phil: sometimes in a multi-chassis system there is a logical rack identifier which is arbitrary and not related with the physical rack location

As a consequence the "r=1" string in the location string does not necessarily mean that the rack belongs to the NE but it may mean that the shelf is associated with a logical rack. This 'rack' actually correspond with the component stack in RFC8348 which can be either a physical or a logical grouping of chassis.

Conclusion: no need to have an association between the rack physical element and the stack NE component of a network-element. The association can still be kept between the shelf physical element and the chassis NE component as in the current model.

Slides updated based on the feedbacks of this call: multi-rack-NE-questions-03.pptx

Need to further discuss:

YuChaode commented 1 year ago

2023-06-28 weekly call: The pizza box is modeled as a chassis. We need to provide some text description in the document to indicate that equipment-room and rack are optional, so that the enterprise scenario can be satisfied. the text is suggested to provided in the new update version of document. the pizza box scenario can be closed.

the case of a single-board NE is not a common scenario. we can close this issue, and may re-open this issue when needed.