Modelling of Transponders

[italobusi]

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

It is suggested to reconcile these models

[italobusi]

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]

See also open issues ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang#5; ietf-ccamp-wg/ietf-ccamp-layer0-types-ext#47; ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang#12 and ietf-ccamp-wg/ietf-ccamp-layer0-types-ext#51

[italobusi]

See also https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-layer0-types/issues/5

[dieterbeller]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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 https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/12

[ggrammel]

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]

Related to the discussion had last week and AP to restructure the model taking into account Esther's comment https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/12#issuecomment-507734476 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]

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]

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]

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]

@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]

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

1) 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?

2) 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]

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]

@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]

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]

@italobusi

1. 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.

2. 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]

@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]

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

1. do B,C,D represent Application identifiers/codes?
2. is there a special meaning of the grey box on slide-1?
3. what means "mode 1" in particular on slide-2? does it correspond to an if-mode?
4. 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]

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

1. 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

2. 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

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

Yes, if-mode

4. 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]

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

1. 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

2. 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.

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

4. 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

[ggrammel]

@sergiobelotti the difference between p.2 and p.3 is mainly that p.2 identifies the if-mode explicitly, while p.3 uses the application identifier to find the right if-mode. Also aiming to get the nomenclature a bit more explicit to avoid discussing about "modes" meaning different things. I.e. I interpret your response to 1 as a "yes".

@italobusi

what do you mean with "setup by NMC"?

Sergio used the term and I understood it to mean the entity that exposes the topology model. I am not sure if it is an important detail or not though.

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.

the point here is that one could pick if-mode-1 corresponding to B at one end and if-mode-2 corresponding to C on the other end. While it should work, it isn't a very nice setup. Therefore, as outlined in 3 the NMC should indicate which application code to use and the corresponding if-mode is picked consistently.

[sergiobelotti]

@sergiobelotti the difference between p.2 and p.3 is mainly that p.2 identifies the if-mode explicitly, while p.3 uses the application identifier to find the right if-mode. Also aiming to get the nomenclature a bit more explicit to avoid discussing about "modes" meaning different things. I.e. I interpret your response to 1 as a "yes". @ggrammel We used explicit indication of if-mode since being a device operation was more clear to explicit indicate the if-mode summarizing a list of "internal" register parameters. About question 1 , yes A,B,C are Application code. Be carefull that we used always the term Application Code . Application identifier is a "dangerous" term since implies different meaning in ITU-T but surely not only standard Application Code. Application identifier typically assume you are comply to Application code + private parameters. I can show many example for that. So we suggest to use correct terminology in our discussion: in topology model we have separated the standard application (Application Code) from what can be private, i.e. Operational mode, and mixing again things with Application identifier does not simplify common understanding and correct encoding.

@italobusi

what do you mean with "setup by NMC"?

Sergio used the term and I understood it to mean the entity that exposes the topology model. I am not sure if it is an important detail or not though.

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.

the point here is that one could pick if-mode-1 corresponding to B at one end and if-mode-2 corresponding to C on the other end. While it should work, it isn't a very nice setup. Therefore, as outlined in 3 the NMC should indicate which application code to use and the corresponding if-mode is picked consistently.

[italobusi]

@italobusi

what do you mean with "setup by NMC"?

Sergio used the term and I understood it to mean the entity that exposes the topology model. I am not sure if it is an important detail or not though.

Maybe it is better to use the term "domain controller" to represent the entity responsible to perform path computation&setup and to configure the TX and RX transceivers.

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.

the point here is that one could pick if-mode-1 corresponding to B at one end and if-mode-2 corresponding to C on the other end. While it should work, it isn't a very nice setup. Therefore, as outlined in 3 the NMC should indicate which application code to use and the corresponding if-mode is picked consistently.

That's was the intended difference between slide 1 and slide 2: in slide 1, the domain controller configures the application code selected based on path computation results, while in slide 2 the domain controller configured the if-mode which supports the application code selected based on path computation results,

What would be the difference between slide 1 and slide 3?

[ggrammel]

@Italo,

In the deck if-mode-clarification-01.pptx slide-1 uses if-modes for step-2 and 3 while slide 3 uses application-modes. The difference is where the translation if-mode to/from app-mode is performed. Take it as a working proposal.

[sergiobelotti]

@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 @EstherLerouzic
Esther is talking about "tranceiver type" , Italo is mentioning "transponder type" , which of the two is in discussion

[italobusi]

@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 @EstherLerouzic Esther is talking about "tranceiver type" , Italo is mentioning "transponder type" , which of the two is in discussion

@sergiobelotti : it was a mistake on my side. My comment should have been:

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

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

I think that Easter has replied to this question

[italobusi]

Slides updated after an offline discussion between Italo, Sergio and Gert:

if-mode-clarification-03.pptx

Slide 3 now describes the case where the explicit mode is used.

[ggrammel]

Suggested wording about Explicit Mode:

in this document we distinguish the following definitions

Application Code: AN application code is defined by ITU-T G.698.2 and defines interoperability. Two transceivers supporting the same application code and a line system matching the constraints of that application mode will interoperate.

Organizational Code: An organizational code is a non-standard code that enables interoperability between Transceivers of that type and associated network conditions. It is up to the defining Entity to define Organizational Codes in a manner that guarantees interoperability. Organizations can be MSA-Groups, Operators, System vendors, component vendors etc.

if-mode: An Interface-mode is a defined set of parameters that identifies a configuration validated by the system vendors. The if-mode is an identifier for an explicit set of parameters. each interface can support 1 or more if-modes and can be referenced by the relevant identifier. A single if-mode can support one or more Application code and one or more Organizational code.

active-if-mode: the active-if-mode is the if-mode an interface is operating. Such active-if-mode identifies an OTSi. the active-if-mode has a reference to one of the supported if-modes and additional parameters that can be varied such as e.g active frequency. if-modes specify interfaces only and do not define interoperability requirements. For interoperability guarantees, Application codes and Organizational codes are referenced.

interop-mode: interop-modes are used in to enable interoperability for path-computation. An interop-mode format may be as simple as a reference to an application code or Organizational code. For cases where no interop-mode exists or applications outside the scope of application-codes cannot be met, the interop-mode can also be encoded in an explicit mode. The explicit mode allows to encode any subset of parameters from the if-mode to enable a controller entity to check for interoperability by means outside of this draft. It shall be noted that using the explicit encoding does not guarantee interoperability between two transceivers even in case of identical parameter definitions. The explicit encoding of an inteerop-mode shall therefore be used with care.

[italobusi]

Few proposed rephrasing based on the text provided by Gert:

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 application code 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.

Interface Mode: An Interface Mode represents an optical interface configuration validated by the system vendors. The if-mode is an identifier for an explicit set of parameters. The if-modes specify the interface configurations only and do not define interoperability requirements. Each interface can support 1 or more if-modes and a single if-mode can support zero, one or more Application Codes and zero, one or more Organizational Modes.

Explicit mode: The explicit mode allows to encode any subset of parameters from the if-mode to enable a controller entity to check for interoperability by means outside of this draft. It shall be noted that using the explicit encoding does not guarantee interoperability between two transceivers even in case of identical parameter definitions. The explicit mode shall therefore be used with care, but it could be useful when no common Application Codes or Organizational Modes exist or the constraints of the common Application Codes or Organizational Modes cannot be met by the line system.

Active-if-mode: The active-if-mode is the if-mode an optical interface is operating. The active-if-mode is a reference to one of the supported if-modes. The optical characteristics of the OTSi generated by the optical interface are defined by the active-if-model and by additional parameters that can be varied such as e.g active frequency.

It looks like the text for the active-if-mode assumes that the mapping between the selected application code or organizational mode is done by the domain controller and not by the transceiver device controller. I am not sure we have all agreed on this so let's further discuss in the call tomorrow.

[italobusi]

2020-07-16 CCAMP call

Need to review the ITU-T G.807 definition for the application identifier and, if applicable to this document, align the terminology usied in the draft with the ITU-T terminology.

[sergiobelotti]

Few proposed rephrasing based on the text provided by Gert:

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. OK, just changed the position of colon

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

application code "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.

@dieterbeller : as underlined in the notes regarding the meeting of July 2, it would be good to have text to explain complete workflow about Organizational mode e.g. how organizational mode takes into account not only transceivers parameters but also optical constraints. This part is implicit in the case of Application code.

Interface Mode: An Interface Mode represents an optical interface configuration validated by the system vendors. The if-mode is an identifier for an explicit set of parameters. The if-modes specify the interface configurations only and do not define interoperability requirements. Each interface can support 1 or more if-modes and a single if-mode can support zero, one or more Application Codes and zero, one or more Organizational Modes. Explicit mode: The explicit mode allows to encode any subset of parameters from the if-mode to enable a controller entity to check for interoperability by means outside of this draft. It shall be noted that using the explicit encoding does not guarantee interoperability between two transceivers even in case of identical parameter definitions. The explicit mode shall therefore be used with care, but it could be useful when no common Application Codes or Organizational Modes exist or the constraints of the common Application Codes or Organizational Modes cannot be met by the line system. Active-if-mode: The active-if-mode is the if-mode an optical interface is operating. The active-if-mode is a reference to one of the supported if-modes. The optical characteristics of the OTSi generated by the optical interface are defined by the active-if-model and by additional parameters that can be varied such as e.g active frequency.

@ggrammel @italobusi : Thanks Gert/Italo for the text . To avoid confusion the only mode alternative to Application and Organizational mode applicable to Topology model is Explicit mode. Interface mode is related to Interface draft only . My feeling is that there is still no agreement or common understanding of the real need of this mode. The important aspect of if-mode is the 1:N relationship with respect supported Application Code or Organizational mode, for which the "explicit set of parameters" characterizing one if-mode can support even more that 1 Application code or Organizational mode. One comment in the proposed definition: how one if-mode that "specify the interface configurations only and do not define interoperability requirements" can support 1 or more Application code or Organizational mode that implies de-facto also interoperability requirements? Active-if-mode is the configured mode in the topology draft so the OTSi configuration.

It looks like the text for the active-if-mode assumes that the mapping between the selected application code or organizational mode is done by the domain controller and not by the transceiver device controller. I am not sure we have all agreed on this so let's further discuss in the call tomorrow. @italobusi : I agree on the comment. When you configure an Organizational mode, is not expecting other from domain controller prospective and the mapping from configured organizational mode /application code and the interface is made by device controller. @dieterbeller : this is probable an aspect we cna clarify in the text above about Organizational mode workflow.

[italobusi]

@sergiobelotti : could you please update the definitions in this file?

https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext/blob/transponder-model-types/modes-definitions.md

This would help tracking the proposed text changes

[italobusi]

Let's use this file for the text proposal in order to track the proposed text changes:

https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext/blob/transponder-model-types/modes-definitions.md

We can keep this open issue for tracking the comments/discussions

FYI:

• This is the original text proposed by Gert: https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext/blob/transponder-model-types/modes-definitions.md
• These are the text changes proposed by me: https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext/commit/9868e3596804e7d8dfb1856a9fd8b4f7f7f76b3b
• These are the text changes agreed during the 2020-07-16 call: https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext/commit/8588647abef431f2a871d1b0c1aa5ddd4cd38d49

The latest changes are just a translation from txt format into md format (no text changes)

[italobusi]

Few proposed rephrasing based on the text provided by Gert:

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. OK, just changed the position of colon

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

application code "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.

@dieterbeller : as underlined in the notes regarding the meeting of July 2, it would be good to have text to explain complete workflow about Organizational mode e.g. how organizational mode takes into account not only transceivers parameters but also optical constraints. This part is implicit in the case of Application code.

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.

Is this assumption correct?

Any text proposal to improve the clarity of this piece of text is very welcome.

Interface Mode: An Interface Mode represents an optical interface configuration validated by the system vendors. The if-mode is an identifier for an explicit set of parameters. The if-modes specify the interface configurations only and do not define interoperability requirements. Each interface can support 1 or more if-modes and a single if-mode can support zero, one or more Application Codes and zero, one or more Organizational Modes. Explicit mode: The explicit mode allows to encode any subset of parameters from the if-mode to enable a controller entity to check for interoperability by means outside of this draft. It shall be noted that using the explicit encoding does not guarantee interoperability between two transceivers even in case of identical parameter definitions. The explicit mode shall therefore be used with care, but it could be useful when no common Application Codes or Organizational Modes exist or the constraints of the common Application Codes or Organizational Modes cannot be met by the line system. Active-if-mode: The active-if-mode is the if-mode an optical interface is operating. The active-if-mode is a reference to one of the supported if-modes. The optical characteristics of the OTSi generated by the optical interface are defined by the active-if-model and by additional parameters that can be varied such as e.g active frequency.

@ggrammel @italobusi : Thanks Gert/Italo for the text . To avoid confusion the only mode alternative to Application and Organizational mode applicable to Topology model is Explicit mode. Interface mode is related to Interface draft only .

Correct. During the 2020-07-16 call we have added a note to clarify this point (sorry for not having added a link to that text earlier)

My feeling is that there is still no agreement or common understanding of the real need of this mode. The important aspect of if-mode is the 1:N relationship with respect supported Application Code or Organizational mode, for which the "explicit set of parameters" characterizing one if-mode can support even more that 1 Application code or Organizational mode. One comment in the proposed definition: how one if-mode that "specify the interface configurations only and do not define interoperability requirements" can support 1 or more Application code or Organizational mode that implies de-facto also interoperability requirements? Active-if-mode is the configured mode in the topology draft so the OTSi configuration.

It looks like the text for the active-if-mode assumes that the mapping between the selected application code or organizational mode is done by the domain controller and not by the transceiver device controller. I am not sure we have all agreed on this so let's further discuss in the call tomorrow. @italobusi : I agree on the comment. When you configure an Organizational mode, is not expecting other from domain controller prospective and the mapping from configured organizational mode /application code and the interface is made by device controller. @dieterbeller : this is probable an aspect we cna clarify in the text above about Organizational mode workflow.

[ggrammel]

2020-07-23Model discussion.pptx

for discussion

[italobusi]

These are the three options we discussed during the 2020-07-23 call:

Option 1

Common structures used by topology and interface models:

+--ro supported-modes* [mode-id]
  +--ro mode-id
  +--ro (mode)?
  |  +--:(G.698.2)
  |  |  +--ro standard-mode?                standard-mode
  |  +--:(organizational-mode)
  |  |  +--ro operational-mode?             operational-mode
  |  |  +--ro organization-identifier?      vendor-identifier
  |  +--:(explicit-mode)
  |     +--ro modulation-types              identityref
  |     ......

Option 2

Common structures used by topology and interface models:

+--ro supported-if-modes* [if-mode-id]
  +--ro if-mode-id
  +--ro modulation-types?             identityref
  ......
  +--ro standard-mode*                standard-mode
  +--ro organizational-mode* [ organization-identifier, operational-mode ]
     +--ro operational-mode           operational-mode
     +--ro organization-identifier    vendor-identifier

Option 3

Adopt option 1 for topology and option 2 for interfaces.

Note - Interface mode = Explicit Mode plus references to supported Application Codes/Organizational Modes. To be added to:

https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext/blob/transponder-model-types/modes-definitions.md

Action for the next call: identify pros&cons of these three options

[sergiobelotti]

[sergiobelotti]

2020-07-23Model discussion.pptx

for discussion

2020-07-23Model-v1.discussion.pptx

new version updated during the meeting

[sergiobelotti]

These are the three options we discussed during the 2020-07-23 call:

Option 1

Common structures used by topology and interface models:

+--ro supported-modes* [mode-id]
  +--ro mode-id
  +--ro (mode)?
  |  +--:(G.698.2)
  |  |  +--ro standard-mode?                standard-mode
  |  +--:(organizational-mode)
  |  |  +--ro operational-mode?             operational-mode
  |  |  +--ro organization-identifier?      vendor-identifier
  |  +--:(explicit-mode)
  |     +--ro modulation-types              identityref
  |     ......

Option 2

Common structures used by topology and interface models:

+--ro supported-if-modes* [if-mode-id]
  +--ro if-mode-id
  +--ro modulation-types?             identityref
  ......
  +--ro standard-mode*                standard-mode
  +--ro organizational-mode* [ organization-identifier, operational-mode ]
     +--ro operational-mode           operational-mode
     +--ro organization-identifier    vendor-identifier

Option 3

Adopt option 1 for topology and option 2 for interfaces.

Note - Interface mode = Explicit Mode plus references to supported Application Codes/Organizational Modes. To be added to:

https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext/blob/transponder-model-types/modes-definitions.md

Action for the next call: identify pros&cons of these three options

@italobusi : Thanks to summarize perfectly the different options. I started to leave my comment. Option 1 I'm in favour of Option 1: advantage:

• it is perfectly aligned to the agreement reached in the f2f off-line meeting during IETF in Singapore , to leave choice regarding the mode to operate transponder (triple choice), it is aligned to the agreed intention to use common structure between topology and interface model, that is a very good approach increasing the attraction of these models that appear very close one to the other.

• Avoid any possible needs for mapping between if-mode as defined in https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext/blob/transponder-model-types/modes-definitions.md and Application code/Organizational mode since the mapping is implicit in the code e.g. if you use explicit modes the set of attributes characterizing a specific if-mode is explicit in both Topology model and Interface model.

disadvantage:

• Interface model should update the YANG to align with the proposal

Option 2

I do not see any advantage on this option: it compels both Topology and Interface model to be updated. It is needed also to add what Application code/organizational mode is really chosen using a specific if-mode +--rw current-opt-if-och-mode-params +--rw mode-id? string +--ro min-osnr-margin?
............ +--rw standard-mode string +--rw organizational-mode +-- rw operational-mode operational-mode +-- rw organization-identifier vendor-identifier ...................................

Option 3

advantage:

• It permits substantially to maintain the same structure on Topology model .

disadvantage:

• Interface model has to provide the reference to application code/organizational mode .

• no alignment in the structure on the two models .

• explicit mapping is needed and provided by Interface model

[ggrammel]

The challenge is that Application Codes (AC) describe a network performance that needs to be met. An AC includes interface capabilities that need to be fulfilled to match the network conditions defined as Black Link. G698.2 (2018) Table 5-1 summarizes the mapping of application codes to single channel interfaces. For the 5 interfaces of the Table, 51 Application codes are defined. If we focus on the concrete example of OTL4.4, Table 8-7 – shows one Interface for 6 Application Codes covering 50GHz and 100GHz spacing as well as 3 different fiber types (G.652, G.653, G.655). Like G.698.2 where one interface characterization is mapped to a set of application codes, the Interface model should configure the interface characteristic and list the applications supported.

[sergiobelotti]

YANG proposal agreed on August 20 ,2020, slide 5, Option 1B if-mode-clarification_options-200820-github.pptx

[sergiobelotti]

A first proposal to add text in the draft , describing the "transponder" part of the model is uploaded. The text is considering only the "capability" part, not the configuration part, following the actual YANG definiton. Transponder-text-section-2.5.docx