Subject: Re: [CCAMP] 答复: Webex meeting changed: Optical impairments draft

From: Gert Grammel <[email-masked]>
Date: Tue, 10 Nov 2020 10:09:04 +0000

Hi Fatai,

The group managed to find agreement on the Application code and the explicit mode whereas Organizational codes are under discussion. In essence, the question is whether non-standard organizations can define their own codes along the same lines as ITU-T did (case-A) or if additional parameters need to be made explicit (case-B).

Regards

Gert

From: Fatai Zhang <[email-masked]>
Date: Friday, November 6, 2020 at 08:01
To: Daniele Ceccarelli <[email-masked]>, Italo Busi <[email-masked]>, Gert Grammel <[email-masked]>, "[email-masked]" <[email-masked]>, CCAMP <[email-masked]>
Cc: Dieter Beller <[email-masked]>
Subject: 答复: [CCAMP] Webex meeting changed: Optical impairments draft

[External Email. Be cautious of content]

Hi all,

I think there are too many options (three!) , which introduces too much flexibility and complexity to this document and the real world.

If “only application codes” can work, why the others are necessary?

I think we can try if we could keep only one option and remove the other options to keep it simple , because we could treat e.g., “organization mode” as proprietary implementation since it is really proprietary  among some organization.

Thanks
Fatai

发件人: Daniele Ceccarelli [mailto:[email-masked]]
发送时间: 2020年11月2日 23:51
收件人: Italo Busi <[email-masked]>; 'Gert Grammel' <[email-masked]>; [email-masked]; [email-masked]
抄送: Dieter Beller <[email-masked]>
主题: RE: [CCAMP] Webex meeting changed: Optical impairments draft

Hi,

Sorry to jump in but I’m having hard times to understand what the issue is. What is wrong with the actual modes? I asked if it was possible to merge 2 of them and go down to 2 but it was proven not possible.

Moreover this is no longer just author’s agreement since the draft is a WG document.
What italo says below is correct. We decided that all the modes are optional, hence the model needs to be self-consistent and all permutations should be allowed.

But once again, it’s not clear to me what the issue is, could you please elaborate it a bit?

Cheers,
Daniele

From: Italo Busi <[email-masked]<mailto:[email-masked]>>
Sent: den 2 november 2020 12:42
To: 'Gert Grammel' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Dieter Beller <[email-masked]<mailto:[email-masked]>>
Subject: RE: [CCAMP] Webex meeting changed: Optical impairments draft

Hi Gert,

Just an high level comment: the initial agreement between the co-authors was that to define three modes (application code, organization mode and explicit mode) all as being optional.

Therefore, IMHO, the YANG model for each mode should be self-consistent to give implementers the freedom to implement either:

  *   Only application codes
  *   Only organization modes
  *   Only explicit modes
  *   Both application codes and organization modes
  *   Both application codes and explicit modes
  *   Both organizational modes and explicit modes
  *   All options (application code, organizational mode and explicit mode)

Please find some detailed comments of mine in line below.

My 2 cents

Italo

From: Gert Grammel [mailto:[email-masked]]
Sent: domenica 1 novembre 2020 12:02
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Dieter Beller <[email-masked]<mailto:[email-masked]>>; Italo Busi <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] Webex meeting changed: Optical impairments draft

It would be good to tune the heat of the down by a few centigrade. Why spending time writing definitions, getting agreement  and rewriting again in less than 24h?  The core of the discussion is where to hang parameters in a YANG-tree in a consistent manner. How exciting is this?

The minimum we should strive for in IETF is to come up with a consistent model. To do so, it is good engineering practice to first agree on the problem. That said, I am happy that apparently the Case-A and Case-B description laid out in my previous mail turned out not to be contentious.

About the issue of “organizational mode”:

  1.  Case-A: AFAIK the most common and Transponder Model today is OpenConfig, which uses a single identifier for the operational-mode. The use is simple because it can be used as a matching criteria to make sure the two transponders at each end interoperate (given the OLS is within spec).
  2.  Case-B: proposes a series of additional criteria that must be met by adding explicit parameters such as frequency range, power-range etc. So the simple matching rule is no more sufficient and additional parameters must be checked to assess compatibility.
I think it is a fair ask to hear from the CCAMP-WG if we are happy to ditch the OpenConfig way and  implement Case-B.

[[Italo Busi] ] I am not an expert of OpenConfig but Dieter has already confirmed that the latest definition in github (https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=44077b9a-1b9c42d9-44073b01-861fcb972bfc-e503d80e6efd81dd&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fissues*2F29*23issuecomment-719503150__;JSUlJSUlJSU!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1dV-vxg_$>) is aligned with existing implementations (I assume, based on his working experience, he was also considering OpenConfig implementations).

Anyhow, OpenConfig experts can provide their comments on this definition, if they think it is not correct.

About the issue of “where to put the explicit parameters”:

  1.  Case-A: puts all explicit parameters in the explicit mode and provides a leafref to Organizational modes. Explicit min/max parameters can be liked to an Organizational mode by referencing the organizational mode from the explicit mode. Organizational modes continue to be used just like Application codes as a matching condition.

[[Italo Busi] ] The references between the explicit mode and the application code/organization modes have been added as informative to represent the fact that an explicit mode can support zero, one or more application codes and/or zero, one or more organization modes. It was not intended to provide additional information wrt the application code or organization mode definitions and I think it should not be used in that way to avoid creating inconsistencies (see comment below).

  1.  Case-B: puts a subset of the parameters also defined in the explicit mode into the Organizational mode. By doing so we now have duplicated parameters in operational and explicit mode.
Structurally this creates a conflict, because it is not clear which definition takes precedence in a matching condition. It is this structural issue we need to address to move forward.

[[Italo Busi] ] I think you have spotted a potential technical issue with the current definition of the leafref between an explicit mode and an application code or organization mode but this is independent from the fact that explitic parameters are defined or not for the application mode.
This inconsistency could apply also to parameters that are implicitly defined by the organization mode (or even by an application code). For example, the YANG model allows an explicit mode which supports one type of FEC to claim support of an application code or of an organization model which (implicitly) requires a different type of FEC.
If the client requests the interface to operate according to a given application code or organization mode, I think that the expectation is that the FEC defined for that application code or organization mode is being used.

I think to resolve this issue we should either clarify the rules an implementation MUST follow to avoid reporting inconsistent information or some precedence rules (considering both implicit and explicit parameters) or remove the leafref.

About the parameter set of the “Organizational mode”:

  1.  Case-A: allows to use any set of explicit parameters to add more information to organizational modes as a reference

[[Italo Busi] ] The YANG model for application codes and organization modes should be self-consistent to supports implementations that do not implement the explicit-mode. Moreover, using the leafref to provide more information would be a potential source of inconsistency (see comment above)

  1.  Base-B: allows a small subset of parameters to be used to further define the organizational mode. This set is fixed as described in case-B.
As the selection criteria for the set of parameters has not been disclosed, it is difficult to understand whether the list remains such short or is growing much longer over time. It would be good to get the sense of the WG on that aspect too.

[[Italo Busi] ] According to the latest definition in github (https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=c4b9f9f1-9b22c0b2-c4b9b96a-861fcb972bfc-7ad4277e89b62b88&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fissues*2F29*23issuecomment-719503150__;JSUlJSUlJSU!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1TYJhR0h$>) the current list is complete.

Those who have implemented organization modes (including OpenConfig experts) can provide their comment if they think this list is not complete.

Cheers

Gert

From: CCAMP <[email-masked]<mailto:[email-masked]>> on behalf of Dieter Beller <[email-masked]<mailto:[email-masked]>>
Organization: Nokia
Date: Saturday, October 31, 2020 at 10:28
To: Italo Busi <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, CCAMP <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] Webex meeting changed: Optical impairments draft

[External Email. Be cautious of content]

Thanks, Italo, for your contribution to the technical discussion!

I would like to emphasize that the text on GitHub ( see https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=2c758499-73eebdda-2c75c402-861fcb972bfc-3975d7433728ea76&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fissues*2F29*23issuecomment-719503150__;JSUlJSUlJSU!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1W1fns7e$>) tries
to provide the technical justification for the modeling approach taken for the organizational mode option - here is the text, which was referenced in Italo's mail:

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.

Moreover, implementations exist that are based on the same modeling approach and hence it is already field proven!

Thanks,
Dieter
On 30.10.2020 17:14, Italo Busi wrote:

Hi Gert,

Let me try to look at this issue from a different perspective.

I think the objective of our work is to define a YANG model for the optical specification methodologies which are used in the field to represent the capabilities of the transponders.

I do not think that it is in the scope of our work to discuss the optical specification methodologies other than understanding how they could be used for path computation (ensuring interoperability between the sender and receiver) and modelled using YANG.

As far as I have understood from past discussion, we have agreed to support three optical specification methodologies which are used by existing optical interfaces implementations and we have named them as application code (ITU-T G.698.2), organizational mode and explicit mode.

After some rounds of discussions and questions for clarification, the latest proposed text to describe the behavior of the organization mode has been prepared on github:

https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=fe2bb22f-a1b08b6c-fe2bf2b4-861fcb972bfc-7c29789e806b744e&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fissues*2F29*23issuecomment-719503150__;JSUlJSUlJSU!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1RUYzMO4$>

I think this updated description has improved the clarity of how the operational mode are implemented and, in particular that:

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

As a consequence, I think that the YANG model defined in "Case A" below does not work (since it does not provide enough information to check that " the supported carrier frequency and power attributes have a matching range ") while the one defined in "Case B" works properly.

This text describing the operational mode behavior has been provided by people who have implemented it.

Therefore, I think we can update the draft with the changes discussed in the last few weeks incorporating the definitions capturing our current understanding of how these optical specification methodologies (application code, organizational mode and explicit mode) behave and the YANG model aligned with our current understanding (i.e., based on "Case B" below).

Since we are not yet in WG LC stage, we still have plenty of time to update both the description and the YANG model based on the feedbacks we receive from data plane experts.

My 2 cents

Italo (as co-author of the draft)

-----Original Message-----

From: Gert Grammel [mailto:[email-masked]]

Sent: giovedì 29 ottobre 2020 17:34

To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Subject: Re: [CCAMP] Webex meeting changed: Optical impairments draft

We discussed today a difference in the interpretation of the model related to https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=30d0fc94-6f4bc5d7-30d0bc0f-861fcb972bfc-5d5353826774237a&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fissues*2F29__;JSUlJSUlJQ!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1eeOzXrI$> and its interpretation. The different interpretation lead to different computation requirements.

The design team appreciates feedback which of both Cases is preferred and what consideration led to the preference

Case A:

======

https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues#issuecomment-677768528<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=af80a102-f01b9841-af80e199-861fcb972bfc-509d8509e721d1cb&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fissues*23issuecomment-677768528__;JSUlJSUlJQ!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1fp5UCUX$> from August 20 documented the structure of the model:

+--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 supported-standard-mode*? leafref

  |     +--ro modulation-types                   identityref

  |     ......

This snippet would allow to use standard mode or operational mode as a simple matching criteria for compatibility i.e. two transponders with Operational-mode=X and suitable line parameters would interoperate.

In case of “explicit” mode, the set of parameters provided, can support one or more application code/organizational mode, that means this set of parameters if applied to configure the transceiver, is aligned with one or more application code/organizational mode.

(Note that there are no additional parameters associated to the organizational mode in this case)

Case B:

======

https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/blob/master/ietf-optical-impairment-topology.tree<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=dacf1e95-855427d6-dacf5e0e-861fcb972bfc-13a67d7f67153c4a&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fblob*2Fmaster*2Fietf-optical-impairment-topology.tree__;JSUlJSUlJSU!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1ToD0jv4$> contains additional parameters to the Operational Mode that are also replicated in the explicit mode. Those parameters are related to the min/max ranges which are allowed.

  +--ro supported-mode* [mode-id]

                +--ro mode-id                      string

                +--ro (mode)

                   +--:(G.698.2)

                   |  +--ro standard-mode?         standard-mode

                   +--:(organizational-mode)

                   |  +--ro organizational-mode

                   |     +--ro operational-mode?

                   |     |       operational-mode

                   |     +--ro organization-identifier?

                   |     |       organization-identifier

                   |     +--ro min-central-frequency?

                   |     |       frequency-thz

                   |     +--ro max-central-frequency?

                   |     |       frequency-thz

                   |     +--ro minimum-channel-spacing?

                   |     |       frequency-ghz

                   |     +--ro tx-channel-power-min?      dbm-t

                   |     +--ro tx-channel-power-max?      dbm-t

                   |     +--ro rx-channel-power-min?      dbm-t

                   |     +--ro rx-channel-power-max?      dbm-t

                   |     +--ro rx-total-power-max?        dbm-t

                   +--:(explicit-mode)

                      +--ro explicit-mode

                         +--ro supported-modes

                         |  +--ro supported-application-codes*

                         |  |       -> ../../mode-id

                         |  +--ro supported-organizational-modes*

                         |          -> ../../mode-id

                         +--ro line-coding-bitrate?

                         |       identityref

                     <snip>

                         +--ro min-central-frequency?

                         |       frequency-thz

                         +--ro max-central-frequency?

                         |       frequency-thz

                         +--ro minimum-channel-spacing?

                         |       frequency-ghz

                         +--ro tx-channel-power-min?

                         |       dbm-t

                         +--ro tx-channel-power-max?

                         |       dbm-t

                         +--ro rx-channel-power-min?

                         |       dbm-t

                         +--ro rx-channel-power-max?

                         |       dbm-t

                         +--ro rx-total-power-max?

                                 dbm-t

In this case, interoperability can only be provided if the organizational code on each side match AND all other explicit parameters defined in the organizational-code have a matching range.

(Note that min/max parameters are associated to the organizational mode AND to the explicit mode in this case)

Juniper Business Use Only

_______________________________________________

CCAMP mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/ccamp<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=e2f70c1c-bd6c355f-e2f74c87-861fcb972bfc-c52544a2ca4d215d&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fccamp__*3B*21*21NEt6yMaO-gk*21Qf7o1-a2YfLkPqzntQzH4eVYGLpUDj-1ysELXfiLRhkWu-G-RrJBibxJipiVa6Bx*24__;JSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1bI5nQgy$>

Juniper Business Use Only

Juniper Business Use Only

---

From: Dieter Beller <[email-masked]>
Date: Tue, 10 Nov 2020 12:34:12 +0100

Hi Gert, all,

there has been consensus to support the 3 options as currently defined 
in the YANG model (see 
https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang).

Stating that the organizational-mode option is under discussion is 
passing a wrong message to the CCAMP WG!

The situation is the following: there is rough consensus that the 
organizational-mode option is valuable and there is only one single 
person continuously disagreeing because of another
preference.

Thanks,
Sergio and Dieter

On 10.11.2020 11:09, Gert Grammel wrote:
>
> Hi Fatai,
>
> The group managed to find agreement on the Application code and the 
> explicit mode whereas Organizational codes are under discussion. In 
> essence, the question is whether non-standard organizations can define 
> their own codes along the same lines as ITU-T did (case-A) or if 
> additional parameters need to be made explicit (case-B).
>
> Regards
>
> Gert
>
> *From: *Fatai Zhang <[email-masked]>
> *Date: *Friday, November 6, 2020 at 08:01
> *To: *Daniele Ceccarelli <[email-masked]>, Italo Busi 
> <[email-masked]>, Gert Grammel <[email-masked]>, 
> "[email-masked]" <[email-masked]>, CCAMP <[email-masked]>
> *Cc: *Dieter Beller <[email-masked]>
> *Subject: *答复: [CCAMP] Webex meeting changed: Optical impairments draft
>
> *[External Email. Be cautious of content]*
>
> Hi all,
>
> I think there are too many options (three!) , which introduces too 
> much flexibility and complexity to this document and the real world.
>
> I think we can try if we could keep only one option and remove the 
> other options to keep it simple , because we could treat e.g., 
> “organization mode” as proprietary implementation since it is really 
> proprietary  among some organization.
>
> Thanks
>
> Fatai
>
> *发件人:*Daniele Ceccarelli [mailto:[email-masked]]
> *发送时间:* 2020年11月2日 23:51
> *收件人:* Italo Busi <[email-masked]>; 'Gert Grammel' 
> <[email-masked]>; [email-masked]; [email-masked]
> *抄送:* Dieter Beller <[email-masked]>
> *主题:* RE: [CCAMP] Webex meeting changed: Optical impairments draft
>
> Hi,
>
> Sorry to jump in but I’m having hard times to understand what the 
> issue is. What is wrong with the actual modes? I asked if it was 
> possible to merge 2 of them and go down to 2 but it was proven not 
> possible.
>
> What italo says below is correct. We decided that all the modes are 
> optional, hence the model needs to be self-consistent and all 
> permutations should be allowed.
>
>
> *From:* Italo Busi <[email-masked] <mailto:[email-masked]>>
> *Sent:* den 2 november 2020 12:42
> *To:* 'Gert Grammel' <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> *Cc:* Dieter Beller <[email-masked] 
> <mailto:[email-masked]>>
> *Subject:* RE: [CCAMP] Webex meeting changed: Optical impairments draft
>
> Hi Gert,
>
> Just an high level comment: the initial agreement between the 
> co-authors was that to define three modes (application code, 
> organization mode and explicit mode) all as being optional.
>
> Therefore, IMHO, the YANG model for each mode should be 
> self-consistent to give implementers the freedom to implement either:
>
>   * Only application codes
> *From:* Gert Grammel [mailto:[email-masked] 
> <mailto:[email-masked]>]
> *Sent:* domenica 1 novembre 2020 12:02
> *To:* [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>
> *Cc:* Dieter Beller <[email-masked] 
> <mailto:[email-masked]>>; Italo Busi <[email-masked] 
> <mailto:[email-masked]>>
> *Subject:* Re: [CCAMP] Webex meeting changed: Optical impairments draft
>
> It would be good to tune the heat of the down by a few centigrade. Why 
> spending time writing definitions, getting agreement  and rewriting 
> again in less than 24h?  The core of the discussion is where to hang 
> parameters in a YANG-tree in a consistent manner. How exciting is this?
>
> The minimum we should strive for in IETF is to come up with a 
> consistent model. To do so, it is good engineering practice to first 
> agree on the problem. That said, I am happy that apparently the Case-A 
> and Case-B description laid out in my previous mail turned out not to 
> be contentious.
>
>  1. Case-A: AFAIK the most common and Transponder Model today is
>     OpenConfig, which uses a single identifier for the
>     operational-mode. The use is simple because it can be used as a
>     matching criteria to make sure the two transponders at each end
>     interoperate (given the OLS is within spec).
>  2. Case-B: proposes a series of additional criteria that must be met
>     by adding explicit parameters such as frequency range, power-range
>     etc. So the simple matching rule is no more sufficient and
>     additional parameters must be checked to assess compatibility.
>
> I think it is a fair ask to hear from the CCAMP-WG if we are happy to 
> ditch the OpenConfig way and  implement Case-B.
>
> //
>
> /[[Italo Busi] ] I am not an expert of OpenConfig but Dieter has 
> already confirmed that the latest definition in github 
> (https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150 
> <https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=44077b9a-1b9c42d9-44073b01-861fcb972bfc-e503d80e6efd81dd&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fissues*2F29*23issuecomment-719503150__;JSUlJSUlJSU!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1dV-vxg_$>) 
> is aligned with existing implementations (I assume, based on his 
> working experience, he was also considering OpenConfig implementations)./
>
> //
>
> /Anyhow, OpenConfig experts can provide their comments on this 
> definition, if they think it is not correct./
>
>  1. Case-A: puts all explicit parameters in the explicit mode and
>     provides a leafref to Organizational modes. Explicit min/max
>     parameters can be liked to an Organizational mode by referencing
>     the organizational mode from the explicit mode. Organizational
>     modes continue to be used just like Application codes as a
>     matching condition.
>
> *//*
>
> /[[Italo Busi] ] The references between the explicit mode and the 
> application code/organization modes have been added as informative to 
> represent the fact that an explicit mode can support zero, one or more 
> application codes and/or zero, one or more organization modes. It was 
> not intended to provide additional information wrt the application 
> code or organization mode definitions and I think it should not be 
> used in that way to avoid creating inconsistencies (see comment below)./
>
>  2. Case-B: puts a subset of the parameters also defined in the
>     explicit mode into the Organizational mode. By doing so we now
>     have duplicated parameters in operational and explicit mode.
>
> Structurally this creates a conflict, because it is not clear which 
> definition takes precedence in a matching condition. It is this 
> structural issue we need to address to move forward.
>
> /[[Italo Busi] ] I think you have spotted a potential technical issue 
> with the current definition of the leafref between an explicit mode 
> and an application code or organization mode but this is independent 
> from the fact that explitic parameters are defined or not for the 
> application mode./
>
> /This inconsistency could apply also to parameters that are implicitly 
> defined by the organization mode (or even by an application code). For 
> example, the YANG model allows an explicit mode which supports one 
> type of FEC to claim support of an application code or of an 
> organization model which (implicitly) requires a different type of FEC./
>
> /If the client requests the interface to operate according to a given 
> application code or organization mode, I think that the expectation is 
> that the FEC defined for that application code or organization mode is 
> being used./
>
> //
>
> /I think to resolve this issue we should either clarify the rules an 
> implementation MUST follow to avoid reporting inconsistent information 
> or some precedence rules (considering both implicit and explicit 
> parameters) or remove the leafref./
>
>  1. Case-A: allows to use any set of explicit parameters to add more
>     information to organizational modes as a reference
>
> //
>
> /[[Italo Busi] ] The YANG model for application codes and organization 
> modes should be self-consistent to supports implementations that do 
> not implement the explicit-mode. Moreover, using the leafref to 
> provide more information would be a potential source of inconsistency 
> (see comment above)/
>
>  2. Base-B: allows a small subset of parameters to be used to further
>     define the organizational mode. This set is fixed as described in
>     case-B.
>
> As the selection criteria for the set of parameters has not been 
> disclosed, it is difficult to understand whether the list remains such 
> short or is growing much longer over time. It would be good to get the 
> sense of the WG on that aspect too.
>
> /[[Italo Busi] ] According to the latest definition in github 
> (https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150 
> <https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=c4b9f9f1-9b22c0b2-c4b9b96a-861fcb972bfc-7ad4277e89b62b88&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fissues*2F29*23issuecomment-719503150__;JSUlJSUlJSU!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1TYJhR0h$>) 
> the current list is complete./
>
> //
>
> /Those who have implemented organization modes (including OpenConfig 
> experts) can provide their comment if they think this list is not 
> complete./
>
> //
>
> Cheers
>
> Gert
>
> *From: *CCAMP <[email-masked] <mailto:[email-masked]>> 
> on behalf of Dieter Beller <[email-masked] 
> <mailto:[email-masked]>>
> *Organization: *Nokia
> *Date: *Saturday, October 31, 2020 at 10:28
> *To: *Italo Busi <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>, CCAMP <[email-masked] 
> <mailto:[email-masked]>>
> *Subject: *Re: [CCAMP] Webex meeting changed: Optical impairments draft
>
> *[External Email. Be cautious of content]*
>
> I would like to emphasize that the text on GitHub ( see 
> https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150 
> <https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=2c758499-73eebdda-2c75c402-861fcb972bfc-3975d7433728ea76&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fissues*2F29*23issuecomment-719503150__;JSUlJSUlJSU!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1W1fns7e$>) 
> tries
> to provide the technical justification for the modeling approach taken 
> for the organizational mode option - here is the text, which was 
> referenced in Italo's mail:
>
> *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
> 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.
>
>
> Moreover, implementations exist that are based on the same modeling 
> approach and hence it is *already field proven!*
>
>
> Thanks,
> Dieter
>
>     I think the objective of our work is to define a YANG model for
>     the optical specification methodologies which are used in the
>     field to represent the capabilities of the transponders.
>
>     I do not think that it is in the scope of our work to discuss the
>     optical specification methodologies other than understanding how
>     they could be used for path computation (ensuring interoperability
>     between the sender and receiver) and modelled using YANG.
>
>     As far as I have understood from past discussion, we have agreed
>     to support three optical specification methodologies which are
>     used by existing optical interfaces implementations and we have
>     named them as application code (ITU-T G.698.2), organizational
>     mode and explicit mode.
>
>     After some rounds of discussions and questions for clarification,
>     the latest proposed text to describe the behavior of the
>     organization mode has been prepared on github:
>
>     https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150
>     <https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=fe2bb22f-a1b08b6c-fe2bf2b4-861fcb972bfc-7c29789e806b744e&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fissues*2F29*23issuecomment-719503150__;JSUlJSUlJSU!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1RUYzMO4$>
>
>     I think this updated description has improved the clarity of how
>     the operational mode are implemented and, in particular that:
>
>     "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."
>
>     As a consequence, I think that the YANG model defined in "Case A"
>     below does not work (since it does not provide enough information
>     to check that " the supported carrier frequency and power
>     attributes have a matching range ") while the one defined in "Case
>     B" works properly.
>
>     This text describing the operational mode behavior has been
>     provided by people who have implemented it.
>
>     Therefore, I think we can update the draft with the changes
>     discussed in the last few weeks incorporating the definitions
>     capturing our current understanding of how these optical
>     specification methodologies (application code, organizational mode
>     and explicit mode) behave and the YANG model aligned with our
>     current understanding (i.e., based on "Case B" below).
>
>     Since we are not yet in WG LC stage, we still have plenty of time
>     to update both the description and the YANG model based on the
>     feedbacks we receive from data plane experts.
>
>     My 2 cents
>
>     From: Gert Grammel [mailto:[email-masked]
>     <mailto:[email-masked]>]
>
>     To: [email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>
>
>     We discussed today a difference in the interpretation of the model
>     related to
>     https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29
>     <https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=30d0fc94-6f4bc5d7-30d0bc0f-861fcb972bfc-5d5353826774237a&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fissues*2F29__;JSUlJSUlJQ!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1eeOzXrI$>
>     and its interpretation. The different interpretation lead to
>     different computation requirements.
>
>     The design team appreciates feedback which of both Cases is
>     preferred and what consideration led to the preference
>
>     Case A:
>
>     ======
>
>     https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues#issuecomment-677768528
>     <https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=af80a102-f01b9841-af80e199-861fcb972bfc-509d8509e721d1cb&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fissues*23issuecomment-677768528__;JSUlJSUlJQ!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1fp5UCUX$>
>     from August 20 documented the structure of the model:
>
>     ➢|  +--:(explicit-mode)
>     ➢|    +--ro supported-standard-mode*? leafref
>
>     This snippet would allow to use standard mode or operational mode
>     as a simple matching criteria for compatibility i.e. two
>     transponders with Operational-mode=X and suitable line parameters
>     would interoperate.
>
>     In case of “explicit” mode, the set of parameters provided, can
>     support one or more application code/organizational mode, that
>     means this set of parameters if applied to configure the
>     transceiver, is aligned with one or more application
>     code/organizational mode.
>
>     https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/blob/master/ietf-optical-impairment-topology.tree
>     <https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=dacf1e95-855427d6-dacf5e0e-861fcb972bfc-13a67d7f67153c4a&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fblob*2Fmaster*2Fietf-optical-impairment-topology.tree__;JSUlJSUlJSU!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1ToD0jv4$>
>     contains additional parameters to the Operational Mode that are
>     also replicated in the explicit mode. Those parameters are related
>     to the min/max ranges which are allowed.
>
>     In this case, interoperability can only be provided if the
>     organizational code on each side match AND all other explicit
>     parameters defined in the organizational-code have a matching range.
>
>     (Note that min/max parameters are associated to the organizational
>     mode AND to the explicit mode in this case)
>
>     [email-masked] <mailto:[email-masked]>
>
>     https://www.ietf.org/mailman/listinfo/ccamp
>     <https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=e2f70c1c-bd6c355f-e2f74c87-861fcb972bfc-c52544a2ca4d215d&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fccamp__*3B*21*21NEt6yMaO-gk*21Qf7o1-a2YfLkPqzntQzH4eVYGLpUDj-1ysELXfiLRhkWu-G-RrJBibxJipiVa6Bx*24__;JSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1bI5nQgy$>
>

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 10 Nov 2020 15:02:56 +0000

Hi everyone,

Didn’t we discuss this at the last IETF meeting when I asked to try to reduce the number of options? If I correctly remember we came to the conclusion that there was value in having all of them.

Since the agenda is not super packed at the next meeting and we have quite some time for discussion I suggest to take the opportunity to discuss this once again during the slot at the next meeting so that we can close the issue.
Authors, could you please make sure to cover this topic in your presentation? It would be great to have a short recap on why the 3 options are needed and what is its value.

It would be great to also have a slide to cover what is considered not in agreement in the organizational codes.

Thanks,
Daniele

From: Dieter Beller <[email-masked]>
Sent: den 10 november 2020 12:34
To: Gert Grammel <[email-masked]>; Fatai Zhang <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Italo Busi <[email-masked]>; [email-masked]; [email-masked]
Cc: Belotti, Sergio <[email-masked]>
Subject: Re: 答复: [CCAMP] Webex meeting changed: Optical impairments draft

Hi Gert, all,

there has been consensus to support the 3 options as currently defined in the YANG model (see https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang<https://protect2.fireeye.com/v1/url?k=2ce046fd-737b7ce4-2ce00666-8682aaa22bc0-e427162ccd0d317b&q=1&e=2f5e6400-0b0f-4576-a308-59c4ef579c6f&u=https%3A%2F%2Fgithub.com%2Fietf-ccamp-wg%2Fdraft-ietf-ccamp-optical-impairment-topology-yang>).

Stating that the organizational-mode option is under discussion is passing a wrong message to the CCAMP WG!

The situation is the following: there is rough consensus that the organizational-mode option is valuable and there is only one single person continuously disagreeing because of another
preference.

Thanks,
Sergio and Dieter

Regards

Gert

From: Fatai Zhang <[email-masked]><mailto:[email-masked]>
Date: Friday, November 6, 2020 at 08:01
To: Daniele Ceccarelli <[email-masked]><mailto:[email-masked]>, Italo Busi <[email-masked]><mailto:[email-masked]>, Gert Grammel <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, CCAMP <[email-masked]><mailto:[email-masked]>
Cc: Dieter Beller <[email-masked]><mailto:[email-masked]>
Subject: 答复: [CCAMP] Webex meeting changed: Optical impairments draft

Hi all,

Thanks
Fatai

发件人: Daniele Ceccarelli [mailto:[email-masked]]
发送时间: 2020年11月2日 23:51
收件人: Italo Busi <[email-masked]><mailto:[email-masked]>; 'Gert Grammel' <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
抄送: Dieter Beller <[email-masked]><mailto:[email-masked]>
主题: RE: [CCAMP] Webex meeting changed: Optical impairments draft

Hi,

Cheers,
Daniele

Hi Gert,

  1.  Only application codes
  2.  Only organization modes
  3.  Only explicit modes
  4.  Both application codes and organization modes
  5.  Both application codes and explicit modes
  6.  Both organizational modes and explicit modes
  7.  All options (application code, organizational mode and explicit mode)

My 2 cents

Italo

[[Italo Busi] ] I am not an expert of OpenConfig but Dieter has already confirmed that the latest definition in github (https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150<https://protect2.fireeye.com/v1/url?k=86755ec2-d9ee64db-86751e59-8682aaa22bc0-5e28230c93bbff5c&q=1&e=2f5e6400-0b0f-4576-a308-59c4ef579c6f&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D44077b9a-1b9c42d9-44073b01-861fcb972bfc-e503d80e6efd81dd%26q%3D1%26e%3Dacdb6ee5-5f1d-46c2-9f88-0c7a7270ed91%26u%3Dhttps%2A3A%2A2F%2A2Fgithub.com%2A2Fietf-ccamp-wg%2A2Fdraft-ietf-ccamp-optical-impairment-topology-yang%2A2Fissues%2A2F29%2A23issuecomment-719503150__%3BJSUlJSUlJSU%21%21NEt6yMaO-gk%21VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1dV-vxg_%24>) is aligned with existing implementations (I assume, based on his working experience, he was also considering OpenConfig implementations).

[[Italo Busi] ] According to the latest definition in github (https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150<https://protect2.fireeye.com/v1/url?k=f6ab154c-a9302f55-f6ab55d7-8682aaa22bc0-d1a715fefa5b6416&q=1&e=2f5e6400-0b0f-4576-a308-59c4ef579c6f&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3Dc4b9f9f1-9b22c0b2-c4b9b96a-861fcb972bfc-7ad4277e89b62b88%26q%3D1%26e%3Dacdb6ee5-5f1d-46c2-9f88-0c7a7270ed91%26u%3Dhttps%2A3A%2A2F%2A2Fgithub.com%2A2Fietf-ccamp-wg%2A2Fdraft-ietf-ccamp-optical-impairment-topology-yang%2A2Fissues%2A2F29%2A23issuecomment-719503150__%3BJSUlJSUlJSU%21%21NEt6yMaO-gk%21VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1TYJhR0h%24>) the current list is complete.

Cheers

Gert

I would like to emphasize that the text on GitHub ( see https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150<https://protect2.fireeye.com/v1/url?k=93b3bfe6-cc2885ff-93b3ff7d-8682aaa22bc0-fa0cc6e5575b2c23&q=1&e=2f5e6400-0b0f-4576-a308-59c4ef579c6f&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D2c758499-73eebdda-2c75c402-861fcb972bfc-3975d7433728ea76%26q%3D1%26e%3Dacdb6ee5-5f1d-46c2-9f88-0c7a7270ed91%26u%3Dhttps%2A3A%2A2F%2A2Fgithub.com%2A2Fietf-ccamp-wg%2A2Fdraft-ietf-ccamp-optical-impairment-topology-yang%2A2Fissues%2A2F29%2A23issuecomment-719503150__%3BJSUlJSUlJSU%21%21NEt6yMaO-gk%21VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1W1fns7e%24>) tries
to provide the technical justification for the modeling approach taken for the organizational mode option - here is the text, which was referenced in Italo's mail:

Organizational Mode:

Thanks,
Dieter

Hi Gert,

https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150<https://protect2.fireeye.com/v1/url?k=bf5d7130-e0c64b29-bf5d31ab-8682aaa22bc0-22a5699fed4500f2&q=1&e=2f5e6400-0b0f-4576-a308-59c4ef579c6f&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3Dfe2bb22f-a1b08b6c-fe2bf2b4-861fcb972bfc-7c29789e806b744e%26q%3D1%26e%3Dacdb6ee5-5f1d-46c2-9f88-0c7a7270ed91%26u%3Dhttps%2A3A%2A2F%2A2Fgithub.com%2A2Fietf-ccamp-wg%2A2Fdraft-ietf-ccamp-optical-impairment-topology-yang%2A2Fissues%2A2F29%2A23issuecomment-719503150__%3BJSUlJSUlJSU%21%21NEt6yMaO-gk%21VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1RUYzMO4%24>

My 2 cents

-----Original Message-----

We discussed today a difference in the interpretation of the model related to https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29<https://protect2.fireeye.com/v1/url?k=a72166d4-f8ba5ccd-a721264f-8682aaa22bc0-11929bac80eec169&q=1&e=2f5e6400-0b0f-4576-a308-59c4ef579c6f&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D30d0fc94-6f4bc5d7-30d0bc0f-861fcb972bfc-5d5353826774237a%26q%3D1%26e%3Dacdb6ee5-5f1d-46c2-9f88-0c7a7270ed91%26u%3Dhttps%2A3A%2A2F%2A2Fgithub.com%2A2Fietf-ccamp-wg%2A2Fdraft-ietf-ccamp-optical-impairment-topology-yang%2A2Fissues%2A2F29__%3BJSUlJSUlJQ%21%21NEt6yMaO-gk%21VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1eeOzXrI%24> and its interpretation. The different interpretation lead to different computation requirements.

Case A:

======

https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues#issuecomment-677768528<https://protect2.fireeye.com/v1/url?k=29e3545a-76786e43-29e314c1-8682aaa22bc0-d27d0ff44e0236ef&q=1&e=2f5e6400-0b0f-4576-a308-59c4ef579c6f&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3Daf80a102-f01b9841-af80e199-861fcb972bfc-509d8509e721d1cb%26q%3D1%26e%3Dacdb6ee5-5f1d-46c2-9f88-0c7a7270ed91%26u%3Dhttps%2A3A%2A2F%2A2Fgithub.com%2A2Fietf-ccamp-wg%2A2Fdraft-ietf-ccamp-optical-impairment-topology-yang%2A2Fissues%2A23issuecomment-677768528__%3BJSUlJSUlJQ%21%21NEt6yMaO-gk%21VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1fp5UCUX%24> from August 20 documented the structure of the model:

  +--ro mode-id

  +--ro (mode)?

  |  +--:(G.698.2)

➢ |  +--:(explicit-mode)

  |     ......

Case B:

======

https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/blob/master/ietf-optical-impairment-topology.tree<https://protect2.fireeye.com/v1/url?k=e83c0a86-b7a7309f-e83c4a1d-8682aaa22bc0-e2975ce4a9f43540&q=1&e=2f5e6400-0b0f-4576-a308-59c4ef579c6f&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3Ddacf1e95-855427d6-dacf5e0e-861fcb972bfc-13a67d7f67153c4a%26q%3D1%26e%3Dacdb6ee5-5f1d-46c2-9f88-0c7a7270ed91%26u%3Dhttps%2A3A%2A2F%2A2Fgithub.com%2A2Fietf-ccamp-wg%2A2Fdraft-ietf-ccamp-optical-impairment-topology-yang%2A2Fblob%2A2Fmaster%2A2Fietf-optical-impairment-topology.tree__%3BJSUlJSUlJSU%21%21NEt6yMaO-gk%21VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1ToD0jv4%24> contains additional parameters to the Operational Mode that are also replicated in the explicit mode. Those parameters are related to the min/max ranges which are allowed.

                +--ro mode-id                      string

                +--ro (mode)

                   +--:(G.698.2)

                   |     |       operational-mode

                   |     |       frequency-thz

                   |     |       frequency-thz

                   |     |       frequency-ghz

                   +--:(explicit-mode)

                      +--ro explicit-mode

                         +--ro supported-modes

                         |  |       -> ../../mode-id

                         |          -> ../../mode-id

                         |       identityref

                     <snip>

                         |       frequency-thz

                         |       frequency-thz

                         |       frequency-ghz

                         |       dbm-t

                         |       dbm-t

                         |       dbm-t

                         |       dbm-t

                                 dbm-t

CCAMP mailing list

https://www.ietf.org/mailman/listinfo/ccamp<https://protect2.fireeye.com/v1/url?k=cbc02e0f-945b1416-cbc06e94-8682aaa22bc0-ad4098e21c70aeee&q=1&e=2f5e6400-0b0f-4576-a308-59c4ef579c6f&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3De2f70c1c-bd6c355f-e2f74c87-861fcb972bfc-c52544a2ca4d215d%26q%3D1%26e%3Dacdb6ee5-5f1d-46c2-9f88-0c7a7270ed91%26u%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fwww.ietf.org%2A2Fmailman%2A2Flistinfo%2A2Fccamp__%2A3B%2A21%2A21NEt6yMaO-gk%2A21Qf7o1-a2YfLkPqzntQzH4eVYGLpUDj-1ysELXfiLRhkWu-G-RrJBibxJipiVa6Bx%2A24__%3BJSUlJSUlJSUlJSUlJSUl%21%21NEt6yMaO-gk%21VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1bI5nQgy%24>

-->

---

From: Gert Grammel <[email-masked]>
Date: Tue, 10 Nov 2020 19:58:48 +0000

Daniele,

Sorry for the long email but it is a bit hard for me to understand why this subject seemingly causes heartburn and confusion. The discussion is about agreeing on the definition “organizational mode” and how to use it consistently.

We already have a solid agreement about a lot of things including using the modes (citing from Italo) :
<snip>  the YANG model for each mode should be self-consistent to give implementers the freedom to implement either:
1.       Only application codes
2.       Only organization modes
3.       Only explicit modes
4.       Both application codes and organization modes
5.       Both application codes and explicit modes
6.       Both organizational modes and explicit modes
7.       All options (application code, organizational mode and explicit mode)
<snip>

Back in Oct-29 there was inconsistent description of the Organizational Mode and its use in our draft text. I brought this up and was tasked to summarize the issue collecting feedback. (full details about Case-A and Case-B at the bottom of this email/beginning of this thread).

<snip>

-----Original Message-----

….

<snip>

In essence, the question is whether non-standard organizations can define their own codes along the same implicit lines as ITU-T did for Application Codes (Case-A) or if additional parameters need to be made explicit (case-B).

My view is that a definition needs careful consideration and benefits from a discussion in the WG. It isn’t straight forward and independent on whatever preference people think I would have.

Gert

--
Googling documents with potential conflicts:

  1.  What we know is that The ITU-T Application code defines power and frequency ranges *implicit* in the AC in G.698.2 Table 8-7. IOW max/min frequency are defined as part of the Application Code:
<snip>
Interface at point Ss:
Maximum mean channel output power
Minimum mean channel output power
Minimum spectral Frequency
Maximum spectral Frequency
….
<snip>

  1.  https://tools.ietf.org/html/rfc7581 does not support explicit parameters:
The Optical Interface Classes format is defined as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |S|     Reserved                |    OI Code Points             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Optical Interface Class                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Optical Interface Class  (Cont.)                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where the first 32 bits of the encoding shall be used to identify the
   semantics of the Optical Interface Class in the following way:

   S (Standard bit):

      S=0: identifies non-ITU code points

     S=1: identifies ITU application codes

   With S=0, the OI Code Points field can take the following value:

      0: reserved

   Future work may add support for vendor-specific application codes
   once the ITU-T has completed its work in that area.

  1.  https://www.ietf.org/id/draft-meuric-ccamp-tsvmode-signaling-01.txt  currently has no explicit parameters.
3.1.1.  WDM-Transceiver-ModeID Sub-TLV

   This document introduces the WDM-Transceiver-ModeID sub-TLV so as to
   carry the Transceiver Type and ModeID.  It has the following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type = TBD1  |  Length = 16  |   Reserved    |AppID Type=TBD6|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              OUI                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          OUI (cont'd)         |            ModeID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Tsv-Type                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Application ID Type (8 bits): As per section 5 of
   [I-D.ietf-ccamp-dwdm-if-lmp], this field allows to distinguish
   between the possible encodings of the trailing "Application ID"
   field.  This specification defines a new Application ID Type (value
   TBD6) that extends the "Proprietary" type and specifies specific
   fields within the "value" bytes:

   o  the first 6 bytes of the Application Identifier must contain the
      hexadecimal representation of an Organizationally Unique
      Identifier (OUI);

   o  the following 2 bytes encode a ModeID;

   o  the last 4 bytes carry a Tsv-Type.

   Tsv-Type (32 bits): A transponder-specific value allowing to identify
   a compatible Tsv-Type at the remote end, and supporting a set of

  1.  OpenConfig defines https://github.com/openconfig/public/blob/master/release/models/optical-transport/openconfig-terminal-device.yang says:
leaf operational-mode {
type uint16;
description
"Vendor-specific mode identifier -- sets the operational
mode for the channel. <snip>

  1.  …

Side note:

  *   Although I do not share some of the comments from Italo on Nov.1, I set the response aside until we have a clear picture in which direction the WG wants to go. Details can be discussed afterwards

From: Daniele Ceccarelli <[email-masked]>
Date: Tuesday, November 10, 2020 at 16:03
To: Dieter Beller <[email-masked]>, Gert Grammel <[email-masked]>, Fatai Zhang <[email-masked]>, Italo Busi <[email-masked]>, "[email-masked]" <[email-masked]>, CCAMP <[email-masked]>
Cc: "Belotti, Sergio" <[email-masked]>
Subject: RE: 答复: [CCAMP] Webex meeting changed: Optical impairments draft

Hi everyone,

Thanks,
Daniele

Hi Gert, all,

there has been consensus to support the 3 options as currently defined in the YANG model (see https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=2ce046fd-737b7ce4-2ce00666-8682aaa22bc0-e427162ccd0d317b&q=1&e=2f5e6400-0b0f-4576-a308-59c4ef579c6f&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang__;JSUlJSU!!NEt6yMaO-gk!SunmVcYqXjqvuGwdx_ZZrLOCXVO5PQVW5ztlO0mNeRxQ4N7n1HiGYCr2elFi2HKM$>).

Thanks,
Sergio and Dieter

Regards

Gert

Hi all,

Thanks
Fatai

Hi,

Cheers,
Daniele

Hi Gert,

My 2 cents

Italo

[[Italo Busi] ] I am not an expert of OpenConfig but Dieter has already confirmed that the latest definition in github (https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=86755ec2-d9ee64db-86751e59-8682aaa22bc0-5e28230c93bbff5c&q=1&e=2f5e6400-0b0f-4576-a308-59c4ef579c6f&u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fprotect2.fireeye.com*2Fv1*2Furl*3Fk*3D44077b9a-1b9c42d9-44073b01-861fcb972bfc-e503d80e6efd81dd*26q*3D1*26e*3Dacdb6ee5-5f1d-46c2-9f88-0c7a7270ed91*26u*3Dhttps*2A3A*2A2F*2A2Fgithub.com*2A2Fietf-ccamp-wg*2A2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2A2Fissues*2A2F29*2A23issuecomment-719503150__*3BJSUlJSUlJSU*21*21NEt6yMaO-gk*21VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1dV-vxg_*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!SunmVcYqXjqvuGwdx_ZZrLOCXVO5PQVW5ztlO0mNeRxQ4N7n1HiGYCr2enLrOmS_$>) is aligned with existing implementations (I assume, based on his working experience, he was also considering OpenConfig implementations).

[[Italo Busi] ] According to the latest definition in github (https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=f6ab154c-a9302f55-f6ab55d7-8682aaa22bc0-d1a715fefa5b6416&q=1&e=2f5e6400-0b0f-4576-a308-59c4ef579c6f&u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fprotect2.fireeye.com*2Fv1*2Furl*3Fk*3Dc4b9f9f1-9b22c0b2-c4b9b96a-861fcb972bfc-7ad4277e89b62b88*26q*3D1*26e*3Dacdb6ee5-5f1d-46c2-9f88-0c7a7270ed91*26u*3Dhttps*2A3A*2A2F*2A2Fgithub.com*2A2Fietf-ccamp-wg*2A2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2A2Fissues*2A2F29*2A23issuecomment-719503150__*3BJSUlJSUlJSU*21*21NEt6yMaO-gk*21VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1TYJhR0h*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!SunmVcYqXjqvuGwdx_ZZrLOCXVO5PQVW5ztlO0mNeRxQ4N7n1HiGYCr2esrtl0z_$>) the current list is complete.

Cheers

Gert

I would like to emphasize that the text on GitHub ( see https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=93b3bfe6-cc2885ff-93b3ff7d-8682aaa22bc0-fa0cc6e5575b2c23&q=1&e=2f5e6400-0b0f-4576-a308-59c4ef579c6f&u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fprotect2.fireeye.com*2Fv1*2Furl*3Fk*3D2c758499-73eebdda-2c75c402-861fcb972bfc-3975d7433728ea76*26q*3D1*26e*3Dacdb6ee5-5f1d-46c2-9f88-0c7a7270ed91*26u*3Dhttps*2A3A*2A2F*2A2Fgithub.com*2A2Fietf-ccamp-wg*2A2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2A2Fissues*2A2F29*2A23issuecomment-719503150__*3BJSUlJSUlJSU*21*21NEt6yMaO-gk*21VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1W1fns7e*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!SunmVcYqXjqvuGwdx_ZZrLOCXVO5PQVW5ztlO0mNeRxQ4N7n1HiGYCr2er1Cwlqr$>) tries
to provide the technical justification for the modeling approach taken for the organizational mode option - here is the text, which was referenced in Italo's mail:

Organizational Mode:

Thanks,
Dieter

Hi Gert,

https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=bf5d7130-e0c64b29-bf5d31ab-8682aaa22bc0-22a5699fed4500f2&q=1&e=2f5e6400-0b0f-4576-a308-59c4ef579c6f&u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fprotect2.fireeye.com*2Fv1*2Furl*3Fk*3Dfe2bb22f-a1b08b6c-fe2bf2b4-861fcb972bfc-7c29789e806b744e*26q*3D1*26e*3Dacdb6ee5-5f1d-46c2-9f88-0c7a7270ed91*26u*3Dhttps*2A3A*2A2F*2A2Fgithub.com*2A2Fietf-ccamp-wg*2A2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2A2Fissues*2A2F29*2A23issuecomment-719503150__*3BJSUlJSUlJSU*21*21NEt6yMaO-gk*21VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1RUYzMO4*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!SunmVcYqXjqvuGwdx_ZZrLOCXVO5PQVW5ztlO0mNeRxQ4N7n1HiGYCr2ehuxwb6A$>

My 2 cents

-----Original Message-----

We discussed today a difference in the interpretation of the model related to https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=a72166d4-f8ba5ccd-a721264f-8682aaa22bc0-11929bac80eec169&q=1&e=2f5e6400-0b0f-4576-a308-59c4ef579c6f&u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fprotect2.fireeye.com*2Fv1*2Furl*3Fk*3D30d0fc94-6f4bc5d7-30d0bc0f-861fcb972bfc-5d5353826774237a*26q*3D1*26e*3Dacdb6ee5-5f1d-46c2-9f88-0c7a7270ed91*26u*3Dhttps*2A3A*2A2F*2A2Fgithub.com*2A2Fietf-ccamp-wg*2A2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2A2Fissues*2A2F29__*3BJSUlJSUlJQ*21*21NEt6yMaO-gk*21VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1eeOzXrI*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!SunmVcYqXjqvuGwdx_ZZrLOCXVO5PQVW5ztlO0mNeRxQ4N7n1HiGYCr2erGOpsRy$> and its interpretation. The different interpretation lead to different computation requirements.

Case A:

======

https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues#issuecomment-677768528<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=29e3545a-76786e43-29e314c1-8682aaa22bc0-d27d0ff44e0236ef&q=1&e=2f5e6400-0b0f-4576-a308-59c4ef579c6f&u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fprotect2.fireeye.com*2Fv1*2Furl*3Fk*3Daf80a102-f01b9841-af80e199-861fcb972bfc-509d8509e721d1cb*26q*3D1*26e*3Dacdb6ee5-5f1d-46c2-9f88-0c7a7270ed91*26u*3Dhttps*2A3A*2A2F*2A2Fgithub.com*2A2Fietf-ccamp-wg*2A2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2A2Fissues*2A23issuecomment-677768528__*3BJSUlJSUlJQ*21*21NEt6yMaO-gk*21VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1fp5UCUX*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!SunmVcYqXjqvuGwdx_ZZrLOCXVO5PQVW5ztlO0mNeRxQ4N7n1HiGYCr2enAZmvC2$> from August 20 documented the structure of the model:

  +--ro mode-id

  +--ro (mode)?

  |  +--:(G.698.2)

➢ |  +--:(explicit-mode)

  |     ......

Case B:

======

https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/blob/master/ietf-optical-impairment-topology.tree<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=e83c0a86-b7a7309f-e83c4a1d-8682aaa22bc0-e2975ce4a9f43540&q=1&e=2f5e6400-0b0f-4576-a308-59c4ef579c6f&u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fprotect2.fireeye.com*2Fv1*2Furl*3Fk*3Ddacf1e95-855427d6-dacf5e0e-861fcb972bfc-13a67d7f67153c4a*26q*3D1*26e*3Dacdb6ee5-5f1d-46c2-9f88-0c7a7270ed91*26u*3Dhttps*2A3A*2A2F*2A2Fgithub.com*2A2Fietf-ccamp-wg*2A2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2A2Fblob*2A2Fmaster*2A2Fietf-optical-impairment-topology.tree__*3BJSUlJSUlJSU*21*21NEt6yMaO-gk*21VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1ToD0jv4*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!SunmVcYqXjqvuGwdx_ZZrLOCXVO5PQVW5ztlO0mNeRxQ4N7n1HiGYCr2eqeyE3KQ$> contains additional parameters to the Operational Mode that are also replicated in the explicit mode. Those parameters are related to the min/max ranges which are allowed.

                +--ro mode-id                      string

                +--ro (mode)

                   +--:(G.698.2)

                   |     |       operational-mode

                   |     |       frequency-thz

                   |     |       frequency-thz

                   |     |       frequency-ghz

                   +--:(explicit-mode)

                      +--ro explicit-mode

                         +--ro supported-modes

                         |  |       -> ../../mode-id

                         |          -> ../../mode-id

                         |       identityref

                     <snip>

                         |       frequency-thz

                         |       frequency-thz

                         |       frequency-ghz

                         |       dbm-t

                         |       dbm-t

                         |       dbm-t

                         |       dbm-t

                                 dbm-t

CCAMP mailing list

https://www.ietf.org/mailman/listinfo/ccamp<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=cbc02e0f-945b1416-cbc06e94-8682aaa22bc0-ad4098e21c70aeee&q=1&e=2f5e6400-0b0f-4576-a308-59c4ef579c6f&u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fprotect2.fireeye.com*2Fv1*2Furl*3Fk*3De2f70c1c-bd6c355f-e2f74c87-861fcb972bfc-c52544a2ca4d215d*26q*3D1*26e*3Dacdb6ee5-5f1d-46c2-9f88-0c7a7270ed91*26u*3Dhttps*2A3A*2A2F*2A2Furldefense.com*2A2Fv3*2A2F__https*2A3A*2A2Fwww.ietf.org*2A2Fmailman*2A2Flistinfo*2A2Fccamp__*2A3B*2A21*2A21NEt6yMaO-gk*2A21Qf7o1-a2YfLkPqzntQzH4eVYGLpUDj-1ysELXfiLRhkWu-G-RrJBibxJipiVa6Bx*2A24__*3BJSUlJSUlJSUlJSUlJSUl*21*21NEt6yMaO-gk*21VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1bI5nQgy*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!SunmVcYqXjqvuGwdx_ZZrLOCXVO5PQVW5ztlO0mNeRxQ4N7n1HiGYCr2eohl4PN6$>

-->

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 11 Nov 2020 08:20:46 +0000

Hi Gert,

Thanks for the explanation, now it’s clear to me.
I hope we’ll get the opportunity next week to discuss pros and cons of case A and case B and eventually come to a consensus.

BR
Daniele

From: Gert Grammel <[email-masked]>
Sent: den 10 november 2020 20:59
To: Daniele Ceccarelli <[email-masked]>; Dieter Beller <[email-masked]>; Fatai Zhang <[email-masked]>; Italo Busi <[email-masked]>; [email-masked]; [email-masked]
Cc: Belotti, Sergio <[email-masked]>
Subject: Re: 答复: [CCAMP] Webex meeting changed: Optical impairments draft

Daniele,

<snip>

-----Original Message-----

….

<snip>

Gert

     0                   1                   2                   3

   S (Standard bit):

      0: reserved

       0                   1                   2                   3

  1.  OpenConfig defines https://github.com/openconfig/public/blob/master/release/models/optical-transport/openconfig-terminal-device.yang<https://protect2.fireeye.com/v1/url?k=6dc97a60-3252434b-6dc93afb-866038973a15-073776e540d60778&q=1&e=1be091a7-dda3-4b0b-90c1-ace9c8b86618&u=https%3A%2F%2Fgithub.com%2Fopenconfig%2Fpublic%2Fblob%2Fmaster%2Frelease%2Fmodels%2Foptical-transport%2Fopenconfig-terminal-device.yang> says:
leaf operational-mode {
type uint16;
description
"Vendor-specific mode identifier -- sets the operational
mode for the channel. <snip>

  1.  …

Side note:

From: Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 10, 2020 at 16:03
To: Dieter Beller <[email-masked]<mailto:[email-masked]>>, Gert Grammel <[email-masked]<mailto:[email-masked]>>, Fatai Zhang <[email-masked]<mailto:[email-masked]>>, Italo Busi <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, CCAMP <[email-masked]<mailto:[email-masked]>>
Cc: "Belotti, Sergio" <[email-masked]<mailto:[email-masked]>>
Subject: RE: 答复: [CCAMP] Webex meeting changed: Optical impairments draft

Hi everyone,

Thanks,
Daniele

From: Dieter Beller <[email-masked]<mailto:[email-masked]>>
Sent: den 10 november 2020 12:34
To: Gert Grammel <[email-masked]<mailto:[email-masked]>>; Fatai Zhang <[email-masked]<mailto:[email-masked]>>; Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; Italo Busi <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Belotti, Sergio <[email-masked]<mailto:[email-masked]>>
Subject: Re: 答复: [CCAMP] Webex meeting changed: Optical impairments draft

Hi Gert, all,

Thanks,
Sergio and Dieter

Regards

Gert

Hi all,

Thanks
Fatai

Hi,

Cheers,
Daniele

Hi Gert,

My 2 cents

Italo

Cheers

Gert

Organizational Mode:

Thanks,
Dieter

Hi Gert,

My 2 cents

-----Original Message-----

Case A:

======

  +--ro mode-id

  +--ro (mode)?

  |  +--:(G.698.2)

➢ |  +--:(explicit-mode)

  |     ......

Case B:

======

                +--ro mode-id                      string

                +--ro (mode)

                   +--:(G.698.2)

                   |     |       operational-mode

                   |     |       frequency-thz

                   |     |       frequency-thz

                   |     |       frequency-ghz

                   +--:(explicit-mode)

                      +--ro explicit-mode

                         +--ro supported-modes

                         |  |       -> ../../mode-id

                         |          -> ../../mode-id

                         |       identityref

                     <snip>

                         |       frequency-thz

                         |       frequency-thz

                         |       frequency-ghz

                         |       dbm-t

                         |       dbm-t

                         |       dbm-t

                         |       dbm-t

                                 dbm-t

CCAMP mailing list

-->

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Wed, 11 Nov 2020 09:40:00 +0000

Hi Gert, all,

when citing another YANG model the full picture should be provided:
  grouping terminal-optical-channel-config {
    description
      "Configuration data for describing optical channels";

    leaf frequency {
      type oc-opt-types:frequency-type;
      description
        "Frequency of the optical channel, expressed in MHz";
    }

    leaf target-output-power {
      type decimal64 {
        fraction-digits 2;
      }
      units dBm;
      description
        "Target output optical power level of the optical channel,
        expressed in increments of 0.01 dBm (decibel-milliwats)";
    }

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

Frequency and power are modeled separately and the organizational-mode approach follows exactly the same principle.
The text in the draft provides the rationale.

Thanks,
Dieter and Sergio

From: Gert Grammel <[email-masked]>
Sent: Tuesday, November 10, 2020 8:59 PM
To: Daniele Ceccarelli <[email-masked]>; Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>; Fatai Zhang <[email-masked]>; Italo Busi <[email-masked]>; [email-masked]; [email-masked]
Cc: Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>
Subject: Re: 答复: [CCAMP] Webex meeting changed: Optical impairments draft

Daniele,

<snip>

-----Original Message-----

….

<snip>

Gert

     0                   1                   2                   3

   S (Standard bit):

      0: reserved

       0                   1                   2                   3

  1.  …

Side note:

Hi everyone,

Thanks,
Daniele

Hi Gert, all,

Thanks,
Sergio and Dieter

Regards

Gert

Hi all,

Thanks
Fatai

Hi,

Cheers,
Daniele

Hi Gert,

My 2 cents

Italo

Cheers

Gert

Organizational Mode:

Thanks,
Dieter

Hi Gert,

My 2 cents

-----Original Message-----

Case A:

======

  +--ro mode-id

  +--ro (mode)?

  |  +--:(G.698.2)

➢ |  +--:(explicit-mode)

  |     ......

Case B:

======

                +--ro mode-id                      string

                +--ro (mode)

                   +--:(G.698.2)

                   |     |       operational-mode

                   |     |       frequency-thz

                   |     |       frequency-thz

                   |     |       frequency-ghz

                   +--:(explicit-mode)

                      +--ro explicit-mode

                         +--ro supported-modes

                         |  |       -> ../../mode-id

                         |          -> ../../mode-id

                         |       identityref

                     <snip>

                         |       frequency-thz

                         |       frequency-thz

                         |       frequency-ghz

                         |       dbm-t

                         |       dbm-t

                         |       dbm-t

                         |       dbm-t

                                 dbm-t

CCAMP mailing list

-->

---

From: Gert Grammel <[email-masked]>
Date: Wed, 11 Nov 2020 11:58:43 +0000

Hi Sergio, Dieter,

The googled list was intended to provide a collection of documents with a potential issue in the definition of organizational mode. Feel free to add more references as you see fit. It is simply meant to provide a collection of documents to check. The only document I intentionally did not put on the list was https://datatracker.ietf.org/doc/draft-ietf-ccamp-dwdm-if-lmp/?include_text=1 since I am a Co-editor and may be interpreted as biased. Note: I am be happy to adjust that draft to whatever direction the WG decides.

About your more detailed comment:
The issue here is whether an operational-mode features *explicit* min-max parameters such as e.g. min/max frequency (full list at the beginning of this thread). The Open Config YANG-Model cited below doesn’t have that provision.
Once you figured out what min/max boundaries are, the actual frequency needs to be configured in that min/max range. That’s what leaf frequency does. This part of the model is consistent with any of the operational-mode cases discussed and doesn’t appear to be contentious.

Regards

Gert

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Wednesday, November 11, 2020 at 10:40
To: Gert Grammel <[email-masked]>, Daniele Ceccarelli <[email-masked]>, Dieter Beller <[email-masked]>, Fatai Zhang <[email-masked]>, Italo Busi <[email-masked]>, "[email-masked]" <[email-masked]>, CCAMP <[email-masked]>
Subject: RE: 答复: [CCAMP] Webex meeting changed: Optical impairments draft

Hi Gert, all,

    leaf frequency {

    leaf operational-mode {
      type uint16;
      description

Thanks,
Dieter and Sergio

Daniele,

<snip>

-----Original Message-----

….

<snip>

Gert

  1.  https://tools.ietf.org/html/rfc7581<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7581__;!!NEt6yMaO-gk!WwnyQbZbxWimGVWQBZUakzJj7qyUl98ef1qaLkqyQhCAvFZzTSZh1HZxv9PawE7S$> does not support explicit parameters:
The Optical Interface Classes format is defined as follows:

     0                   1                   2                   3

   S (Standard bit):

      0: reserved

  1.  https://www.ietf.org/id/draft-meuric-ccamp-tsvmode-signaling-01.txt<https://urldefense.com/v3/__https:/www.ietf.org/id/draft-meuric-ccamp-tsvmode-signaling-01.txt__;!!NEt6yMaO-gk!WwnyQbZbxWimGVWQBZUakzJj7qyUl98ef1qaLkqyQhCAvFZzTSZh1HZxv8L_t0e1$>  currently has no explicit parameters.
3.1.1.  WDM-Transceiver-ModeID Sub-TLV

       0                   1                   2                   3

  1.  …

Side note:

Hi everyone,

Thanks,
Daniele

Hi Gert, all,

Thanks,
Sergio and Dieter

Regards

Gert

Hi all,

Thanks
Fatai

Hi,

Cheers,
Daniele

Hi Gert,

My 2 cents

Italo

Cheers

Gert

Organizational Mode:

Thanks,
Dieter

Hi Gert,

My 2 cents

-----Original Message-----

Case A:

======

  +--ro mode-id

  +--ro (mode)?

  |  +--:(G.698.2)

➢ |  +--:(explicit-mode)

  |     ......

Case B:

======

                +--ro mode-id                      string

                +--ro (mode)

                   +--:(G.698.2)

                   |     |       operational-mode

                   |     |       frequency-thz

                   |     |       frequency-thz

                   |     |       frequency-ghz

                   +--:(explicit-mode)

                      +--ro explicit-mode

                         +--ro supported-modes

                         |  |       -> ../../mode-id

                         |          -> ../../mode-id

                         |       identityref

                     <snip>

                         |       frequency-thz

                         |       frequency-thz

                         |       frequency-ghz

                         |       dbm-t

                         |       dbm-t

                         |       dbm-t

                         |       dbm-t

                                 dbm-t

CCAMP mailing list

-->