search

ietf-ccamp-wg / ietf-ccamp-layer0-types-ext-RFC9093-bis

CCAMP WG repository for ietf-layer0-types-ext
3 stars 3 forks source link

Multiple line codings for the same ITU-T application code #62

Closed italobusi closed 1 year ago

italobusi commented 1 year ago

Looking at ITU-T G.698.2 there are cases in which at one application code corresponds 2 line-coding. This would be a problem for IW e.g. in case operational mode is used for transponder (same application code but possible different line coding, no interworking). Different opinion to solve the problem: a) leave ITU-T to deal with that and put some text raising the point. b) use different operational modes c) define an attribute , specifically a list representing an application code with related line-coding as entries. With this option we should define new identities in YANG to represent the different line-coding applicable to the same application code

Weekly call on June 21st: About the point 3 the preferred solution is a) , so we need to add some text explaining the issue. AP @dieterbeller to modify the draft adding the text.

See: https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext/issues/51#issuecomment-1169783573

sergiobelotti commented 1 year ago

weekly call: We need to send a mail to ITU-T , asking how to clarify the situation of this ambiguity.

AP @sergiobelotti @italobusi @ggrammel : to provide a draft of the text for the e-mail

ggrammel commented 1 year ago

Proposed text:

Dear …

We would ask for a clarification related to Rec. ITU-T G.698.2 (11/2018) application codes. Applications are defined using optical interface parameters at the single-channel connection points between optical transmitters and the optical multiplexer, as well as between optical receivers and the optical demultiplexer in the DWDM system. Table 8-7 defines Bit rate/line coding of optical tributary signals for DP-DQPSK 100G, narrow spectral excursion applications and specifies “OTL4.4-SC or FOIC1.4-SC”.

We observed that OTL4.4-SC and FOIC1.4-SC are incompatible to each other but share the same application codes. This ambiguity could lead to incompatibility of optical interface specifications towards the realization of transversely compatible dense wavelength division multiplexing (DWDM) systems. We appreciate your support to interpret Table 8-7 to avoid incompatibility issues when using Application Codes.

From: sergio belotti @.> Date: Tuesday, 25. October 2022 at 15:00 To: ietf-ccamp-wg/ietf-ccamp-layer0-types-ext @.> Cc: Gert Grammel @.>, Mention @.> Subject: Re: [ietf-ccamp-wg/ietf-ccamp-layer0-types-ext] Multiple line codings for the same ITU-T application code (Issue #62) [External Email. Be cautious of content]

weekly call: We need to send a mail to ITU-T , asking how to clarify the situation of this ambiguity.

AP @sergiobelottihttps://urldefense.com/v3/__https:/github.com/sergiobelotti__;!!NEt6yMaO-gk!FaFTRp_dm9af8WEs9olDDYOvHacJMPYqXH813T_WE05eQrrIaf13D4A4BoyIS8VmQovMRtALI6kJssgIhbT0ARKkpQ$ @italobusihttps://urldefense.com/v3/__https:/github.com/italobusi__;!!NEt6yMaO-gk!FaFTRp_dm9af8WEs9olDDYOvHacJMPYqXH813T_WE05eQrrIaf13D4A4BoyIS8VmQovMRtALI6kJssgIhbTAXhzL_Q$ @ggrammelhttps://urldefense.com/v3/__https:/github.com/ggrammel__;!!NEt6yMaO-gk!FaFTRp_dm9af8WEs9olDDYOvHacJMPYqXH813T_WE05eQrrIaf13D4A4BoyIS8VmQovMRtALI6kJssgIhbSYjIgIdA$ : to provide a draft of the text for the e-mail

— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext/issues/62*issuecomment-1290516094__;Iw!!NEt6yMaO-gk!FaFTRp_dm9af8WEs9olDDYOvHacJMPYqXH813T_WE05eQrrIaf13D4A4BoyIS8VmQovMRtALI6kJssgIhbTt9JjISA$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/ADTQOVBAVDDMOD7ENAXXDTLWE7KXZANCNFSM6AAAAAARKEDSLE__;!!NEt6yMaO-gk!FaFTRp_dm9af8WEs9olDDYOvHacJMPYqXH813T_WE05eQrrIaf13D4A4BoyIS8VmQovMRtALI6kJssgIhbRZWWKwug$. You are receiving this because you were mentioned.Message ID: @.***>

Juniper Business Use Only

sergiobelotti commented 1 year ago

@ggrammel : thanks Gert ! The text seems to me fine to be sent to ITU-T. There is not other to ask, and the question for clarification is very clear. @italobusi : I'm a bit far from ITU-T discussion for some time , is the text ready for ITU-T ?

italobusi commented 1 year ago

@ggrammel : thanks Gert ! The text seems to me fine to be sent to ITU-T. There is not other to ask, and the question for clarification is very clear. @italobusi : I'm a bit far from ITU-T discussion for some time , is the text ready for ITU-T ?

It's a very good starting point. I would propose to shorten it a bit to go straight to the point:

We would ask for a clarification related to Rec. ITU-T G.698.2 (11/2018) application codes. Table 8-7 defines Bit rate/line coding of optical tributary signals for DP-DQPSK 100G applications and specifies it as “OTL4.4-SC or FOIC1.4-SC”.

We observed that OTL4.4-SC and FOIC1.4-SC are incompatible to each other but share the same application codes. We appreciate your support to interpret Table 8-7 to avoid incompatibility issues when the two ends are configured with the application code, but one using OTL4.4-SC and the other using FOIC1.4-SC.

italobusi commented 1 year ago

Thinking further after our call yesterday, I am wondering whether the ambiguity can be resolved by the L1 configuration (and capability reporting) of the transponder. If the OTSiG carries an OTU4 then the line coding should be OTL4.4 while if the OTSiG carries FlexO then the line coding should be FOIC1.4-SC.

sergiobelotti commented 1 year ago

We got feedback from an internal Q6 expert about this issue.

He said that: "we need to distinguish between the optical interface spec and a spec for the bit rate / line coding. The application codes in G.698.2 provide the OPTICAL specs for a CLASS of optical tributary signals. This CLASS can contain optical tributary signals with different bit rates and line coding that all share the same OPTICAL specs. This means the user ( operator) can use signals with this different line coding/ bit rate on the same optical link with this common optical specification. Of course, the operator/ user needs to make sure that conditions as defined in G.709.2 and G.709.3 documents need to be fulfilled. This means if these Recommendations do not cover interworking then the user has to make sure that the same bit rate/ line coding is used at both ends of the link. See also definition of optical tributary signal class DP-QPSK-100G in Clause 3.2.1, in particular with the last sentence: "Optical tributary signal class DP-DQPSK 100G includes a signal with FOIC1.4-SC bit rate according to [ITU-T G.709.3] and OTL4.4-SC bit rate according to [ITU-T G.709.2]." "

dieterbeller commented 1 year ago

So, for describing the transceiver capabilities unambiguously, a new optional line-coding attribute is needed in addition to the standard-mode leaf defined for the ITU-T application codes as defined in ITU-T Recommendation G.698.2. This should solve the issue.

sergiobelotti commented 1 year ago

Please see the proposed reply from ITU-T Q6 to our Liaison: From: t22sg15q6-request@lists.itu.int [t22sg15q6-request@lists.itu.int](mailto:t22sg15q6-request@lists.itu.int) On Behalf Of Fabio Cavaliere Sent: 18 April 2023 21:41 To: t22sg15q6@lists.itu.int Subject: [T15Q6] Reply to IETF L/S in TD40 WP2

Dear Q6 colleagues,

Please find below the text I would propose to reply to the iETF L7S:

“As regards your request for clarification about DP-DQPSK 100G application codes Rec. ITU-T G.698.2 (11/2018), we confirm that: • OTL4.4-SC or FOIC1.4-SC share the same application code, as specified in the Bit rate/line coding field of Table 8-7. • That your understanding that OTL4.4-SC and FOIC1.4-SC are incompatible with each other is correct and the same type of tributary signal must be present ay both ends of the link.

Moreover, we concluded that generating different application codes having the same set of optical parameters could be misleading so we don’t support this solution”

Best Regards Fabio

Fabio Cavaliere Expert in Photonic System and Technologies Via Moruzzi 1 c/o CNR, Ericsson 56124 Pisa (Italy) Tel. +39 050 5492381 Cell. +39 3336324797 Email: fabio.cavaliere@ericsson.com

sergiobelotti commented 1 year ago

Here the official ITU-T reply to our liaison https://mailarchive.ietf.org/arch/browse/ccamp/ Based on this answer the proposal to add a new optional line-coding attribute in addition to the standard-mode leaf seems the only possibility to disambiguate different line coding with the same application code.

As stated during weekly call on 02-05-23 we need to decide if to adopt the same solution proposed for ITU-T standard application code also for the other two "mode" for transponder capability description i.e. organizational mode and explicit mode.

sergiobelotti commented 1 year ago

Related to "As stated during weekly call on 02-05-23 we need to decide if to adopt the same solution proposed for ITU-T standard application code also for the other two "mode" for transponder capability description i.e. organizational mode and explicit mode."

the grouping common-explicit-mode already have line-coding attribute see

grouping common-explicit-mode { description "Attributes capabilities related to explicit mode of an optical transceiver"; leaf line-coding-bitrate { type identityref { base line-coding; } config false; description "Bit rate/line coding of the optical tributary signal."; reference "ITU-T G.698.2 section 7.1.2"; } ...................................... ..................................

sergiobelotti commented 1 year ago

weekly call 2023-06-23

About the pending question , the decision is to take things as they are, no line -coding attribute to be added to organizational-mode grouping.

italobusi commented 1 year ago

IMHO, the line-coding attributes are required only when the application code supports more than one line-coding and they could be defined as optional attributes when the application codes supports only one line-coding

Following the same approach for organizational mode, would give organizations freedom to either define different organizational modes for different line-coding or a single organization mode with multiple line-codings

Another doubt: have we checked which approach is followed for ZR and ZR+ (including the on-going work in OIF)?

sergiobelotti commented 1 year ago

IMHO, the line-coding attributes are required only when the application code supports more than one line-coding and they could be defined as optional attributes when the application codes supports only one line-coding

Following the same approach for organizational mode, would give organizations freedom to either define different organizational modes for different line-coding or a single organization mode with multiple line-codings

Another doubt: have we checked which approach is followed for ZR and ZR+ (including the on-going work in OIF)?

@italobusi could you kindly add your comments at the minute? This is the link https://demo.hedgedoc.org/O3vr1ynNR3Kg-Xj4KWemYw

Not clear for me why to make explicit line-coding when the organizational mode itself permits full flexibility of the "hidden" parameters that can distinguish one organizational mode to another, e.g. exactly the line-coding.

italobusi commented 1 year ago

@italobusi could you kindly add your comments at the minute? This is the link https://demo.hedgedoc.org/O3vr1ynNR3Kg-Xj4KWemYw

Done

Not clear for me why to make explicit line-coding when the organizational mode itself permits full flexibility of the "hidden" parameters that can distinguish one organizational mode to another, e.g. exactly the line-coding.

The current model works well if the organization defines organizational modes which support only one line-coding

The current model works well if the organization defines organizational modes which support only one line-coding

The proposal is: 1) to add these additional attributes to make the model more flexible to give organizations the freedom to follow the same approach as ITU-T (i.e., defining organizational modes which support multiple line codings) if the wish 2) to make these attributes optional not to impact the organizations which defines organizational modes which support only one line-coding but just give more freedom

sergiobelotti commented 1 year ago

@italobusi could you kindly add your comments at the minute? This is the link https://demo.hedgedoc.org/O3vr1ynNR3Kg-Xj4KWemYw

Done

Not clear for me why to make explicit line-coding when the organizational mode itself permits full flexibility of the "hidden" parameters that can distinguish one organizational mode to another, e.g. exactly the line-coding.

The current model works well if the organization defines organizational modes which support only one line-coding

The current model works well if the organization defines organizational modes which support only one line-coding

The proposal is:

  1. to add these additional attributes to make the model more flexible to give organizations the freedom to follow the same approach as ITU-T (i.e., defining organizational modes which support multiple line codings) if the wish
  2. to make these attributes optional not to impact the organizations which defines organizational modes which support only one line-coding but just give more freedom

@italobusi : thanks Italo your further explanation is clear. It could make sense to have an alignment in the behaviour between standard-mode and organizational-mode. The optional attribute should be a list I guess not a single leaf , to define an organizational mode supporting more that one line-coding.