Available OTSi capabilities and configured property

[dieterbeller]

This issue is related to #5.

The avialable OTSi capabilities and configured OTSi capability shall be defined as follows:

• available-standard-modes / configured-standard-mode,
• available-operational-modes / configured-operational-mode,
• available-modulation-types / configured-modulation-type,
• available-baud-rates / configured-baud-rate,
• available-FEC-types / configured-FEC-type,
• etc.

The capabilities shall shall be defined with a leaf-list statement.
For the organizational-modes, a list of containers may be needed, one for each organization/vendor (see organization-identifier).

[sergiobelotti]

available-modulation-types / configured-modulation-type,
available-baud-rates / configured-baud-rate,
available-FEC-types / configured-FEC-type,

In Yang we already have these definitions, with configured as leaf and a leaf-list for the available.
But the configured attributes should be modified as "config true" .

for ### organizational mode, we need to add the list of "available" organizational modes.

[dieterbeller]

Here is a tree-structure proposal for discussion how the OTSi (transceiver) capabilities could be described in the model as well as the configured operational mode for the transceivers in use (note that some transceivers may not be in use and for those unused tranceivers the configured-operational-mode attribute is meaningless):

  augment /nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point:
    +--ro OTSiG-element* [OTSiG-identifier]
    |  +--ro OTSiG-identifier    int16
    |  +--ro OTSiG-capabilities   // NEW! OTSIg cpabilitie still need to be defined (example: supported client bit rates: 100Gbps, 200Gbps,300Gbps, 400Gbps, etc.)
    |  +--ro OTSiG-container
    |     +--ro OTSi* [OTSi-carrier-id]
    |        +--ro OTSi-carrier-id               int16
    |        +--ro OTSi-carrier-frequency        decimal64
    |        +--ro OTSi-min-carrier-frequency?   decimal64
    |        +--ro OTSi-max-carrier-frequency?   decimal64
    |        +--ro OTSi-signal-width             decimal64
    |        +--ro OTSi-tx-power
    |        +--ro delta-power?                  decimal64
    |        +--ro OTSi-tx-min-power?
    |        +--ro OTSi-tx-max-power?
    |        +--ro (available-operational-modes)
    |           +--:(available-G.692.2-modes)
    |              +--ro available-standard-modes?   // list of supported G.692.2 application identifiers
    |           +--:(available-organizational-modes)
    |              +--ro organization* [organization-identifier]
    |              +--ro organization-identifier?   string
    |                 +--ro available-operational-modes?   // list of available operational modes for a particular org/vendor
    |           +--:(explicit-mode)
    |              +--ro available-modulation-types*      identityref
    |              +--ro available-xyz*
    |              ... // list of all configurable explicit attributes 
    |              ...
    |              ...
    |        +--ro (configured-operational-mode)
    |           +--:(configured-G.692.2-mode)
    |              +--ro configured-standard-mode   
    |           +--:(configured-organizational-mode)
    |              +--ro organization-identifier?   string
    |              +--ro configured-operational-mode?
    |           +--:(configured-explicit-mode)
    |              +--ro configured-modulation-type      identityref
    |              +--ro configured-xyz
    |              ... // list of all explicitly configured attributes 
    |              ...
    |              ...

[egriseri]

[everyone else removed] Hi Dieter, Is the configured-operational-mode a list? I’m not sure I completely understand what brackets mean 😊 . If My interpretation is correct, shouldn’t it be only one value instead of a list? Best regards, enrico From: Dieter Beller <notifications@github.com> Sent: Thursday, June 27, 2019 3:05 PM To: younglee-ietf/ietf-optical-impairment-yang <ietf-optical-impairment-yang@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: Re: [younglee-ietf/ietf-optical-impairment-yang] Available OTSi capabilities and configured property (#12) Here is a proposal for discussion how the OTSi (transceiver) capabilities could be described in the model as well as the configured operational mode for the transceiver in use (note that some transceivers may not be in use and for those the configured-operational-mode attribute is meaningless): augment /nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point: +--ro OTSiG-element* [OTSiG-identifier] | +--ro OTSiG-identifier int16 | +--ro OTSiG-capabilities // NEW! OTSIg cpabilitie still need to be defined (example: supported client bit rates: 100Gbps, 200Gbps,300Gbps, 400Gbps, etc.) | +--ro OTSiG-container | +--ro OTSi* [OTSi-carrier-id] | +--ro OTSi-carrier-id int16 | +--ro OTSi-carrier-frequency decimal64 | +--ro OTSi-min-carrier-frequency? decimal64 | +--ro OTSi-max-carrier-frequency? decimal64 | +--ro OTSi-signal-width decimal64 | +--ro OTSi-tx-power | +--ro delta-power? decimal64 | +--ro OTSi-tx-min-power? | +--ro OTSi-tx-max-power? | +--ro (available-operational-modes) | +--:(available-G.692.2-modes) | +--ro available-standard-modes? // list of supported G.692.2 application identifiers | +--:(available-organizational-modes) | +--ro organization* [organization-identifier] | +--ro organization-identifier? string | +--ro available-operational-modes? // list of available operational modes for a particular org/vendor | +--:(explicit-mode) | +--ro available-modulation-types* identityref | +--ro available-xyz* | ... // list of all configurable explicit attributes | ... | ... | +--ro (configured-operational-mode) | +--:(configured-G.692.2-mode) | +--ro configured-standard-mode | +--:(configured-organizational-mode) | +--ro organization-identifier? string | +--ro configured-operational-mode? | +--:(configured-explicit-mode) | +--ro configured-modulation-type identityref | +--ro configured-xyz | ... // list of all explicitly configured attributes | ... | ... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#12>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AMB3D3MOWCQH6WYCS7FAXXLP4S3I3ANCNFSM4HP5MISA>.

[EstherLerouzic]

the brackets means that this is a choice. The name in the bracket is logical and does not appear in the data instance. I have found this reference that explains tree representation convention https://tools.ietf.org/id/draft-ietf-netmod-yang-tree-diagrams-01.html#rfc.section.2

? for an optional leaf, choice, anydata or anyxml ! for a presence container * for a leaf-list or list [<keys>] for a list's keys / for a mounted module @ for a node made available via a schema mount parent reference

[EstherLerouzic]

I think we should not place the "available modes" in the OTSi container: here is the reasoning:
The definition of OTSi in Recommandation G.959.1 (07/18) is:
optical tributary signal (OTSi): Optical signal that is placed within a network media channel for transport across the optical network. This may consist of a single modulated optical carrier or a group of modulated optical carriers or subcarriers.
(last part we asked to suppress)

so in my opinion an OTSi is already a signal generated by transceiver and attached to a transponder. If the signal already exists, it means that the transceiver type is known and the mode has already been configured. And in the yang model it is an augmentation of a tunnel.

So my point is that it is very confusing to have an OTSi without configured mode.
And since in my opinion there should be a configured mode, there is no point to give the detail of available modes in the OTSi.
Instead my suggestion is to list transponders separately, have the available mode in this separate container and reference a transponder in the OTSi.
Moreover, a transponder may exist without active OTSi.

The list of transponders could be an augmentation of interfaces as in draft-ietf-ccamp-dwdm-if-param-yang-00. In this case we may propose to increase the tree of this draft with our needs:

And a transponder could also be referenced in a tunnel termination point in the te topology

Would it be possible to discuss both solutions (Dieter's and mine) on a next conf call ?

[sergiobelotti]

This issue is related to transponder model and it is solved in PR#36