Open YuChaode opened 6 months ago
YuChaode
commented
6 months 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
6 months 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
6 months 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
6 months 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
6 months 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
5 months 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:
italobusi
commented
5 months 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 portIt 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 portOption 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 portOption 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)partially consistent with the OpenConfig approach (only for the ports but not for the slots)
use the RFC8348 container component class to model the slots
not consistent models for the slots and the SFP holes
implementation of the capability model is not required to report the empty slots and SFP holes
[ ] @italobusi ask the following questions to the IVY WG
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
5 months 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
5 months ago Slides updated based on the feedbacks from the 2024-05-29 Network Inventory weekly call
italobusi
commented
5 months 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:
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
5 months 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
5 months 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.
italobusi
commented
4 months 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
4 months 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
4 months 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 groupthoughts ?
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:
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'
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
4 months ago openconfig-breakout-groups.pptx
Attached is the PPT
italobusi
commented
4 months ago 2024-06-26 Base Network Inventory weekly call
Phil presented some slides about the OpenConfig modelling: openconfig-breakout-groups.pptx
A port in OpenConfig is not field replaceable: it is either an 'SFP hole' or integrated connector (in case of non-pluggable ports)
port (SFP hole)
transceiverPort is a parent component of the transceiver inserted into that port
OpenConfig does not model the host channels but only the media channels on the line (as physical channels under the transceiver component if applicable)
No breakout configuration means the host "interface" maps to all host to transceiver and transceiver to media channels.
The OC "interface" is referencing the port, the transceiver and the list of media channels
In case of a breakout, each interface will reference the same port and the same transceiver, but different physical media channels
In the case where the transceiver is on the cable (the cable cannot be unplugged from the SFP), like the QSFP-4x10G-AOC10M, it is modelled as:
port (SFP hole)
transceiver
4x children ports2024-09-11 Base Network Inventory weekly call
The IVY WG chairs have sent an email, right after the discussion at IETF 120, to ask WG what is the opinion regarding the 3 options:
See: https://mailarchive.ietf.org/arch/msg/inventory-yang/AbrkYA2PZ4f4CQIxsl4AbIdUlFU/
philbedard
commented
2 months ago I’m somewhat in favor of option #2 for modeling the port and pluggable, but would not adopt a 1:1 mapping of the OC terminology since it has some ambiguity.
Thanks, Phil
From: italobusi @.> Date: Wednesday, September 11, 2024 at 14:01 To: ietf-ivy-wg/network-inventory-yang @.> Cc: Phil Bedard @.>, Comment @.> Subject: Re: [ietf-ivy-wg/network-inventory-yang] Modeling of Port and Transceiver (Issue #45)
2024-09-11 Base Network Inventory weekly callhttps://github.com/ietf-ivy-wg/network-inventory-yang/wiki/minutes-2024-09-11
The IVY WG chairs have sent an email, right after the discussion at IETF 120, to ask WG what is the opinion regarding the 3 options:
See: https://mailarchive.ietf.org/arch/msg/inventory-yang/AbrkYA2PZ4f4CQIxsl4AbIdUlFU/
— Reply to this email directly, view it on GitHubhttps://github.com/ietf-ivy-wg/network-inventory-yang/issues/45#issuecomment-2344452847, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACR35ZJVOAK5X4YL2GX3HNDZWCHRBAVCNFSM6AAAAABHOI7YIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBUGQ2TEOBUG4. You are receiving this because you commented.Message ID: @.***>
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