search

ietf-ivy-wg / network-inventory-yang

Other
0 stars 3 forks source link

Modeling of Port and Transceiver #45

Open YuChaode opened 1 month ago

YuChaode commented 1 month ago

This issue was raised when we were considering how to introduce transceiver into the base model. We found the understandings of port were not aligned, so we collected four scenarios of port & transceiver installation and run this discussion with several proposals. The slide we discussed on the weekly call of 8th May, 2024 is attached below: Discussion of Port Modeling-20240508.pptx

YuChaode commented 1 month ago

The main disagreement is whether to model hole/cage. Especially for the third scenario, which is no transceiver inserted in the hole, people had some disagreement on whether to model it as a port or a cage.

italobusi commented 1 month ago

2024-05-08 Network Inventory weekly call

Slide from Chaode reviewed: Discussion.of.Port.Modeling-20240508.pptx

A better term for the 'transceiver' component should be investigated since some SFPs contain more than one transceivers and the term 'transceiver' is already used in the optical impairments topology to represent the functional aspects.

In case of a non-pluggable port, reporting the 'transceiver' component is an implementation option: it could be useful if there is a need to report specific information (e.g., part-number or serial-number) of a non-pluggable component integrated into the board. Otherwise, the port component can be reported directly under the module component representing the board.

Even the 'hole' has no serial-number, it is still need to model the 'hole' because there are multiple 'holes' in the device which need to be numbered and need to distinguish the different types of 'holes' within the network element, which may have different capabilities in terms of SFP modules which can be plugged-id.

It has been agreed that the four cases (pluggable transceiver port, non-pluggable transceiver port, empty hole and non-pluggable integrated port) apply to both optical and electrical ports.

Jeff: it is important to highlight that a port is the starting point of a service. Nigel: In TAPI the access port has been defined (considered) as conceptual bridge between the logical model and physical model.

Italo: I am not sure we need to associate the port with the service or a new object to bridge between the functional view and the hardware/equipment view. The service starts from an LTP and the LTP can be associated with a port.

It has been agreed that there is no need to report two components for the Tx and Rx connector. A single 'port' component instance can be used to report the combination of the Tx and Rx connectors. In case of bidirectional connectors (e.g., a pin terminating a bidirectional fiber or an RJ-45 connector), a single 'port' component instance can be used to report the bidirectional connector.

Jeff: for me, on a pluggable, the port is the connector or the combination of the Tx and Rx connectors

It was highlighted that the SFP module and the connector/connectors pair can be modelled as a single 'port' component. In this case, there is no need for a new component class (the 'transceiver' component class in the slides) and no need to differentiate in the model between the non-pluggable transceiver port and the non-pluggable integrated port.

Jeff disagreed not have a specific component for transceiver.

This issue needs further discussion.

The slides propose to model the 'hole', where an SFP module can be plugged-in, as a 'port' component instead of as a 'container' component

There was no agreement on whether the 'hole', where an SFP module can be plugged-in, should be modelled as a 'port' component or as an holder component of a different class (e.g., 'container' component class or as a new component class)

italobusi commented 1 month ago
  • [x] @italobusi send a mail to the IVY WG to gather more feedbacks also from other operators on how to model the 'hole' where an SPF module can be plugged-in

Draft text for the mail provided in:

https://demo.hedgedoc.org/6AxuTUrRRQ661IUDMc1AYw

Waiting for feedbacks from the participants to the call before sending it to the IVY WG mailing list

sergiobelotti commented 1 month ago

@italobusi : I think the text is reporting correctly the discussion we had. I would have just added the reference to BBF new object to define "hole", that in the context of Option 2.

italobusi commented 1 month ago

2024-05-15 Network Inventory weekly call

It has been agreed to send the mail asking for feedbacks to the IVY WG without providing any pros&cons analysis. Supporters of one option can reply to the mail with their opinion about the advantages of the option they prefer.

The objective is to get a decision between option 1 and option 2 before the next call (May 22, 2024).

If option 2 is selected, we can later discuss the pros&cons of reusing the 'container' component class or defining a new component class, such as the 'cage' as proposed by BBF.

Nigel thinks that the hole is present with or without anything plugged-in and its capabilities have to be reported. Even if some holes are specialize for a single type of SFP, nothing precludes holes that can have different types of SFPs or with more than one 'port'. An 'hole' can also host some other type of module (e.g., a memory module) without any external connector, not necessarily a transceiver.

Aihua reported the use case to retrieve all the capabilities of a board, including the empty 'holes', pluggable ports and non-pluggable ports.

According to Nigel the capability of the cards should be known by the controller before the card is plugged-in either through offline information or by some capability model.

Prasenjit reported that if there is a mismatch between the capabilities of the 'hole' and what it is plugged-in, an alarm should be raised.

Aihua reported that in the published BBF the 'transceiver-link' component is not used to report a optical connector but the 'transceiver' function within an SFP module (which is modelled in BBF as a 'transceiver' component). There are scenarios where a single SFP module can contain more than on 'transceiver' functions.

It has been highlighted that the current approach in IVY WG is to decouple the functional view from the hardware view. The functional view of the 'transceiver' is already modelled in the optical impairments topology and equally applies to the 'transceivers' hosted in an SFP module as well as those hosted on a 'transponder card'.

It may be worthwhile having some examples of the PON possible configurations to check how the base model can be used to model the PON port, especially those at the OLT.

italobusi commented 1 month ago

As an input for our discussion, I have prepared some examples describing scenarios with non-MPO ports, MPO ports without breakouts and MPO ports with breakouts:

port-examples-06.pptx

italobusi commented 1 month ago

2024-05-22 Network Inventory weekly call

Summary of the OpenConfig approach for the four different types of ports in Discussion.of.Port.Modeling-20240508.pptx

Board X/Y
   Port X/Y/1 (empty = False)   // Pluggable transceiver port
      Transceiver X/Y/1 (removable = True)
   Port X/Y/2 (empty = False)   // Non-pluggable transceiver port
      Transceiver X/Y/2 (removable = False)
   Port X/Y/3 (empty = True)    // Empty hole
   Port X/Y/4 (empty = False)   // Non-pluggable integrated port

It was noted that the empty attribute in OpenConfig applies to every component type, because OpenConfig does not define a container component class (as opposed to RFC8348):

Nigel presented the proposal from his e-mail to the IVY WG to model the capabilities of the components separately from the list of installed components. With this approach there is no need to define a container component class (as in RFC8348) because there is no need to report the empty slots nor the empty SFP holes in the list of installed components.

Concerns have been raised about how the following scenarios can be supported without defining a container component class:

It was also noted that reporting the available slots and SFP holes only in the capability model and not in the component list would make the implementation of the capability model mandatory when reporting the empty slots and SFP holes is required.

Based on this discussion, we can summarize the possible solutions with four options, which differs in:

Option 1:

+-- chassis
    +-- container                 // slot: empty when there is no child module component
        +-- module                // board
            +-- container         // SFP hole (only for pluggable ports): empty when there is no child module component
                +-- module        // transceiver(s) module (optional for non-pluggable ports)
                    +-- port      // non-MPO port

Option 2:

+-- chassis
    +-- module                    // empty slot or board
        +-- port                  // empty SFP hole or port (MPO or non-MPO and pluggable or non-pluggable port)
            +-- transceiver       // transceiver(s) module (optional for non-pluggable ports)

Option 3:

+-- chassis
    +-- module                    // board
        +-- module                // transceiver(s) module (optional for non-pluggable ports)
            +-- port              // non-MPO port

Option 4:

+-- chassis
    +-- container                 // slot: empty when there is no child module component
        +-- module                // board
            +-- port              // empty SFP hole or (pluggable or non-pluggable) non-MPO port
                +-- transceiver   // transceiver(s) module (optional for non-pluggable ports)

1) How important is to maintain consistency with the OpenConfig approach in IVY WG? 2) How important is to support the following scenarios (which can be supported using the RFC8348 container component class to model the slots)?

italobusi commented 1 month ago

2024-05-29 Network Inventory weekly call

Reviewed slides port-examples-06.pptx

Comments:

It was also pointed out that there are also cases where there is a single fiber used to carry signal in a single direction: to be analyzed in a later step

The modelling for example 6 may depend on whether the interface is a short-reach or a long-reach interface: in the long-reach each transceiver needs to be managed individually and therefore also each pin becomes relevant from management perspective

The OpenConfig approach is to define a child port component for each breakout: it is not known if OpenConfig is defining a breakout port for each pin or for each client

In case a WDM mux is used, the WDM mux is modelled in the functional domain (outside the scope of the inventory) and a single 'port' is represented in the inventory model. The description of the navigation from the client interface/LTP to the 'port' should be addressed by navigating in the functional model(s) and arriving at the same 'port' component in the inventory model (shown as a green dot on the device).

In this specific there is no need to expose in the inventory model the specific pins (used for Tx/Rx).

This approach seems reasonable but more details have to be investigated to understand how the WDM multiplexing and the cable breakout are modelled in the functional domain.

It was noted that the different multiplexing techniques can be combined, for example the optical signal at the output of the WDM Mux can be placed on a fiber pairs within an MPO cable.

Next steps: review the example 6 to understand also which level of details need to be included in the model for the pins (which now are relevant since different clients are using different pins)

italobusi commented 1 month ago

Slides updated based on the feedbacks from the 2024-05-29 Network Inventory weekly call

port-examples-07.pptx

italobusi commented 3 weeks ago

2024-06-05 Network Inventory weekly call

Reviewed updated slides: port-examples-07.pptx

The slides have been updated marking the examples where it has been already agreed to model the multiplexing function as a functional element

Updated slides: port-examples-08.pptx

Example 6b has been analyzed with the expectations that other MPO-related scenarios can be modeled as simpler special configuration

It was also pointed out that Examples 6a and 6b seems more complex that the current practice: Example 6c has been added to match the most common scenario today

It has been agreed that there is no need to model the breakout cables to describe these scenarios

Two options have been considered in the call:

More investigation is needed to understand the OpenConfig model. Some examples are provided in the OpenConfig YANG model:

https://github.com/openconfig/public/blob/master/release/models/platform/openconfig-platform-port.yang#L138

However, it is not fully clear how the model can be used to model the examples in the slides. Some JSON (or pseudo-JSON) code showing how the OpenConfig models the examples in the slides would be useful.

italobusi commented 2 weeks ago

2024-06-12 Base Network Inventory weekly call

Slides from Nigel about TAPI model for access ports: ModelFigures.pptx

The connector is an element which is atomically removed/inserted

If there is no need to manage the pins in a connector (e.g., the MPO connector for the 100GE-SR4), a single access port can be created and associated with a connector on an equipment (circuit pack or SFP)

In case of breakout, the pins need to be managed and multiple access ports are defined referencing the same connector on an equipment (circuit pack or SFP). One or more pins can be assigned to an access port.

There is no managed object to represent the connectors and the pins in the connectors: they are known a-priori by a number

The connectors associated with a single access port can be located on different equipment (circuit pack or SFP)

It could be good to have some JSON (or pseudo-JSON) description of the example in port-examples-08.pptx

sergiobelotti commented 2 weeks ago

2024-06-12 Base Network Inventory weekly call

Slides from Nigel about TAPI model for access ports: ModelFigures.pptx

The connector is an element which is atomically removed/inserted

If there is no need to manage the pins in a connector (e.g., the MPO connector for the 100GE-SR4), a single access port can be created and associated with a connector on an equipment (circuit pack or SFP)

In case of breakout, the pins need to be managed and multiple access ports are defined referencing the same connector on an equipment (circuit pack or SFP). One or more pins can be assigned to an access port.

There is no managed object to represent the connectors and the pins in the connectors: they are known a-priori by a number

The connectors associated with a single access port can be located on different equipment (circuit pack or SFP)

It could be good to have some JSON (or pseudo-JSON) description of the example in port-examples-08.pptx

Thanks @italobusi for the minute. I'm trying to map what I think to have understood about OpenConfig breakout port modeling with what Nigel explained yesterday and I have few questions.

  1. Is what is called "physical-channel" in OC equivalent to "pin" in TAPI ?
  2. Can we say that the "breakout group" in OC is equivalent to "access port" in TAPI? If yes, any access port should be characterized by speed , where is this information provided in TAPI? I do not see that in the Nigel's slide 11 where access port is introduced .
italobusi commented 1 week ago

2024-06-19 Base Network Inventory weekly call

Slides updated during the call: port-examples-09.pptx

More work is needed to complete the analysis of the OpenConfig-like option

The target is to finalize the set of options before IETF 120 to be able to present them at the IVY WG in IETF 120 and to get WG consensus right after

prmanna commented 1 week ago

OpenConfig Model introduced breakout-mode config for Grey Optics. It does not consider complicated config to pin specific lanes. Under pluggable comp - it should have list of breakout groups also. 

       +--ro groups
          +--ro group* [index].   // list of group
             +--ro index    
             +--ro breakout-speed?         // optional speed
             + --ro component-ref           // the reference component of this group. 
             +--ro channels*?                  // list of lanes/pins for this group

thoughts ?

italobusi commented 5 days ago

OpenConfig Model introduced breakout-mode config for Grey Optics. It does not consider complicated config to pin specific lanes. Under pluggable comp - it should have list of breakout groups also.

       +--ro groups
          +--ro group* [index].   // list of group
             +--ro index    
             +--ro breakout-speed?         // optional speed
             + --ro component-ref           // the reference component of this group. 
             +--ro channels*?                  // list of lanes/pins for this group

thoughts ?

Before commenting or asking some questions for clarification, let me start checking if I can understand your proposal from an high-level perspective. My understanding is that you are proposing to:

  1. model the "MPO connector" as one component instance of class 'port' and to define the container groups under the component with some when statement to make it applicable only to components of type 'port'

  2. define an entry in the group list to represent the set of lanes/pins which are associated with a single client interface (an entry in the group is something similar to the TAPI access-port)

    For example, considering example 5 in slide 10 of port-examples-09.pptx, there will be M groups where the group 1 (associated with client 1 interface) has K lanes while group M (associated with client M interface) has one lane

Is my understanding correct?

philbedard commented 5 days ago

openconfig-breakout-groups.pptx

Attached is the PPT

italobusi commented 5 days ago

2024-06-26 Base Network Inventory weekly call

Under review