Terminal-device-properties-v2 initial commit

[arthurMll]

This initial commit push the proposal consolidated from TIP OOPT community where it addresses the issues reported in Issue #910.

Change Scope

This pull request covers a proposed solution to the issues described in #910.

The changes to the existing model are not backward compatible.

The summary of the changes proposed is the following:

1. Operational-mode list:

• The list of the exposed operational modes properties by the Terminal Device is augmented with the set of CHARacteristic properties of the operational mode.
• The mode-ids are the same used within the operational datastore of the terminal device (exposed by the openconfig-terminal-device.yang model) and have network-wide scope assuming they guarantee interoperability in bookended scenarios (two Terminal Devices of the same system vendor supporting the same mode).
• The mode-ids are defined by the system vendor.

2. Mode-descriptors list:

• The design properties of the modes, which are dependent on the transceiver component that implements the mode, are exposed as a nested list within the operational mode list. It is assumed that a single operational mode might be implemented by different transceivers which might have associated different design properties exposed by different mode descriptors.
• The mode-descriptor-id is a local index that does not have interoperability meaning outside the specific Terminal device which reports it. In other words, the same mode descriptors might be exported by different Terminal Devices with different IDs.

3. Interoperable mode list.

• A given proprietary operational mode might be capable to comply with a certain number of standards or elsewhere publicly defined operational modes defined by other organizations e.g., ITU-T or OpenROADM.
• This compatibility characteristic shall be assured by the system vendor and imply that the design properties of the implementations of that specific operational mode are a superset of all listed supported standard modes.
• This model block will replace the previous "G.698.2" node tree with a more generic definition able to accommodate multiple standards or MSA-defined modes.

4. Transceiver-descriptors list.

• The Terminal Device exposes the list of the transceiver components which are supported by the device.
• Each transceiver exposes the list of compatible modes and their associated mode descriptor.
• This new model block enhances the previous version by allowing to expose explicitly the compatibility matrix between the Terminal Device, the set of transceiver modules supported and the associated modes supported.

5. Linecard-descriptors list.

• The Terminal Device exposes the list of linecard components which are supported by the device.
• Each linecard component exposes the list of transceivers that are supported.
• Each linecard constrains the list of modes that can be supported among the ones supported by the transceiver.
• Each linecard constrains the optical-channel configuration, e.g., target-output-power and frequency range.
• This new model block enhances the previous version by allowing to expose explicitly the compatibility matrix between the Terminal Device, the line cards, the set of transceiver module per line card and the associated modes supported.

Following the model tree with the 5 blocks described above. In green the new leaves/containers are added in this proposal; in black the non-modified leaves, even if they have been reallocated within the tree under different containers/lists.

For more clarity on the above please check the following common definitions and assumptions defined during the design process of this proposal within the Telecom Infra Project (TIP) OOPT MUST project.

Common definitions

• System-vendor = the O-OT host platform provider (e.g. muxponder 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.

[OpenConfigBot]

No major YANG version changes in commit 01cbc370a2475000999e44431ef7b9c8f8aea268

[arthurMll]

@dplore @oscargdd @ejbrever could you take a look to this? I can attend next public call to try to answer some questions as per your review. Thanks

[dplore]

Thanks @arthurMll . Two requests for you:

• Can you also provide reference to any vendor implementations, or invite vendors to comment who are planning to support this?
• Can you refer any network operators who are implementing and/or want to consume these models?

[EstherLerouzic]

Dear @dplore I can comment on this one:

Can you refer any network operators who are implementing and/or want to consume these models?

Orange plans to consume this model once it is made available northbound from devices.

I hope this helps!

regards

Esther

[renzodiazp]

Dear @dplore, Regarding your comment:

• Can you refer any network operators who are implementing and/or want to consume these models?

From Telia Company side, there are plans to consume the proposed model in the future once it is available. Best regards, /Renzo Díaz

[vaugais]

Hi @dplore, all

To answer this question:

* Can you refer any network operators who are implementing and/or want to consume these models?

Yes we confirm from Colt Technology Services that we are actively working on SDN architecture for packet-optical services and technologies where openconfig for open optical terminals will be one key building block.

Thanks,

Valéry Augais

[dplore]

Thanks for all the comments on interest. I would like to see a review of the model by at least one operator. The review of the yang syntax is not critical, but the content is. The OC Operators who are regularly attending our calls and participating in reviews do not have a deep familiarity with this use case.

@arthurMll if you find it helpful, may I suggest you organize a call with interested operators for a live review. We can utilize the weekly Operator call (at 09:00 PST on Tuesdays) or if needed, we could create a call just for this PR review.

Also, @arthurMll perhaps you could create a tree view which in my experience helps reviewers more easily understand the model (reading only the yang it is difficult to understand the structure of the model).

[jbouqui153]

Dear @dplore ,

regarding your question:

• Can you refer any network operators who are implementing and/or want to consume these models?

Vodafone is interested in this model to be made available on optical terminal devices.

Kind regards,

Jeff Bouquier

[dplore]

@arthurMll thanks for presenting this today. I more clearly understand the intent of this model now. Action items from the live review were:

• Suggest adding a diagram showing the O-OT System vendor is responsible for delivering an implementation of the model. which contains multiple manufacturer's transceiver modules.
• Please provide 2 examples of data from implementations (O-OT) which describe data that matches or is similar to the data modeled in this PR. These examples can be references to documentation, or sample output from show commands, craft interface, TL1 command output, etc.

[matias-schneeberger]

Nokia is in agreement with the last model version. We didn’t discover any issues with it yet and we are planning to support it.

CC: @arthurMll

[dplore]

@arthurMll thanks for your updates. Can you rebase this to the latest comment on the master branch and resolve any conflicts? Then I will take a pass at review.

[arthurMll]

@dplore conflicts resolved and code ready for the final review

[dplore]

/gcbrun

[dplore]

I merged this PR with the latest master, as there are new/fresh conflicts to be resolved.

[dplore]

/gcbrun

[dplore]

@arthurMll please check the latest set of github check results to make some fixes.

[arthurMll]

Hi @dplore ,

I tried to fix what I found on the error list.... can you trigger another /gcbrun?

[dplore]

/gcbrun

[dplore]

/gcbrun

[arthurMll]

Hi @dplore ,

In the last commit, I tried to resolve the following errors. Unfortunately,  I cannot reproduce it locally so I am kind of blind until you do the next /gbcrun command.

F0604 16:17:22.769055 888 generator.go:384] ERROR Generating GoStruct Code: key transceiver-descriptor-id had a leafref key (/openconfig-terminal-device-properties/linecard-descriptors/linecard-descriptor/compatible-transceivers/compatible-transceiver/transceiver-descriptor-id) in dir state that did not exist ([ oc-opt-term-properties:transceiver-descriptors oc-opt-term-properties:transceiver-descriptor oc-opt-term-properties:state oc-opt-term-properties:component-descriptor-id]) key mode-id had a leafref key (/openconfig-terminal-device-properties/linecard-descriptors/linecard-descriptor/compatible-transceivers/compatible-transceiver/constrained-compatible-modes/constrained-compatible-mode/mode-id) in dir operational-modes that did not exist ([ oc-opt-term-properties:operational-mode-descriptors operational-modes mode-id]) key mode-id had a leafref key (/openconfig-terminal-device-properties/transceiver-descriptors/transceiver-descriptor/transceiver-compatible-modes/transceiver-compatible-mode/mode-id) in dir operational-modes that did not exist ([ oc-opt-term-properties:operational-mode-descriptors operational-modes mode-id])

[dplore]

/gcbrun

Sorry this is not automatic

[m1k10h]

NEC optical transport team supports this proposal. We have a plan to release our software that implements the proposed properties.

/CC @arthurMll

[dplore]

/gcbrun

[dplore]

/gcbrun

[arthurMll]

/gcbrun

@dplore can you build it one more time?

[dplore]

/gcbrun

[arthurMll]

@dplore can you make a final gcbrun and if everything ok the PR is ready to be merged in master

[dplore]

/gcbrun

[arthurMll]

All checks are passed so from our side the PR is ready to be merged to public. @dplore please approve

[dplore]

Final tree output:

module: openconfig-terminal-device-properties
  +--ro transceiver-descriptors
  |  +--ro transceiver-descriptor* [component-descriptor-id]
  |     +--ro component-descriptor-id         -> ../state/component-descriptor-id
  |     +--ro state
  |     |  +--ro component-descriptor-id?   string
  |     |  +--ro system-vendor-name?        string
  |     |  +--ro system-vendor-part-no?     string
  |     |  +--ro mfg-name?                  string
  |     |  +--ro mfg-part-no?               string
  |     |  +--ro hardware-version?          string
  |     |  +--ro firmware-version?          string
  |     |  +--ro software-version?          string
  |     |  +--ro clei-code?                 string
  |     +--ro transceiver-compatible-modes
  |        +--ro transceiver-compatible-mode* [mode-id]
  |           +--ro mode-id    -> ../state/mode-id
  |           +--ro state
  |              +--ro mode-id?              uint16
  |              +--ro mode-descriptor-id?   -> /operational-mode-descriptors/operational-modes/mode-descriptors/mode-descriptor/mode-descriptor-id
  +--ro linecard-descriptors
  |  +--ro linecard-descriptor* [component-descriptor-id]
  |     +--ro component-descriptor-id    -> ../state/component-descriptor-id
  |     +--ro state
  |     |  +--ro component-descriptor-id?   string
  |     |  +--ro system-vendor-name?        string
  |     |  +--ro system-vendor-part-no?     string
  |     |  +--ro mfg-name?                  string
  |     |  +--ro mfg-part-no?               string
  |     |  +--ro hardware-version?          string
  |     |  +--ro firmware-version?          string
  |     |  +--ro software-version?          string
  |     |  +--ro clei-code?                 string
  |     +--ro compatible-transceivers
  |        +--ro compatible-transceiver* [transceiver-descriptor-id]
  |           +--ro transceiver-descriptor-id       -> ../state/transceiver-descriptor-id
  |           +--ro state
  |           |  +--ro transceiver-descriptor-id?   string
  |           +--ro constrained-compatible-modes
  |              +--ro constrained-compatible-mode* [mode-id]
  |                 +--ro mode-id                                     -> ../state/mode-id
  |                 +--ro state
  |                 |  +--ro mode-id?              uint16
  |                 |  +--ro mode-descriptor-id?   -> /operational-mode-descriptors/operational-modes/mode-descriptors/mode-descriptor/mode-descriptor-id
  |                 +--ro optical-channel-config-value-constraints
  |                    +--ro state
  |                       +--ro min-central-frequency?    oc-opt-types:frequency-type
  |                       +--ro max-central-frequency?    oc-opt-types:frequency-type
  |                       +--ro grid-type?                oc-opt-term-prop-types:grid-type
  |                       +--ro adjustment-granularity?   oc-opt-term-prop-types:adjustment-granularity
  |                       +--ro min-channel-spacing?      decimal64
  |                       +--ro min-output-power?         decimal64
  |                       +--ro max-output-power?         decimal64
  +--ro operational-mode-descriptors
     +--ro operational-modes* [mode-id]
        +--ro mode-id             -> ../state/mode-id
        +--ro state
        |  +--ro mode-id?                          uint16
        |  +--ro modulation-format?                union
        |  +--ro bit-rate?                         oc-opt-term-prop-types:bit-rate
        |  +--ro baud-rate?                        decimal64
        |  +--ro optical-channel-spectrum-width?   decimal64
        +--ro filter
        |  +--ro state
        |     +--ro pulse-shaping-type?   union
        |     +--ro roll-off?             decimal64
        +--ro fec
        |  +--ro state
        |     +--ro fec-coding?        union
        |     +--ro coding-overhead?   decimal64
        |     +--ro coding-gain?       decimal64
        +--ro mode-descriptors
           +--ro mode-descriptor* [mode-descriptor-id]
              +--ro mode-descriptor-id     -> ../state/mode-descriptor-id
              +--ro state
              |  +--ro mode-descriptor-id?                uint16
              |  +--ro min-tx-osnr?                       decimal64
              |  +--ro min-rx-osnr?                       decimal64
              |  +--ro min-input-power?                   decimal64
              |  +--ro max-input-power?                   decimal64
              |  +--ro max-chromatic-dispersion?          decimal64
              |  +--ro max-differential-group-delay?      decimal64
              |  +--ro max-polarization-dependent-loss?   decimal64
              |  +--ro pre-fec-ber-threshold?             decimal64
              +--ro penalties
              |  +--ro penalty* [parameter-and-unit up-to-boundary]
              |     +--ro parameter-and-unit    -> ../state/parameter-and-unit
              |     +--ro up-to-boundary        -> ../state/up-to-boundary
              |     +--ro state
              |        +--ro parameter-and-unit?   oc-opt-term-prop-types:impairment-type
              |        +--ro up-to-boundary?       decimal64
              |        +--ro penalty-value?        decimal64
              +--ro interoperable-modes
                 +--ro interoperable-mode* [mode-name]
                    +--ro mode-name    -> ../state/mode-name
                    +--ro state
                       +--ro mode-name?                string
                       +--ro publisher-organization?   union