Structure for location/position information

[italobusi]

Check whether uint8 is sufficient for rack/shelf/slot/port identification or a longer unsigned integer type should be used instead

[italobusi]

This was the proposal in issue #1 to manage the position within the NE:

      +--ro position
      |  +--ro ne-name        string
      |  +--ro rack?          uint8
      |  +--ro shelf?         uint8
      |  +--ro sub-shelf*     uint8   // when ../shelf
      |  +--ro slot?          uint8
      |  +--ro sub-slot*      uint8   // when ../slot
      |  +--ro port?          uint8   // when (not ../slot and not ../shelf and
      |                            //       not ../rack) or (../slot)

[italobusi]

2022-05-25 Network Inventory weekly call

• [ ] @aguoietf , @sergiobelotti , @jbouqui153 : provides a proposal for the location/position information, taking into account that it should be generic and not applicable only to optical NEs

[sergiobelotti]

2022-05-25 Network Inventory weekly call

• [ ] @aguoietf , @sergiobelotti , @jbouqui153 : provides a proposal for the location/position information, taking into account that it should be generic and not applicable only to optical NEs

OpenConfig has a string position but it seems to exploit on parent and child pointer (leafref) to show the structure of all the components in the node and a the containments.

[italobusi]

2022-07-06 Network Inventory weekly call

• @aguoietf , @sergiobelotti , @jbouqui153 : provides a proposal for the location/position information, taking into account that it should be generic and not applicable only to optical NEs

The proposal for IETF 114 is to replace the location container with a free-form string:

OLD

                  +--ro location
                  |  +--ro equipment-room-name?   leafref
                  |  +--ro ne-name?               leafref
                  |  +--ro rack-number?           leafref
                  |  +--ro chassis-index?         uint16
                  |  +--ro slot-index?            uint16
                  |  +--ro port-index?            uint16

NEW

                  +--ro location                  string

The reason is that a free-form string has more flexibility than a pattern like "/ne=\[/r=][/sh=[/s_sh= …]][[/sl=[/s_sl= …]][/p= …]]" hich is common in optical networks but not sure it applies to any technology

The need to report the location information versus inferring it from the parent information (to updated with some index value) should be further discussed (e.g., during the presentation at IETF 114)

[italobusi]

2022-11-23 Network Inventory weekly call

Chaode: For issue #3, we all agreed to provide a string format for the components' location. And for IP technology, if the there are some other type component, we just need to modify the pattern which could be compatible. And for issue #41, we have actually provide UUID information in the parent-references structure, so a uuid-based location is not needed.

Jeff: yes, the uuid-based location is not needed. And for the equipment room's name, i remember we have define it in the someplace.

Chaode: The equipment room's name is the location of network element.

Issue #41 can be closed

[italobusi]

2023-02-15 Network Inventory weekly call

Since the location is a free form string it would be worthwhile documenting some format constraints, similar to those defined in ONF TR-547, in the I-D

This is a common format used in Optical networks so it is recommended at least for Optical networks but it seems also applicable to IP and MW

This format can be described as a "recommended" format for Optical, IP and MW, unless there are objections from IP and MW experts

• [ ] @YuChaode provide some text proposal to describe the recommended format of the location string

[YuChaode]

2023-06-28 Weekly Call The text has been provided in the YANG file, we agree to close this issue.

[italobusi]

To be fixed by PR #98