Terminal device properties found issues - New release proposed v0.2.0

[arthurMll]

Motivation

After the initial release of the openconfig-terminal-device-properties.yang, there have been significant technical questions and discussions happening within the Telecom Infra Project (TIP) Open Optical & Packet Transport (OOPT) community between operators and vendors.

This issue summarizes the motivation and issues detected in the first release of the model and it will serve as an introduction and motivation of a new pull request (#911) with a new proposed comprehensive update of the model which will be accompanied by the relevant explanations on how the new model proposal will try to overcome the detected issues. It is worth mentioning that the current analysis and the new proposal are the outcomes of an extensive technical discussion within the OOPT community between vendors and service providers and that it consolidates an already discussed proposal starting from the issues and motivations explained here.

Context

The current proposed terminal-device-properties model was designed with the objective of allowing the terminal devices' system vendors to expose the intrinsic properties (Modulation Format, FEC, Baud-rate) and performance characteristics (Rx-OSNR, CD/PMD limits) of the device's supported transmission modes.

The initial version of the model was designed as a flat list of mode properties, where each entry represents a mode supported by the terminal device and includes the list of characteristics of that mode. However, this initial version presents a significant list of limitations.

Initial release limitations

• First issue: The current model exposes a list of modes available in the device, however, the characteristics of a mode of transmission are affected by the HW transceiver supplying it. In other words, two different transceivers (supported by the same terminal device) might support the same mode, but their mode characteristics are different.

• Second issue: There is not an interoperability matrix within the Terminal Device's which exposes the compatibility between Terminal Device's chassis, linecards, transceivers and modes. Right now there is no compatibility information available in the model, to allow the supplier to properly describe which modes are supported by each transceiver module available in the terminal device.

Operational challenges

• It is not clear how mode IDs will be assigned and who will assign them.
• Clarification of the bookended solution target by the model.

New proposal scope and initial assumptions

Clarify the target of the next extension targets

1. Bookended solutions, and interoperability between terminal devices of the same system vendor.
2. Interoperability between different system vendors O-OTs through standard modes

Common definitions

• Open Optical Terminal (O-OT) - the term designates a category of Network Elements in an Optical Transport Network, including the network functions of Transponders (1:1 mapping of clients to line side interfaces); Muxponders (N:1 mapping and multiplexing); Switchponders (N:M mapping, digital switching and multiplexing). Their role is to adapt digital clients of the Optical Transport Network over DWDM channels. It does map 1:1 to the defined "Terminal Device" in OpenConfig.
• System-vendor = the O-OT host platform provider (e.g. mux-ponder shelf, router, switch) and system integrator including the network operating system of the O-OT
• Manufacturer = Transceiver manufacturer (pluggable)
• Bookended scenario definition.
  • The System Vendor is the same in the two O-OTs.
  • The O-OTs of the same system vendor might host different Transceiver manufacturers.
  • Mode-ids are defined and maintained by the system vendor.
  • Interoperability shall be guaranteed by the system vendor if the same mode-id is configured in the line interfaces /optical-channels of the two O-OTs.

Assumptions

• The openconfig-terminal-device-properties.yang is a standalone model which represents static properties of a given terminal device, including:
  • Operational-modes’ characteristic properties on the transceiver configuration which characterize the mode (modulation-format, baud-rate, bit-rate, fec-format, filter…)
  • Mode-descriptors which describe the transmission design properties (Tx/Rx properties + CHARacteristic properties) of the implementation of the mode conditioned by the HW platform (transceiver + linecard) (Rx/Tx-OSNR, CD/PMD tolerances, penalties…)
  • optical-channel’s configuration constraints introduced by the HW implementation (min/max-central-frequency, min/max-output-power…)
• The openconfig-terminal-device-properties.yang is a standalone model representing a given mode’s static properties. We shall avoid any reference btw the manifest files and the operational openconfig trees which change dynamically. In other words, the references between mode-descriptors and operational modes, shall be through absolute identifiers.

Conclusion and Wrap up

As per the issues identified above, the TIP OOPT community would like to push a new pull request to the existing model to consolidate a number of changes that can enhance the current model to solve the issues found and provide more clarity on how to use the model in production networks.

[github-actions]

This issue is stale because it has been open 180 days with no activity. If you wish to keep this issue active, please remove the stale label or add a comment, otherwise will be closed in 14 days.

[arthurMll]

Still relevant for discussion

[dplore]

Fixed by #911