Modelling of Transponders #29

italobusi · 2020-03-06T11:12:14Z

There are three models for transponders in WSON topology, Flexi-grid topology and optical-impairment topology

It is suggested to reconcile these models

italobusi · 2020-03-06T11:14:51Z

These are the current models:

WSON topology (https://tools.ietf.org/html/draft-ietf-ccamp-wson-yang-23):

     augment /nw:networks/nw:network/nw:node/tet:te
               /tet:tunnel-termination-point:
       +--rw supported-operational-modes*
       |       layer0-types:operational-mode
       +--rw configured-operational-modes?
       |       layer0-types:operational-mode
       +--rw supported-fec-types*            identityref
       +--rw supported-termination-types*    identityref
       +--rw supports-bit-stuffing?          boolean
       +--rw is-tunable?                     boolean

Flexi-grid topology (https://tools.ietf.org/html/draft-ietf-ccamp-flexigrid-yang-05):

  augment /nw:networks/nw:network/nw:node/tet:te/
    tet:tunnel-termination-point:
    +--rw supported-operational-modes*    layer0-types:operational-mode
    +--rw configured-operational-modes?   layer0-types:operational-mode
    +--rw supported-fec-types*            identityref
    +--rw supported-termination-types*    identityref
    +--rw supports-bit-stuffing?          boolean
    +--rw is-tunable?                     boolean
    +--rw max-subcarrier-channel-num?     uint8
    +--rw supports-flexi-grid?            boolean

Optical-impairments topology (https://tools.ietf.org/html/draft-ietf-ccamp-optical-impairment-topology-yang-02):

  augment /nw:networks/nw:network/nw:node/tet:te
            /tet:tunnel-termination-point:
    +--ro OTSiG-element* [OTSiG-identifier]
    |  +--ro OTSiG-identifier    int16
    |  +--ro OTSiG-container
    |     +--ro OTSi* [OTSi-carrier-id]
    |        +--ro OTSi-carrier-id           int16
    |        +--ro OTSi-carrier-frequency?   decimal64
    |        +--ro OTSi-signal-width?        decimal64
    |        +--ro channel-delta-power?      decimal64
    +--ro transponders-list* [transponder-id]
       +--ro transponder-id                   uint32
       +--ro (mode)?
       |  +--:(G.692.2)
       |  |  +--ro standard_mode?             layer0-types:standard-mode
       |  +--:(organizational_mode)
       |  |  +--ro operational-mode?
       |  |  |       layer0-types:operational-mode
       |  |  +--ro organization-identifier?
       |  |          layer0-types:vendor-identifier
       |  +--:(explicit_mode)
       |     +--ro available-modulation*      identityref
       |     +--ro modulation-type?           identityref
       |     +--ro available-baud-rates*      uint32
       |     +--ro configured-baud-rate?      uint32
       |     +--ro available-FEC*             identityref
       |     +--ro FEC-type?                  identityref
       |     +--ro FEC-code-rate?             decimal64
       |     +--ro FEC-threshold?             decimal64
       +--ro power?                           int32
       +--ro power-min?                       int32
       +--ro power-max?                       int32

italobusi · 2020-03-12T15:02:22Z

See also open issues #5; ietf-ccamp-wg/ietf-ccamp-layer0-types-ext-RFC9093-bis#47; #12 and ietf-ccamp-wg/ietf-ccamp-layer0-types-ext-RFC9093-bis#51

italobusi · 2020-03-19T16:35:56Z

See also ietf-ccamp-wg/draft-ietf-ccamp-layer0-types#5

dieterbeller · 2020-04-07T09:46:45Z

For the optical impairment aware L0 topology, the modelling of the following optical transponder properties are needed:

Optical transponder capabilities (how it can be configured):
- list of supported OTSi operational modes (simple representation of parameter set) including optical impairment limits for each operational mode (min OSNR, max PMD, max CD, max PDL, Q-factor limit, etc.)
- alternatively: explicit OTSi parameter list and supported parameter values/ranges (important: the parameter list must be complete!)
- supported transmitter tuning range [f_tx_min, f_tx_max]
- supported transmitter tunability grid (in GHz)
- supported transmitter power range [p_tx-min, p_tx_max]
- supported receiver power range [p_rx-min, p_rx_max]
- supported inverse multiplexing capabilities such as max. OTSiG:OTSi cardinality (to be defined)
Current transponder setting (state information) for each OTSiG and associated OTSi signals, if the optical transponder is currently in use:
- current OTSiG identifier and related OTSi list (as defined in the model)
- current total receive power
- for each OTSi:
  - current operational mode
  - alternatively: currently parameter list setting (the parameter list must be complete!)
  - current transmit frequency
  - current transmit power
  - current receiver OTSi power (per OTSi channel)

sergiobelotti · 2020-04-08T17:41:52Z

To complete the picture herewith the parameters from draft-ietf-ccamp-dwdm-if-param-yang-03:
augment /if:interfaces/if:interface:

    +--rw optIfOChRsSs
       +--rw if-current-mode
       |  +--ro mode-id?                          string
       |  +--ro application-identifier?           uint32
       |  +--ro min-central-frequency?            layer0-types:frequency-thz
       |  +--ro max-central-frequency?            layer0-types:frequency-thz
       |  +--ro min-channel-input-power?          dbm-t
       |  +--ro max-channel-input-power?          dbm-t
       |  +--ro min-channel-output-power?         dbm-t
       |  +--ro max-channel-output-power?         dbm-t
       |  +--ro osnr-margin?                      int32
       |  +--ro q-margin?                         int32
       |  +--ro fec-info?                         string
       |  +--ro fec-bitrate?                      string
       |  +--ro fec-gain?                         string
       |  +--rw pre-fec-ber-mantissa-threshold?   uint32
       |  +--rw pre-fec-ber-exponent-threshold?   int32
       |  +--ro number-of-lanes?                  uint32
       |  +--ro min-laser-temperature?            int32
       |  +--ro max-laser-temperature?            int32
       |  +--ro max-total-rx-optical-power?       dbm-t
       |  +--ro max-chromatic-dispersion?         int32
       |  +--ro max-diff-group-delay?             int32
       |  +--ro modulation-format?                string
       |  +--rw baud-rate?                        uint32
       |  +--rw bits-per-symbol?                  uint32
       |  +--rw num-symbols-in-alphabet?          uint32
       |  +--rw symbols-index?                    uint32
       +--ro if-supported-mode
       |  +--ro number-of-modes-supported?   uint32
       |  +--ro mode-list* [mode-id]
       |     +--ro mode-id                           string
       |     +--ro application-identifier?           uint32
       |     +--ro min-central-frequency?            layer0-types:frequency-thz
       |     +--ro max-central-frequency?            layer0-types:frequency-thz
       |     +--ro min-channel-input-power?          dbm-t
       |     +--ro max-channel-input-power?          dbm-t
       |     +--ro min-channel-output-power?         dbm-t
       |     +--ro max-channel-output-power?         dbm-t
       |     +--ro osnr-margin?                      int32
       |     +--ro q-margin?                         int32
       |     +--ro fec-info?                         string
       |     +--ro fec-bitrate?                      string
       |     +--ro fec-gain?                         string
       |     +--ro pre-fec-ber-mantissa-threshold?   uint32
       |     +--ro pre-fec-ber-exponent-threshold?   int32
       |     +--ro number-of-lanes?                  uint32
       |     +--ro min-laser-temperature?            int32
       |     +--ro max-laser-temperature?            int32
       |     +--ro max-total-rx-optical-power?       dbm-t
       |     +--ro max-chromatic-dispersion?         int32
       |     +--ro max-diff-group-delay?             int32
       |     +--ro modulation-format?                string
       |     +--ro baud-rate?                        uint32
       |     +--ro bits-per-symbol?                  uint32
       |     +--ro num-symbols-in-alphabet?          uint32
       |     +--ro symbols-index?                    uint32
       +--rw current-opt-if-och-mode-params
          +--rw mode-id?                          string
          +--ro min-osnr-margin?                  int32
          +--ro q-margin?                         int32
          +--rw central-frequency?                layer0-types:frequency-thz
          +--rw channel-output-power?             dbm-t
          +--ro channel-input-power?              dbm-t
          +--ro total-input-power?                dbm-t
          +--rw min-fec-ber-mantissa-threshold?   uint32
          +--rw min-fec-ber-exponent-threshold?   int32
          +--rw max-fec-ber-mantissa-threshold?   uint32
          +--rw max-fec-ber-exponent-threshold?   int32
          +--rw number-of-tcas-supported?         uint32
          +--rw mode-list* [tca-type]
          |  +--rw tca-type         opt-if-och-tca-types
          |  +--rw min-threshold?   int32
          |  +--rw max-threshold?   int32
          +--ro cur-osnr?                         int32
          +--ro cur-q-factor?                     int32
          +--ro uncorrected-words?                uint64
          +--ro pre-fec-ber-mantissa?             uint32
          +--ro pre-fec-ber-exponent?             int32

italobusi · 2020-04-14T17:32:57Z

For the optical impairment aware L0 topology, the modelling of the following optical transponder properties are needed:

Optical transponder capabilities (how it can be configured):

list of supported OTSi operational modes (simple representation of parameter set) including optical impairment limits for each operational mode (min OSNR, max PMD, max CD, max PDL, Q-factor limit, etc.)

Some initial questions/doubts considering for example a 400G transponder.

Is it possible that the number of OTSis supported depends on the operational model. For example. the transport can take an OTUC4 and transport it either over a 400G OTSi or over 4x 100G OTSis.
Is it a realistic scenario?
If it is, how can I describe this capability?
I have the feeling that we may need some hierarchical structure with a top level definition of the transponder's capability with e.g., the number of OTSis and then, for each option, the OTSi capabilities?

When the transponder is capable to support 4x 100G OTSis, can we assume that it is always capable to put all of them into a single media channel (if available) or should we describe the capability of the transponder to put multiple OTSis into one media channel?

The model allows for different OTSis to use different operation modes but we expect that in general the same operational model is used.
Is this an "operational" assumption or are there any hardware limitations that would preclude configuring different operational mode?
In the latter case, I think we would need some flags to report whether the hardware is capable to support different operational modes?

Would it be a a realistic use case to consider cases where the transponder has flexibility also on the client signal configuration (for example it is capable to have as input either an OTUC4 or 4x OTUC1/OTU4)?
If this is the case, maybe not all the combinations between the client digital signal and the OTSi configurations are possible. For example, it is not possible to generate a single 400G OTSi if the digital client is a 4x OTUC1/OTU4,

sergiobelotti · 2020-04-15T11:14:58Z

For the optical impairment aware L0 topology, the modelling of the following optical transponder properties are needed:

Optical transponder capabilities (how it can be configured):

list of supported OTSi operational modes (simple representation of parameter set) including optical impairment limits for each operational mode (min OSNR, max PMD, max CD, max PDL, Q-factor limit, etc.)

Some initial questions/doubts considering for example a 400G transponder.

Is it possible that the number of OTSis supported depends on the operational model. For example. the transport can take an OTUC4 and transport it either over a 400G OTSi or over 4x 100G OTSis.
Is it a realistic scenario?

SB> My understanding of the Dieter's proposal is that the last attrubute in the list
- supported inverse multiplexing capabilities such as max. OTSiG:OTSi cardinality (to be defined)
should cover exactly the HW capability of Transponder , and it would be independent of operational mode.

If it is, how can I describe this capability?

SB> see above

I have the feeling that we may need some hierarchical structure with a top level definition of the transponder's capability with e.g., the number of OTSis and then, for each option, the OTSi capabilities?

When the transponder is capable to support 4x 100G OTSis, can we assume that it is always capable to put all of them into a single media channel (if available) or should we describe the capability of the transponder to put multiple OTSis into one media channel?

SB> Why the fact to use 1 or more media channel should impact topology model for optical impairments? It seems to me more a problem of path setup .

The model allows for different OTSis to use different operation modes but we expect that in general the same operational model is used.

SB> During last call it was said that it seems reasonable to consider that OTSi belongong to the same OTiG can use the same operational mode.

Is this an "operational" assumption or are there any hardware limitations that would preclude configuring different operational mode?

In the latter case, I think we would need some flags to report whether the hardware is capable to support different operational modes?

Would it be a a realistic use case to consider cases where the transponder has flexibility also on the client signal configuration (for example it is capable to have as input either an OTUC4 or 4x OTUC1/OTU4)?
If this is the case, maybe not all the combinations between the client digital signal and the OTSi configurations are possible. For example, it is not possible to generate a single 400G OTSi if the digital client is a 4x OTUC1/OTU4,

italobusi · 2020-04-16T08:35:45Z

For the optical impairment aware L0 topology, the modelling of the following optical transponder properties are needed:

Optical transponder capabilities (how it can be configured):

list of supported OTSi operational modes (simple representation of parameter set) including optical impairment limits for each operational mode (min OSNR, max PMD, max CD, max PDL, Q-factor limit, etc.)

Some initial questions/doubts considering for example a 400G transponder.
Is it possible that the number of OTSis supported depends on the operational model. For example. the transport can take an OTUC4 and transport it either over a 400G OTSi or over 4x 100G OTSis.
Is it a realistic scenario?

SB> My understanding of the Dieter's proposal is that the last attrubute in the list
- supported inverse multiplexing capabilities such as max. OTSiG:OTSi cardinality (to be defined)
should cover exactly the HW capability of Transponder , and it would be independent of operational mode.

[Italo] My doubt is that in this case the server reports that the OTSiG:OTSi cardinality is 4 (since it is possible to carry an OTUC4 over 4x OTSi@100G) and that the OTSi supports a 400G operating mode but it does not report that these two capabilities are mutually exclusive since the transponder cannot be configured to carry an OTUC16 over 4xOTSis@400G.

If it is, how can I describe this capability?

SB> see above

I have the feeling that we may need some hierarchical structure with a top level definition of the transponder's capability with e.g., the number of OTSis and then, for each option, the OTSi capabilities?

When the transponder is capable to support 4x 100G OTSis, can we assume that it is always capable to put all of them into a single media channel (if available) or should we describe the capability of the transponder to put multiple OTSis into one media channel?

SB> Why the fact to use 1 or more media channel should impact topology model for optical impairments? It seems to me more a problem of path setup .

[Italo] I agree that it is a problem of path setup/computation but I think it should be addressed otherwise path computation finds a path which is feasible from optical impairments perspective but unfeasible because of transponder capabilities.

The model allows for different OTSis to use different operation modes but we expect that in general the same operational model is used.

SB> During last call it was said that it seems reasonable to consider that OTSi belongong to the same OTiG can use the same operational mode.

[Italo] My doubt is not about the possibility to use the same operational model but about the possibility for an implementation to require this. If an implementation requires all the OTSis within the same OTSiG group to use the same operational model for example it would not be possible to carry an OTUC4 over one OTSi@200G and 2xOTSis@100G even if both operational modes are supported. If path computation is not aware of this transponder limitation it could find an optical path which seems feasible but it is actually unfeasible because of transponder capabilities. As above it is not an optical impairment issue but a path setup/computation issue.

Is this an "operational" assumption or are there any hardware limitations that would preclude configuring different operational mode?

In the latter case, I think we would need some flags to report whether the hardware is capable to support different operational modes?
Would it be a a realistic use case to consider cases where the transponder has flexibility also on the client signal configuration (for example it is capable to have as input either an OTUC4 or 4x OTUC1/OTU4)?
If this is the case, maybe not all the combinations between the client digital signal and the OTSi configurations are possible. For example, it is not possible to generate a single 400G OTSi if the digital client is a 4x OTUC1/OTU4,

italobusi · 2020-04-16T10:23:25Z

I have double checked the current proposal from Dieter with existing definitions in WSON and Flexi-grid topology and found that these attributes are missing but that requires further discussion/investigation:

+--rw supported-fec-types* identityref

I am not sure whether the FEC type is implicitly defined by the operational mode or not. In other words, is it possible to configure different FEC types for the same operational mode?

+--rw supported-termination-types* identityref

The definition and use of this attribute is not fully clear to me but at the first glance is seems more related to the 3R and/or client signal adaptation capabilities

+--rw supports-bit-stuffing? boolean

The definition and use of this attribute is not fully clear

+--rw is-tunable? boolean

I think we can replace this attribute with these two attributes proposed by Dieter which provides more information about the tuning capabilities:

supported transmitter tuning range [f_tx_min, f_tx_max]

supported transmitter tunability grid (in GHz)

+--rw max-subcarrier-channel-num? uint8

It looks like the same as the max. OTSiG:OTSi cardinality attribute proposed by Dieter. I think it is applicable to both WSON and flexi-grid networks.

+--rw supports-flexi-grid? boolean

I am not sure we really need this attribute. The LLC should provide enough information (label-restrictions) to describe any limitation the transponder has on the media-channel frequency-slot(s) it could use. This information includes also the type of grid the transponder can use.

italobusi · 2020-04-16T10:29:00Z

I have also noted that the optical-impairments topology allows one TTP to have multiple transponders (transponders-list* [transponder-id]) but each entry of the the transponder-list defines the capability of one OTSi

Also the DWDM interface model seems describing a transponder with supports only one OTSi

Am I missing something?

dieterbeller · 2020-04-16T10:43:08Z

For the optical impairment aware L0 topology, the modelling of the following optical transponder properties are needed:

Optical transponder capabilities (how it can be configured):

list of supported OTSi operational modes (simple representation of parameter set) including optical impairment limits for each operational mode (min OSNR, max PMD, max CD, max PDL, Q-factor limit, etc.)

Some initial questions/doubts considering for example a 400G transponder.
Is it possible that the number of OTSis supported depends on the operational model. For example. the transport can take an OTUC4 and transport it either over a 400G OTSi or over 4x 100G OTSis.
Is it a realistic scenario?

SB> My understanding of the Dieter's proposal is that the last attrubute in the list
- supported inverse multiplexing capabilities such as max. OTSiG:OTSi cardinality (to be defined)
should cover exactly the HW capability of Transponder , and it would be independent of operational mode.

[Italo] My doubt is that in this case the server reports that the OTSiG:OTSi cardinality is 4 (since it is possible to carry an OTUC4 over 4x OTSi@100G) and that the OTSi supports a 400G operating mode but it does not report that these two capabilities are mutually exclusive since the transponder cannot be configured to carry an OTUC16 over 4xOTSis@400G.

[Dieter] The max OTSiG:OTSi cardinality is one constraint imposed by the OT HW. A max OTSiG data rate in terms of n x 100G is an additional constraint needed for path computation in case inverse muxing is supported. This is not directly related to L0 and optical impairments but should probably be added.

If it is, how can I describe this capability?

SB> see above

I have the feeling that we may need some hierarchical structure with a top level definition of the transponder's capability with e.g., the number of OTSis and then, for each option, the OTSi capabilities?

When the transponder is capable to support 4x 100G OTSis, can we assume that it is always capable to put all of them into a single media channel (if available) or should we describe the capability of the transponder to put multiple OTSis into one media channel?

SB> Why the fact to use 1 or more media channel should impact topology model for optical impairments? It seems to me more a problem of path setup .

[Italo] I agree that it is a problem of path setup/computation but I think it should be addressed otherwise path computation finds a path which is feasible from optical impairments perspective but unfeasible because of transponder capabilities.

[Dieter] I don't think that putting the OTSi signals into one or more media channels is an issue of the optical transponder capabilities.

The model allows for different OTSis to use different operation modes but we expect that in general the same operational model is used.

SB> During last call it was said that it seems reasonable to consider that OTSi belongong to the same OTiG can use the same operational mode.

[Italo] My doubt is not about the possibility to use the same operational model but about the possibility for an implementation to require this. If an implementation requires all the OTSis within the same OTSiG group to use the same operational model for example it would not be possible to carry an OTUC4 over one OTSi@200G and 2xOTSis@100G even if both operational modes are supported. If path computation is not aware of this transponder limitation it could find an optical path which seems feasible but it is actually unfeasible because of transponder capabilities. As above it is not an optical impairment issue but a path setup/computation issue.

[Dieter] As discussed last week, there was agreement that the OTSi signals belonging to the same OTSiG are usually configured homogeneously. However, the YANG model should not prohibit that and shall allow to use different OTSi configurations. If the data rate for the different OTSi signals are different, the OTSiG must be capable to subdivide the OTSiG data accordingly. This will add complexity to the path computation function because the number of potential configurations increases.

Is this an "operational" assumption or are there any hardware limitations that would preclude configuring different operational mode?

In the latter case, I think we would need some flags to report whether the hardware is capable to support different operational modes?
Would it be a a realistic use case to consider cases where the transponder has flexibility also on the client signal configuration (for example it is capable to have as input either an OTUC4 or 4x OTUC1/OTU4)?
If this is the case, maybe not all the combinations between the client digital signal and the OTSi configurations are possible. For example, it is not possible to generate a single 400G OTSi if the digital client is a 4x OTUC1/OTU4,

dieterbeller · 2020-04-16T10:53:49Z

I have also noted that the optical-impairments topology allows one TTP to have multiple transponders (transponders-list* [transponder-id]) but each entry of the the transponder-list defines the capability of one OTSi

Also the DWDM interface model seems describing a transponder with supports only one OTSi

Am I missing something?

[Dieter] This needs to be reviewed and we have to check the TTP definition carefully. The OTSi termination function terminates the photonic signal and the OTSiG termination function performs the is dis-aggregation/aggregation of the OTSiG client signal into multiple OTSi flows.

sergiobelotti · 2020-05-14T09:19:00Z

For the optical impairment aware L0 topology, the modelling of the following optical transponder properties are needed:

Optical transponder capabilities (how it can be configured):

list of supported OTSi operational modes (simple representation of parameter set) including optical impairment limits for each operational mode (min OSNR, max PMD, max CD, max PDL, Q-factor limit, etc.)

Some initial questions/doubts considering for example a 400G transponder.

Is it possible that the number of OTSis supported depends on the operational model. For example. the transport can take an OTUC4 and transport it either over a 400G OTSi or over 4x 100G OTSis.
Is it a realistic scenario?
If it is, how can I describe this capability?
I have the feeling that we may need some hierarchical structure with a top level definition of the transponder's capability with e.g., the number of OTSis and then, for each option, the OTSi capabilities?

When the transponder is capable to support 4x 100G OTSis, can we assume that it is always capable to put all of them into a single media channel (if available) or should we describe the capability of the transponder to put multiple OTSis into one media channel?

The model allows for different OTSis to use different operation modes but we expect that in general the same operational model is used.
Is this an "operational" assumption or are there any hardware limitations that would preclude configuring different operational mode?
In the latter case, I think we would need some flags to report whether the hardware is capable to support different operational modes?

Would it be a a realistic use case to consider cases where the transponder has flexibility also on the client signal configuration (for example it is capable to have as input either an OTUC4 or 4x OTUC1/OTU4)?
If this is the case, maybe not all the combinations between the client digital signal and the OTSi configurations are possible. For example, it is not possible to generate a single 400G OTSi if the digital client is a 4x OTUC1/OTU4,

Related to optical transponder capabilities , we have already a specif issue and comment form Esther
#12

ggrammel · 2020-05-28T13:35:40Z

It may be useful to distinguish the impairment model from routing needs. For the impairment model it is not important if two OTSi carry the same OTUCn or not. For calculating the impairment it would suffice to know the signal itself and the spectral distance to neighbor channels.
On the other hand, for routing, it is quite important to understand the grouping needs of two and more OTSi. However which route can be taken depends on the Line system spectral allocation. In other words, if two OTSi are co-routed, they do not necessarily have to carry a single OTUCn.

So there is a need to identify the co-routing requirement for OTSi, let's call it OTSI-CRG for the time being (members of an OTSIG can be individually routed)

To calculate the feasibility of an OTSi-CRG, one would need to definefor member-OTSi the minimum distance to an OTSi of the same CRG and the additional distance to an OTSi from a different CRG.
That would allow to achieve a dense packing for a CRG with adjacent OTSi where only OTSi at the edge of the CRG would need additional guard bands. In contrast, if all OTSi of the CRG is spread across the available spectrum, each of them would need to keep a guard band to non-CRG neighbor channels.

That would allow

to route individual OTSi of a CRG one by one, only keeping the same route but spread out across the spectrum
to calculate the bandwidth and route the CRG as a whole and set the individial OTSi frequencies to what s allowed by the CRG.
any mix of above.

sergiobelotti · 2020-06-11T13:33:24Z

Related to the discussion had last week and AP to restructure the model taking into account Esther's comment
#12 (comment)
and in the view to reconcile better topology model and interface draft, here uploaded some slides for preliminarry discussion before to modify the model.
transponder-model-YANG-v2.pptx

ggrammel · 2020-06-22T08:37:44Z

Presentation1.pptx
here the deck discussed in the call 2020-06-18 highlighting the issue with standard Application Codes. Those are bound on a specific optical model including fiber-type and do not characterize the interface only.

EstherLerouzic · 2020-06-25T15:10:57Z

Here is my thought of the naming of operational modes
Consider vendor A has « foo » and « bar » transceiver type
Each can have modes
Foo has mode1, mode2
Bar has mode1, mode2, mode3
Then in the capability list for transponder, I expect:

        "transponders-list": [{
            "organization-identifier": “vendor A”,
            "transponder-id": “123”,
            “transceiver-list”:[{
                 “transceiver-id “: “345”,
                 "supported-modes": [{
                    "supported-mode": "mode1"},
                    {
                    "supported-mode": "mode2"},
                    {
                    "supported-mode": "mode3"},
                ]
            }
         ]
     }
 ]

Then where should I put the information that this transceiver is a “foo” transceiver?
If it is concatenated inside the “supported mode” attribute, then how can I recognize the type 100% in the string (that’s a lot of implicit knowledge here) . for example:
"supported-mode": "foo mode1"}? "supported-mode": "foo type mode1"}? "supported-mode": "foo_mode1"}? "supported-mode": "mode1_foo"}? all could be correct from the model point of view, but I can not know which convention is used, nor if it is the same for every type/vendor. So I can not extract the mode name easily, nor the type.

Then how can I avoid wrong implementations such as

        "transponders-list": [{
            "organization-identifier": “vendor A”,
            "transponder-id": “123”,
            “transceiver-list”:[{
                 “transceiver-id “: “345”,
                 "supported-modes": [{
                    "supported-mode": "foo mode1"},
                    {
                    "supported-mode": " mode2_bar"},
                    {
                    "supported-mode": "type foo - mode mode3"},
                ]
            }
         ]
     }
 ]

Which does not make sense because this is the list of a given transceiver capability (foo or bar, not both)
So my suggestion was to separate type and mode to avoid any non defined namings

        "transponders-list": [{
            "organization-identifier": “vendor A”,
            "transponder-id": “123”,
            “transceiver-list”:[{
                 “transceiver-id “: “345”,
                 “transceiver-type”: “foo”,
                 "supported-modes": [{
                    "supported-mode": "mode1"},
                    {
                    "supported-mode": "mode2"},
                    {
                    "supported-mode": "mode3"},
                ]
            }
         ]
     }
 ]

sergiobelotti · 2020-06-29T09:00:21Z

If I got correctly your point and suggestion, the better encoding would be simple to add, in addition to "id" of transceiver also a new leaf indicating the "type" of transceiver and then the related list of possible "modes" supported . Correct?

italobusi · 2020-06-29T21:05:55Z

@EstherLerouzic : I am not sure whether you are assuming that a transponder type « foo » cannot interoperate with a transponder type « bar », even if they are from the same vendor or not.

If it is possible that the two transponder types can interoperate, how can the controller know that e..g, mode 1 for transponder type « foo » can interoperate with mode 2 for transponder type « bar »?

italobusi · 2020-06-29T21:12:19Z

Presentation1.pptx
here the deck discussed in the call 2020-06-18 highlighting the issue with standard Application Codes. Those are bound on a specific optical model including fiber-type and do not characterize the interface only.

@ggrammel : Two questions for clarification based on your slide 4

are you assuming that the application identifier is fully equivalent to an ITU-T standard application code but could also be organizational or vendor specific?
are you assuming that the DWDM-if model shall report, for each "configuration mode" the list of supported standard application codes and organizational/vendor-specific identifiers?
I cannot find this list in the current YANG model

EstherLerouzic · 2020-06-30T06:46:50Z

If I got correctly your point and suggestion, the better encoding would be simple to add, in addition to "id" of transceiver also a new leaf indicating the "type" of transceiver and then the related list of possible "modes" supported . Correct?

Yes !

EstherLerouzic · 2020-06-30T06:57:01Z

@EstherLerouzic : I am not sure whether you are assuming that a transponder type « foo » cannot interoperate with a transponder type « bar », even if they are from the same vendor or not.

If it is possible that the two transponder types can interoperate, how can the controller know that e..g, mode 1 for transponder type « foo » can interoperate with mode 2 for transponder type « bar »?

I have made no assumptions on interoperability: only wanted to highlight foo capability in terms of modes.
The interoperability capability is in my opinion another type of information.
I guess this could be another list for each mode:

    "transponders-list": [{
        "organization-identifier": “vendor A”,
        "transponder-id": “123”,
        “transceiver-list”:[{
             “transceiver-id “: “345”,
             “transceiver-type”: “foo”,
             "supported-modes": [{
                "supported-mode": "mode1",
                "compatible-with": [{
                   "organization-identifier": “vendor A”,
                   “transceiver-type”: “bar”,
                   "mode": mode2
                   },
                   {
                   "organization-identifier": “vendor B”,
                   “transceiver-type”: “alice”,
                   "mode": mode1
                   }]
                },
                {
                "supported-mode": "mode2"},
                {
                "supported-mode": "mode3"},
            ]
        }
     ]
 }

]

ggrammel · 2020-06-30T08:15:57Z

This goes into the same direction as our last discussion about operational modes for interfaces vs. topology. The outcome there was that we need two different identifiers because there is a 1:n relationship between both. So one Identifier that encodes the interoperability (application codes and organizational codes) and another for the interface configuration setting (if-mode).

Hint: https://tools.ietf.org/html/draft-ietf-ccamp-dwdm-if-lmp-02 says:
Note: if the A.I. type = PROPRIETARY, the first 6 Octets of the
Application Identifier in use are six characters of the
PrintableString must contain the Hexadecimal representation of
an OUI (Organizationally Unique Identifier) assigned to the
vendor whose implementation generated the Application
Identifier; the remaining octets of the PrintableString are
unspecified.

IOW it allows organizations to encode more tha just the organization in the string.

ggrammel · 2020-06-30T09:04:55Z

@italobusi

are you assuming that the application identifier is fully equivalent to an ITU-T standard application code but could also be organizational or vendor specific?

The slide wasn't meant to provide a particular semantic for "Application Identifier". We know that the term "Application Code" is reserved for Standardized codes, and for non-standardized codes the term "Application Identifier" is used. So on p.4 I used "Application Identifier" since it appears to be more general.

are you assuming that the DWDM-if model shall report, for each "configuration mode" the list of supported standard application codes and organizational/vendor-specific identifiers?

Yes, this was thanks to Sergio's observation that the if-mode describes only a transceiver and there is a 1:n relationship between if-mode and mode (used by topology-draft). The current dwdm-if YANG model has indeed only a single string that could be used for that purpose.

So for the Interface the following may work. Note that in order to distinguish between different semantics in "modes" I added "if-mode" to indicate this is different from "mode" as used by the current topology draft. The application-identifiers-list may contain application-codes as well as organizational-codes. It's purpose is to trace back applications to if-modes and the dwdm-if model doesn't require a particular semantic.

module: ietf-ext-xponder-wdm-if
     augment /if:interfaces/if:interface:
       +--rw optIfOChRsSs
         <snip>
          +--ro if-supported-mode
          |  +--ro number-of-if-modes-supported?        uint32
          |  +--ro if-mode-list* [if-mode-id]
          |     +--ro if-mode-id                        String
          |     +--ro application-identifiers-list* 
          |        +--ro application-identifiers          String
          |     +--ro min-central-frequency?  layer0-types:frequency-thz
          |     +--ro max-central-frequency?  layer0-types:frequency-thz
          |     +--ro min-channel-input-power?          dbm-t
          |     +--ro max-channel-input-power?          dbm-t
          |     +--ro min-channel-output-power?         dbm-t
          |     +--ro max-channel-output-power?         dbm-t
         <snip>

@EstherLerouzic The proposal is indirectly addressing also the issue you brought up. When connecting two transceivers in the topology model, it is based on application identifiers, but upon selecting the application identifier foo on node A would be configured with its associated if-mode-A and bar on node Z would get its if-mode-Z.

italobusi · 2020-06-30T10:29:35Z

@ggrammel @dieterbeller : Sergio and I have tried to better understand your viewpoint and prepared few slides to describe the two approaches.

if-mode-clarification-00.pptx

To simplify the discussion, let's consider only standard application codes at this stage.

We understand that slide 1 represents the OpenConfig approach, where, the mapping between the application code, selected by path computation, and the if-mode is done internally by the transponder device, while slide 2 represents your proposal where this mapping is done by the domain controller.

Is our understanding correct?

ggrammel · 2020-06-30T10:56:03Z

@italobusi & @sergiobelotti
Thanks for the nice sides, a few questions for clarification:

do B,C,D represent Application identifiers/codes?
is there a special meaning of the grey box on slide-1?
what means "mode 1" in particular on slide-2? does it correspond to an if-mode?
What means the red text on slide-2?

added a 3rd slide to clarify my interpretation. Note that the selection is a little different.

if-mode-clarification-01.pptx

italobusi · 2020-06-30T12:27:31Z

@italobusi & @sergiobelotti
Thanks for the nice sides, a few questions for clarification:

do B,C,D represent Application identifiers/codes?

For the time being, let's assume that A, B, C and D are application codes only

is there a special meaning of the grey box on slide-1?

Yes, the intention is to show that the mapping between if-mode and application code is internal to the transponder device and not exposed to the domain controller

what means "mode 1" in particular on slide-2? does it correspond to an if-mode?

Yes, if-mode

What means the red text on slide-2?

It was text to be rephrased

Slides updated to fix these issues:

if-mode-clarification-02.pptx

added a 3rd slide to clarify my interpretation. Note that the selection is a little different.

if-mode-clarification-01.pptx

Few questions of mine about slide 3:

what do you mean with "setup by NMC"?
if the optical characteristics of the computed path are compliant with both application codes B and C, the path setup is the same no matter which application code is picked-up. The picked-up application code would impact only the if-mode configured on the transceivers.

sergiobelotti · 2020-06-30T12:33:00Z

@italobusi & @sergiobelotti
Thanks for the nice sides, a few questions for clarification:

do B,C,D represent Application identifiers/codes?
We focused "only" in trying to clarify relationship between "standard" ITU-T Application Code and if-mode , then , second step, is clarify relationship with operational mode

is there a special meaning of the grey box on slide-1?
The first slide is in the prospective of OpenConfig approach and "grey" box means that mapping, is not explicit, the mapping between the application code, selected by path computation, and the if-mode is done internally
In the second slide, the same is white, so made explicit by the model and mapping is done with controller.

what means "mode 1" in particular on slide-2? does it correspond to an if-mode?
Yes

What means the red text on slide-2?
no particular meaning

added a 3rd slide to clarify my interpretation. Note that the selection is a little different.

if-mode-clarification-01.pptx

I'm a bit confuse of your added slide: our thought was that you have "interface" set of parameters configured corresponding to an if-mode, covering more than 1 (1:N) possible application. So I do not understand the meaning of your slide with respect the other , in particular slide 2

italobusi · 2020-10-26T17:16:18Z

here is a change proposal for the text.
Transponder-text-section-2.5_elr.docx
I added a table with my understanding of the explicit/implicit presence of parameters

@EstherLerouzic : I'm generally fine with the table . One comment: you wrote
"
-maximum channel
power on receiver
-max total power on receiver
Are not the same ??? In the model we have "rx-total-power-max" .
About your comment " I thought that there was a leaf ref to the configured mode, no ? and maybe the instance related settings such as current optical emitter power, frequency, ..."
Yes , it is exactly what you describe. I will add text along your lines.
Herewith attached the new proposed text.
Transponder-text-section-2.5_elr-sb-261020.docx

Additional comments/text proposals:
Transponder-text-section-2.5_elr-sb-261020-ib.docx

ggrammel · 2020-10-27T14:30:09Z

Wondering if there is some misunderstanding to clarify. Looking at the table, it references for the Organizational mode that a set of explicit parameters in column-2 would be "explicit". Is it a typo?

My understanding is:

A mode defined along the line of G.698.2 would also cover the parameters in column-2.
The recent decision to use Model 1B, confined detailed parameters to the Explicit mode. This enabled to keep the parameters for Application code and Organizational code implicit.
Model 1B addressed also the case of an Explicit mode providing reference to application/organizational modes. This allowed to cover cases where explicit parameters are available for the transponder that supports one or more application/organizational modes. https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/files/5104243/if-mode-clarification_options-200820-github.pptx
@italobusi , @sergiobelotti is this your understanding too?

italobusi · 2020-10-27T15:01:52Z

Wondering if there is some misunderstanding to clarify. Looking at the table, it references for the Organizational mode that a set of explicit parameters in column-2 would be "explicit". Is it a typo?

My understanding is:

A mode defined along the line of G.698.2 would also cover the parameters in column-2.

The recent decision to use Model 1B, confined detailed parameters to the Explicit mode. This enabled to keep the parameters for Application code and Organizational code implicit.

Model 1B addressed also the case of an Explicit mode providing reference to application/organizational modes. This allowed to cover cases where explicit parameters are available for the transponder that supports one or more application/organizational modes. https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/files/5104243/if-mode-clarification_options-200820-github.pptx
@italobusi , @sergiobelotti is this your understanding too?

@ggrammel : I share your understanding of model 1B but I am not sure I have understood your initial point about misunderstanding in the table.

I assume you are referring to the table proposed in https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/files/5424280/Transponder-text-section-2.5_elr.docx

My understanding is that:

in the explicit mode all the attributes are explicit
in the application code all the attributes are implicit
in the organizational mode most of the attributes are implicit but some (i.e., those listed in column-2 of the table) are explicit

In other words, it seems that for the attributes in column-2, ITU-T application codes and organizational modes have adopted a different approach.

The YANG model and the table seem align with this understanding.

ggrammel · 2020-10-27T15:25:02Z

#29 (comment) was setting out that
" Organizational Mode: An organizational mode represents a non-standard optical interface specification towards the realization of transversely compatible DWDM systems. Two transceivers supporting the same organizational mode
and a line system matching the constraints, defined by the organization which owns the mode, for that organizational will interoperate. These organizations can be MSA-Groups, Operators, System vendors, component vendors etc."
So apart from the organization, Application Code and organizational mode are considered the same.

e.g. Min/Max frequency and tunability grid are part of the definition in e.g. OpenROADM and is in line with the G.698.2 table. Parameters like this do not show up in Model-1B outside for the Explicit mode. It is confusing to see those popping up at a location where they were intended to be hidden in the first place.

sergiobelotti · 2020-10-27T15:43:54Z

Wondering if there is some misunderstanding to clarify. Looking at the table, it references for the Organizational mode that a set of explicit parameters in column-2 would be "explicit". Is it a typo?
My understanding is:

A mode defined along the line of G.698.2 would also cover the parameters in column-2.

The recent decision to use Model 1B, confined detailed parameters to the Explicit mode. This enabled to keep the parameters for Application code and Organizational code implicit.

Model 1B addressed also the case of an Explicit mode providing reference to application/organizational modes. This allowed to cover cases where explicit parameters are available for the transponder that supports one or more application/organizational modes. https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/files/5104243/if-mode-clarification_options-200820-github.pptx
@italobusi , @sergiobelotti is this your understanding too?

@ggrammel : I share your understanding of model 1B but I am not sure I have understood your initial point about misunderstanding in the table.

@ggrammel : Yes, your understanding of the model 1B is correct.

I assume you are referring to the table proposed in https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/files/5424280/Transponder-text-section-2.5_elr.docx

My understanding is that:

in the explicit mode all the attributes are explicit

in the application code all the attributes are implicit

in the organizational mode most of the attributes are implicit but some (i.e., those listed in column-2 of the table) are explicit

@italobusi : Yes, you got correctly . The only parameters that also organizational mode is showing up is the range of soem attributes like rx-power-channel or tx-power-channel as we discussed and agreed in #29 (comment)
-supported transmitter tuning range [f_tx_min, f_tx_max]
-supported transmitter tunability grid (in GHz)
-supported transmitter power range [p_tx-min, p_tx_max]
-supported receiver power range [p_rx-min, p_rx_max]

In other words, it seems that for the attributes in column-2, ITU-T application codes and organizational modes have adopted a different approach.

@ggrammel : correct, this is also my understanding of organizational mode, the parameters I've indicated above are not implicit in the organizational mode.

The YANG model and the table seem align with this understanding.
@italobusi @ggrammel : yes , there is complete alignment

ggrammel · 2020-10-27T16:56:14Z

This is still confusing.
The text says "So apart from the organization, Application Code and organizational mode are considered the same."
If so, why is there a need to define things like tuning range explicitly for organizational codes only?

It appears the change in the model came with the merge 11 days ago, but it is not really clear to me what caused this change.

In any case the Text seems to contradict itself and needs to be cleaned up.

sergiobelotti · 2020-10-27T18:18:09Z

This is still confusing.
The text says "So apart from the organization, Application Code and organizational mode are considered the same."
If so, why is there a need to define things like tuning range explicitly for organizational codes only?

It appears the change in the model came with the merge 11 days ago, but it is not really clear to me what caused this change.

In any case the Text seems to contradict itself and needs to be cleaned up.
@ggrammel : I do not see in the proposed text https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/files/5440306/Transponder-text-section-2.5_elr-sb-261020-ib.docx
the sentence you reported, and this is made on purpose.
What defined in the YANG model for organizational mode corresponds to what described in the #29 (comment) and never changed . The range limitation for some parameters appears explicitly in the organizational mode . This is different with respect application code.
Nothing change with respect what discussed many times.

ggrammel · 2020-10-27T19:09:25Z

seems the references are all a bit coarse, let me try to describe the location in addition to the links, so that it is easier to find, it's a bit hard to summarize everything:

We had a discussion about the relationship between Application Code and Organizational mode on this thread:
"italobusi commented on Jul 22" where this was confirmed: "The current text is written under the assumption that the workflow for operational mode and application codes is the same and the only difference is on the entity responsible to define the application code/operational mode."
The current text contains in the definition section:

"Application Code: An application code represents a standard G.698.2 optical interface specification towards the realization of transversely compatible DWDM systems. Two transceivers supporting the same application code and a line system matching the constraints, defined in ITU-T G.698.2, for that application code will interoperate."

" Organizational Mode: An organizational mode represents a non-standard optical interface specification towards the realization of transversely compatible DWDM systems. Two transceivers supporting the same organizational mode and a line system matching the constraints, defined by the organization which owns the mode, for that organizational will interoperate. These organizations can be MSA-Groups, Operators, System vendors, component vendors etc."

So when comparing it to definition of Application Code, my reading is that apart from the organization, Application Code and organizational mode are considered the same.

The models discussed e.g. sergiobelotti commented on Jul 24 •
Modelling of Transponders #29 (comment) did not show explicit parameters for organizational codes. Also the YANG slides don't show anything: https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/files/5104243/if-mode-clarification_options-200820-github.pptx

What the discussion highlighted is that there is a discrepancy in the understanding about what an organizational code describes and we need to get this straight. Let me try to describe the issue it in other words:

IF the set of explicit parameters like "min/max frequency" would be required to allow interoperability with Operational modes, THEN the following condition of the description of Organizational mode is not met:

Two transceivers supporting the same organizational mode and a line system matching the constraints, defined by the organization which owns the mode, for that organizational will interoperate.

dieterbeller · 2020-10-29T14:04:47Z

Meanwhile, I found some time for drafting some text describing the Organizational Mode option re transceiver capabilities:

Organizational Mode:
Organizations like operator groups, industry fora, or equipment vendors can define organizational modes, which will allow these organizations to make use of advanced transceiver capabilities going beyond existing standardized application codes. Such an organizational mode is identified by the organization-identifier attribute defining the scope and an operational-mode that is meaningful within the scope of the organization. Hence, the two attributes must always be considered together. Two transceivers are inter-operable, if they have at least one (organization-identifier, operational-mode) pair in common. This is a necessary condition for path computation in the context of organizational modes. An operational mode is a transceiver preset (a configuration with well-defined parameter values) subsuming several transceiver properties including:
• FEC type
• Modulation scheme
• Encoding (mapping of bit patterns to symbols in the constellation diagram)
• Baud rate (symbol rate)
• Carrier bandwidth (typically measured in GHz)

The major reason for these transceiver presets, is that the attribute values typically cannot be configured independently and are therefore advertised as supported operational mode capabilities.
It is the responsibility of the organization to assign operational modes and to ensure that operational modes are unique and not ambiguous within the scope of the organization.
In addition to the transceiver properties subsumed by the operational mode, there are configuration parameters that can be configured independently and are therefore handled individually like carrier the frequency of the modulated carrier in transmit and receive direction as well as the transmit power including the supported ranges. The received channel power and the received total power are other parameters that can be measured and can be provided by the transceiver in order to allow a controller to determine the expected performance of the end-to-end service taking into account the optical impairments along the path.

ggrammel · 2020-10-29T15:39:04Z

no issue with this text

ggrammel · 2020-10-29T15:40:50Z

2020-10-29 AI:

@dieterbeller : Provide complete list of desired parameters to add to the operational mode definition

egriseri · 2020-10-29T17:07:42Z

May I suggest to add a couple of lines to specify the ratio of having a subset of parameters explicitly reported? Something like this “A subset of the transceiver properties subsumed by the operational mode may be explicitly exposed; this allows transceivers of different performances interoperate without the need to introduce a specific operational mode. One use case includes transceivers which differ only by the input power sensitivities. Another use case include transceivers which differ only by the tunability range of the carrier frequency. The set of transceiver characteristic explicitly exposed is limited to input and output power and tunability capabilities of the transceiver.”

ggrammel · 2020-10-30T08:45:16Z

@egriseri the use case described had been discussed when taking the decision for Model 1B. The Explicit mode allows to define parameters such as different receiver sensitivity or tunability ranges. In particular, https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/files/5104243/if-mode-clarification_options-200820-github.pptx introduced a ro supported-standard-mode*? leafref allowing to reference a standard mode (meaning application code or organizational mode) that is supported by these explicit parameters.
The desire was to keep the Application code and organizational mode as simple matching condition, while detailed parameters were pushed to the explicit mode where parameter checks need to apply naturally.

The Issues I have with the approach to add explicit parameters to extend the operational mode are:

a compatibility check practically becomes the same as the compatibility check required for the explicit mode: all parameters and ranges need to fit. The intention however was to use it as a sole matching criteria.
What are the limits for adding additional parameters to further extend the operational mode? Adding many explicit parameters making it practically the same as the explicit mode.
The explicit mode has a leafref (described above) to the organizational mode. By which mechanism can we exclude an inconsistency between explicit parameters defined in the explicit mode referencing an operational mode and explicit parameters defined there?

In summary: parameters defining an organizational mode should stay implicit to support simple matching conditions. Where extensions are required, an explicit mode with reference to the organizational mode appears to do the job.

dieterbeller · 2020-10-30T11:38:01Z

Based on Enrico's comment #29 (comment), I updated the text above (see #29 (comment)) as follows:

Organizational Mode:
Organizations like operator groups, industry fora, or equipment vendors can define organizational modes, which will allow these organizations to make use of advanced transceiver capabilities going beyond existing standardized application codes. Such an organizational mode is identified by the organization-identifier attribute defining the scope and an operational-mode that is meaningful within the scope of the organization. Hence, the two attributes must always be considered together. Two transceivers are inter-operable, if they have at least one (organization-identifier, operational-mode) pair in common and if the supported carrier frequency and power attributes have a matching range. This is a necessary condition for path computation in the context of organizational modes. An operational mode is a transceiver preset (a configuration with well-defined parameter values) subsuming several transceiver properties including:
• FEC type
• Modulation scheme
• Encoding (mapping of bit patterns to symbols in the constellation diagram)
• Baud rate (symbol rate)
• Carrier bandwidth (typically measured in GHz)

The major reason for these transceiver presets is the fact that the attribute values typically cannot be configured independently and are therefore advertised as supported operational mode capabilities.
It is the responsibility of the organization to assign operational modes and to ensure that operational modes are unique and not ambiguous within the scope of the organization.
In addition to the transceiver properties subsumed by the operational mode, optical power and carrier frequency related properties are modeled separately, i.e., outside of the operational mode. This modeling approach allows transponders using different transceiver variants (e.g. optical modules) with slightly different power and/or frequency range properties to interoperate without defining separate operational modes. Different optical modules (pluggables) from different suppliers typically have slightly different input and output power ranges or may have slightly different carrier frequency tuning ranges.
The received channel power and the received total power are two parameters that can be measured by the receiver and can be provided by the transceiver in order to allow a controller to determine the expected performance of the end-to-end service taking into account the optical impairments along the path.

ggrammel · 2020-10-30T11:46:51Z

@dieterbeller: the new text would need discussion. While there are always differences between implementations and samples, they are supposed to be considered by the MSA-organization in such a way that they interoperate. Suggestion is to first nail down the requirements before jumping in a solution.
As a starting point, the commonly agreed definition adopted by the group is:
" Organizational Mode: An organizational mode represents a non-standard optical interface specification towards the realization of transversely compatible DWDM systems. Two transceivers supporting the same organizational mode and a line system matching the constraints, defined by the organization which owns the mode, for that organizational will interoperate. These organizations can be MSA-Groups, Operators, System vendors, component vendors etc."

sergiobelotti · 2020-10-30T15:08:41Z

@ggrammel : the intent of the transponder model part is exactly to "model" not invent , the existing way to determine optical signal compatibility. This why we have described in YANG with the triplet (standard, organizational and explicit).
Text proposed perfectly describes what it is the sate of art of organizational mode, how it works, no alternative on that, and obviously who has implementation on that knows very well this. We do not have need of requirements to describe what is already there , in field.
The text you mention, is "my" proposal that obviously has been completed and improved by Dieter and Enrico suggestion.
I've already updated text of section 2.5 along these lines and uploaded

here is a change proposal for the text.
Transponder-text-section-2.5_elr.docx
I added a table with my understanding of the explicit/implicit presence of parameters

@EstherLerouzic : I'm generally fine with the table . One comment: you wrote
"
-maximum channel
power on receiver
-max total power on receiver
Are not the same ??? In the model we have "rx-total-power-max" .
About your comment " I thought that there was a leaf ref to the configured mode, no ? and maybe the instance related settings such as current optical emitter power, frequency, ..."
Yes , it is exactly what you describe. I will add text along your lines.
Herewith attached the new proposed text.
Transponder-text-section-2.5_elr-sb-261020.docx

Additional comments/text proposals:
Transponder-text-section-2.5_elr-sb-261020-ib.docx

@italobusi @EstherLerouzic : Taking into account the new text from Dieter #29 (comment)
I've uploaded the new section 2.5 to be used for uploading of the new version of the draft in the view of IETF 109. Remain open some comment about definitions from Italo but we can survive with the present text for uploading and take the action to verify with our internal Q6 expert for better definition of transponder/transceiver.
Transponder-text-section-2.5_301020.docx

ggrammel · 2020-10-30T17:36:08Z

@sergiobelotti<mailto:notifications@github.com> can you be more specific about “organizational mode, how it works”? In past discussions @Dieter claimed it would be a simple match condition in OpenConfig. If the purpose of the operational mode is to mimic how OpenConfig works, then what needs to change? The model there looks like this: https://github.com/openconfig/public/blob/master/release/models/optical-transport/openconfig-terminal-device.yang leaf operational-mode { type uint16; description "Vendor-specific mode identifier -- sets the operational mode for the channel. The specified operational mode must exist in the list of supported operational modes supplied by the device"; // // Ideally, this leaf should be a leafref to the supported // operational modes, but YANG 1.0 does not allow a r/w // leaf to be a leafref to a r/o leaf. } From: sergiobelotti <notifications@github.com> Reply-To: ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang <reply@reply.github.com> Date: Friday, October 30, 2020 at 16:09 To: ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang <draft-ietf-ccamp-optical-impairment-topology-yang@noreply.github.com> Cc: Gert Grammel <ggrammel@juniper.net>, Mention <mention@noreply.github.com> Subject: Re: [ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang] Modelling of Transponders (#29) [External Email. Be cautious of content] @ggrammel<https://github.com/ggrammel> : the intent of the transponder model part is exactly to "model" not invent , the existing way to determine optical signal compatibility. This why we have described in YANG with the triplet (standard, organizational and explicit). Text proposed perfectly describes what it is the sate of art of organizational mode, how it works, no alternative on that, and obviously who has implementation on that knows very well this. We do not have need of requirements to describe what is already there , in field. The text you mention, is "my" proposal that obviously has been completed and improved by Dieter and Enrico suggestion. I've already updated text of section 2.5 along these lines and uploaded here is a change proposal for the text. Transponder-text-section-2.5_elr.docx<https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/files/5424280/Transponder-text-section-2.5_elr.docx> I added a table with my understanding of the explicit/implicit presence of parameters @EstherLerouzic<https://github.com/EstherLerouzic> : I'm generally fine with the table . One comment: you wrote " -maximum channel power on receiver -max total power on receiver Are not the same ??? In the model we have "rx-total-power-max" . About your comment " I thought that there was a leaf ref to the configured mode, no ? and maybe the instance related settings such as current optical emitter power, frequency, ..." Yes , it is exactly what you describe. I will add text along your lines. Herewith attached the new proposed text. Transponder-text-section-2.5_elr-sb-261020.docx<https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/files/5438399/Transponder-text-section-2.5_elr-sb-261020.docx> Additional comments/text proposals: Transponder-text-section-2.5_elr-sb-261020-ib.docx<https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/files/5440306/Transponder-text-section-2.5_elr-sb-261020-ib.docx> @italobusi<https://github.com/italobusi> @EstherLerouzic<https://github.com/EstherLerouzic> : Taking into account the new text from Dieter ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang#29 (comment)<#29 (comment)> I've uploaded the new section 2.5 to be used for uploading of the new version of the draft in the view of IETF 109. Remain open some comment about definitions from Italo but we can survive with the present text for uploading and take the action to verify with our internal Q6 expert for better definition of transponder/transceiver. Transponder-text-section-2.5_301020.docx<https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/files/5465887/Transponder-text-section-2.5_301020.docx> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#29 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADTQOVFPMA4TRGDBO3SLHFLSNLJIVANCNFSM4LC6BAFA>. Juniper Business Use Only

EstherLerouzic · 2020-10-30T17:42:35Z

This discussion with multiple embedded comments is quite hard to follow :)
To answer italo question (4 days ago) on this:

-max total power on receiver
Are not the same ??? In the model we have "rx-total-power-max" .

I just copied the list of bullet points that were on the text and wrapped them a bit... So I may have misunderstods these two bullet points (listed in the docx file). here is my understanding:
• supported receiver power range [p_rx-min, p_rx_max] x channel -> this one is per channel
• supported maximum total power, rx power for all the channels -> this one is for the aggregated power (sum of all carriers power received)

I have read https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/files/5465887/Transponder-text-section-2.5_301020.docx and have no comment for the text, except that maybe we need to better name "supported receiver power range" and "supported maximum total power"

thanks !

egriseri · 2020-10-30T18:32:21Z

@ggrammel

The desire was to keep the Application code and organizational mode as simple matching condition, while detailed parameters were pushed to the explicit mode where parameter checks need to apply naturally.

Your intent is clear, but is not what I understood for the organizational mode.

The Issues I have with the approach to add explicit parameters to extend the operational mode are:

a compatibility check practically becomes the same as the compatibility check required for the explicit mode: all parameters and ranges need to fit. The intention however was to use it as a sole matching criteria.

This is not my understanding. The interoperability is done by matching of (organization-identifier, operational-mode). Letting optical power and carrier frequency related properties avoid un-necessary duplication of operational modes in case sligthly different optical front end are used.

What are the limits for adding additional parameters to further extend the operational mode? Adding many explicit parameters making it practically the same as the explicit mode.

The explicit parameters are listed in @dieterbeller answer (and in the agreed Yang code). No more.

The explicit mode has a leafref (described above) to the organizational mode. By which mechanism can we exclude an inconsistency between explicit parameters defined in the explicit mode referencing an operational mode and explicit parameters defined there?

In summary: parameters defining an organizational mode should stay implicit to support simple matching conditions. Where extensions are required, an explicit mode with reference to the organizational mode appears to do the job.

See answers above.

ggrammel · 2020-10-30T18:52:58Z

@egriseri<mailto:notifications@github.com> 1. what is your understanding of an Operational Mode? Is this understanding in line with OpenConfig definitions or any other organization? Would be great to align here. 2. If the interoperability is done by matching of (organization-identifier, operational-mode), then there is no need to check anything. However when you add a frequency range to organizational modes and the frequency range of transmitter and receiver are different, then there is no interoperability on the non-overlapping range. This complicates the path calculation quite a bit. 3. Thanks for confirming that the parameters are exactly the ones in discussion and are not going to be extended. 4. What are your thoughts about how to circumvent the incompatibility issue? From: egriseri <notifications@github.com> Reply-To: ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang <reply@reply.github.com> Date: Friday, October 30, 2020 at 19:32 To: ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang <draft-ietf-ccamp-optical-impairment-topology-yang@noreply.github.com> Cc: Gert Grammel <ggrammel@juniper.net>, Mention <mention@noreply.github.com> Subject: Re: [ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang] Modelling of Transponders (#29) [External Email. Be cautious of content] @ggrammel<https://github.com/ggrammel> The desire was to keep the Application code and organizational mode as simple matching condition, while detailed parameters were pushed to the explicit mode where parameter checks need to apply naturally. Your intent is clear, but is not what I understood for the organizational mode. The Issues I have with the approach to add explicit parameters to extend the operational mode are: 1. a compatibility check practically becomes the same as the compatibility check required for the explicit mode: all parameters and ranges need to fit. The intention however was to use it as a sole matching criteria. This is not my understanding. The interoperability is done by matching of (organization-identifier, operational-mode). Letting optical power and carrier frequency related properties avoid un-necessary duplication of operational modes in case sligthly different optical front end are used. 1. What are the limits for adding additional parameters to further extend the operational mode? Adding many explicit parameters making it practically the same as the explicit mode. The explicit parameters are listed in @dieterbeller<https://github.com/dieterbeller> answer (and in the agreed Yang code). No more. 1. The explicit mode has a leafref (described above) to the organizational mode. By which mechanism can we exclude an inconsistency between explicit parameters defined in the explicit mode referencing an operational mode and explicit parameters defined there? In summary: parameters defining an organizational mode should stay implicit to support simple matching conditions. Where extensions are required, an explicit mode with reference to the organizational mode appears to do the job. See answers above. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#29 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADTQOVAF333TJFILE23J3N3SNMBEJANCNFSM4LC6BAFA>. Juniper Business Use Only

egriseri · 2020-11-02T18:55:31Z

@egriseri mailto:notifications@github.com

what is your understanding of an Operational Mode? Is this understanding in line with OpenConfig definitions or any other organization? Would be great to align here.

My personal understanding of Operational Mode is mainly to avoid un-necessary duplication of Organizational Modes in case many vendors (or the same vendor) have interoperable optics with small differences in power range and tunability. This happens even within the same vendor portfolio, thus why impose a duplication?
From another perspective the Operational Mode subsumes what really matters for interoperability between transceivers and separates it from properties that in a DWDM system are not actually needed for interoperability. As an example, the input power to a transceiver is determined by the ROADM architecture and settings, thus it is irrelevant if the RX transceiver range matches the transmitter receiver.

In OpenConfig, I read that the optical channel in OpenConfig is configured by the (carrier) frequency, target-output-power, as well as by an operational mode.

If the interoperability is done by matching of (organization-identifier, operational-mode), then there is no need to check anything. However when you add a frequency range to organizational modes and the frequency range of transmitter and receiver are different, then there is no interoperability on the non-overlapping range. This complicates the path calculation quite a bit.

I'm sorry I disagree: in a DWDM system power and frequency ranges must be in any case be checked against the DWDM system settings and capabilities. This is always required no matter the Application Code, Organizational Mode or Explicit Mode is used.

Thanks for confirming that the parameters are exactly the ones in discussion and are not going to be extended.

You're welcome. The rationale is to collect under the Operational Mode "what really matters" for interoperability.

What are your thoughts about how to circumvent the incompatibility issue?

Don't we have the same issue when an Application Code is referenced to from within an Explicit Mode?

YANG model and tree view aligned with ietf-optical-impairment-topology.yang and ietf-optical-impairment-topology.tree on GitHub, Section "2.5 Transpomders" updated based on Open Issue #29

ggrammel · 2020-11-04T19:35:35Z

@egriseri trying to summarize in a copy/paste session from your earlier comment to make it more readable:

1a) My personal understanding of Operational Mode is mainly to avoid un-necessary duplication of Organizational Modes
Agree, that's why I wasn't keen to go for "simple matching as in OpenConfig". The introduction of interface modes (essentially explicit mode now) addressed that. At least we are in agreement about the need to avoid code-inflation.
2) "in a DWDM system power and frequency ranges must be in any case be checked against the DWDM system settings and capabilities."
That's why power and frequency ranges are defined in the Application code and in Organizational specifications (e.g. OpenROADM). IOW because those ranges would be implicitly specified as part of the code/identifier and there would be no need to perform extra checks beyond what is in that definition.
3) "From another perspective the Operational Mode subsumes what really matters for interoperability between transceivers and separates it from properties that in a DWDM system are not actually needed for interoperability." yep, this was the rationale to introduce interface-modes.
4) Don't we have the same issue when an Application Code is referenced to from within an Explicit Mode?
in the Application code case, the parameters are implicit (i.e. hidden from a model standpoint) in the Application code. The explicit mode allowed to extend those with explicit ones e.g. frequency range. The same would have been true for organizational codes. Now the organizational code contains the implicit range (e.g. OpenROADM), and an explicit range and the explicit code could reference that organizational mode overlapping parameters.
Let's set-out a simple rule: the more specialized parameter takes precedence:

Application Identifiers carry ONLY implicit parameters. Can the organizational code carry implicit parameters (e.g. frequency ranges)?
When exposing an explicit range in an OC, the explicit range takes precedence over implicit ranges of that OC
if an explicit mode points to an AI/OC the parameters provided in the explicit mode take precedence.

sergiobelotti · 2021-01-19T17:00:05Z

closed issue with commit 8b7c07e

@ggrammel

Text proposed by @ggrammel : ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang#29 (comment)

Proposed changes: ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang#29 (comment)

italobusi mentioned this issue Mar 6, 2020

YANG model for ROADM optical impairments #28

Merged

sergiobelotti mentioned this issue Apr 22, 2020

Transponder typedefs and groupings ietf-ccamp-wg/ietf-ccamp-layer0-types-ext-RFC9093-bis#2

Closed

egriseri closed this as completed Oct 29, 2020

ggrammel reopened this Oct 30, 2020

sergiobelotti closed this as completed Jan 19, 2021

italobusi added a commit to ietf-ccamp-wg/ietf-ccamp-layer0-types-ext-RFC9093-bis that referenced this issue Feb 4, 2021

Update modes-definitions.txt

0af5451

Text proposed by @ggrammel : ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang#29 (comment)

italobusi added a commit to ietf-ccamp-wg/ietf-ccamp-layer0-types-ext-RFC9093-bis that referenced this issue Feb 4, 2021

Update modes-definitions.txt

326f940

Proposed changes: ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang#29 (comment)

sergiobelotti mentioned this issue Feb 9, 2021

need to better specify minimum-channel-spacing parameter #42

Closed

Modelling of Transponders #29

Modelling of Transponders #29

Comments

italobusi commented Mar 6, 2020

italobusi commented Mar 6, 2020

italobusi commented Mar 12, 2020

italobusi commented Mar 19, 2020

dieterbeller commented Apr 7, 2020 • edited Loading

sergiobelotti commented Apr 8, 2020 • edited by dieterbeller Loading

italobusi commented Apr 14, 2020

sergiobelotti commented Apr 15, 2020 • edited Loading

italobusi commented Apr 16, 2020

italobusi commented Apr 16, 2020

italobusi commented Apr 16, 2020

dieterbeller commented Apr 16, 2020

dieterbeller commented Apr 16, 2020

sergiobelotti commented May 14, 2020

ggrammel commented May 28, 2020

sergiobelotti commented Jun 11, 2020

ggrammel commented Jun 22, 2020

EstherLerouzic commented Jun 25, 2020

sergiobelotti commented Jun 29, 2020

italobusi commented Jun 29, 2020

italobusi commented Jun 29, 2020

EstherLerouzic commented Jun 30, 2020

EstherLerouzic commented Jun 30, 2020

ggrammel commented Jun 30, 2020

ggrammel commented Jun 30, 2020

italobusi commented Jun 30, 2020 • edited Loading

ggrammel commented Jun 30, 2020

italobusi commented Jun 30, 2020

sergiobelotti commented Jun 30, 2020

italobusi commented Oct 26, 2020

ggrammel commented Oct 27, 2020

italobusi commented Oct 27, 2020 • edited Loading

ggrammel commented Oct 27, 2020

sergiobelotti commented Oct 27, 2020

ggrammel commented Oct 27, 2020

sergiobelotti commented Oct 27, 2020

ggrammel commented Oct 27, 2020

dieterbeller commented Oct 29, 2020

ggrammel commented Oct 29, 2020

ggrammel commented Oct 29, 2020

egriseri commented Oct 29, 2020 via email • edited Loading

ggrammel commented Oct 30, 2020 • edited Loading

dieterbeller commented Oct 30, 2020

ggrammel commented Oct 30, 2020

sergiobelotti commented Oct 30, 2020

ggrammel commented Oct 30, 2020 via email

EstherLerouzic commented Oct 30, 2020

egriseri commented Oct 30, 2020

ggrammel commented Oct 30, 2020 via email

egriseri commented Nov 2, 2020

ggrammel commented Nov 4, 2020

sergiobelotti commented Jan 19, 2021

dieterbeller commented Apr 7, 2020 •

edited

Loading

sergiobelotti commented Apr 8, 2020 •

edited by dieterbeller

Loading

sergiobelotti commented Apr 15, 2020 •

edited

Loading

italobusi commented Jun 30, 2020 •

edited

Loading

italobusi commented Oct 27, 2020 •

edited

Loading

egriseri commented Oct 29, 2020 via email •

edited

Loading

ggrammel commented Oct 30, 2020 •

edited

Loading