search

ietf-ccamp-wg / draft-ietf-ccamp-optical-impairment-topology-yang

8 stars 10 forks source link

Modelling of Transponders #29

Closed italobusi closed 3 years ago

italobusi commented 4 years ago

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

It is suggested to reconcile these models

EstherLerouzic commented 4 years ago

here is a change proposal for the text. Transponder-text-section-2.5_elr.docx

I added a table with my understanding of the explicit/implicit presence of parameters

sergiobelotti commented 4 years ago

here is a change proposal for the text. Transponder-text-section-2.5_elr.docx

I added a table with my understanding of the explicit/implicit presence of parameters

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

italobusi commented 4 years ago

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

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

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

ggrammel commented 4 years ago

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

My understanding is:

italobusi commented 4 years ago

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

My understanding is:

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

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

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

My understanding is that:

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

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

ggrammel commented 4 years ago

https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-662531309 was setting out that " Organizational Mode: An organizational mode represents a non-standard optical interface specification towards the realization of transversely compatible DWDM systems. Two transceivers supporting the same organizational mode and a line system matching the constraints, defined by the organization which owns the mode, for that organizational will interoperate. These organizations can be MSA-Groups, Operators, System vendors, component vendors etc." So apart from the organization, Application Code and organizational mode are considered the same.

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

sergiobelotti commented 4 years ago

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

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

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

@ggrammel : Yes, your understanding of the model 1B is correct. I assume you are referring to the table proposed in https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/files/5424280/Transponder-text-section-2.5_elr.docx

My understanding is that:

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

@italobusi : Yes, you got correctly . The only parameters that also organizational mode is showing up is the range of soem attributes like rx-power-channel or tx-power-channel as we discussed and agreed in https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-610288875 -supported transmitter tuning range [f_tx_min, f_tx_max] -supported transmitter tunability grid (in GHz) -supported transmitter power range [p_tx-min, p_tx_max] -supported receiver power range [p_rx-min, p_rx_max]

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

@ggrammel : correct, this is also my understanding of organizational mode, the parameters I've indicated above are not implicit in the organizational mode. The YANG model and the table seem align with this understanding. @italobusi @ggrammel : yes , there is complete alignment

ggrammel commented 4 years ago

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

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

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

sergiobelotti commented 4 years ago

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

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

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

ggrammel commented 4 years ago

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

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

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

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

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

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

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

dieterbeller commented 4 years ago

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

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

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

ggrammel commented 4 years ago

no issue with this text

ggrammel commented 4 years ago

2020-10-29 AI:

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

egriseri commented 4 years ago

May I suggest to add a couple of lines to specify the ratio of having a subset of parameters explicitly reported? Something like this

“A subset of the transceiver properties subsumed by the operational mode may be explicitly exposed; this allows transceivers of different performances interoperate without the need to introduce a specific operational mode. One use case includes transceivers which differ only by the input power sensitivities. Another use case include transceivers which differ only by the tunability range of the carrier frequency. The set of transceiver characteristic explicitly exposed is limited to input and output power and tunability capabilities of the transceiver.”

ggrammel commented 4 years ago

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

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

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

dieterbeller commented 4 years ago

Based on Enrico's comment https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-718893899, I updated the text above (see https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-718774926) as follows:

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

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

ggrammel commented 4 years ago

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

sergiobelotti commented 4 years ago

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

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

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

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

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

ggrammel commented 4 years ago

@sergiobelottimailto:notifications@github.com can you be more specific about “organizational mode, how it works”? In past discussions @Dieter claimed it would be a simple match condition in OpenConfig. If the purpose of the operational mode is to mimic how OpenConfig works, then what needs to change?

The model there looks like this: https://github.com/openconfig/public/blob/master/release/models/optical-transport/openconfig-terminal-device.yang leaf operational-mode {

type uint16;

description

"Vendor-specific mode identifier -- sets the operational

mode for the channel. The specified operational mode must

exist in the list of supported operational modes supplied

by the device";

//

// Ideally, this leaf should be a leafref to the supported

// operational modes, but YANG 1.0 does not allow a r/w

// leaf to be a leafref to a r/o leaf. }

From: sergiobelotti notifications@github.com Reply-To: ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang reply@reply.github.com Date: Friday, October 30, 2020 at 16:09 To: ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang draft-ietf-ccamp-optical-impairment-topology-yang@noreply.github.com Cc: Gert Grammel ggrammel@juniper.net, Mention mention@noreply.github.com Subject: Re: [ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang] Modelling of Transponders (#29)

[External Email. Be cautious of content]

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

here is a change proposal for the text. Transponder-text-section-2.5_elr.docxhttps://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/files/5424280/Transponder-text-section-2.5_elr.docx I added a table with my understanding of the explicit/implicit presence of parameters

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

Additional comments/text proposals: Transponder-text-section-2.5_elr-sb-261020-ib.docxhttps://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/files/5440306/Transponder-text-section-2.5_elr-sb-261020-ib.docx

@italobusihttps://github.com/italobusi @EstherLerouzichttps://github.com/EstherLerouzic : Taking into account the new text from Dieter ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang#29 (comment)https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150 I've uploaded the new section 2.5 to be used for uploading of the new version of the draft in the view of IETF 109. Remain open some comment about definitions from Italo but we can survive with the present text for uploading and take the action to verify with our internal Q6 expert for better definition of transponder/transceiver. Transponder-text-section-2.5_301020.docxhttps://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/files/5465887/Transponder-text-section-2.5_301020.docx

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719609123, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADTQOVFPMA4TRGDBO3SLHFLSNLJIVANCNFSM4LC6BAFA.

Juniper Business Use Only

EstherLerouzic commented 4 years ago

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

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

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

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

thanks !

egriseri commented 4 years ago

@ggrammel

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

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

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

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

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

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

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

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

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

See answers above.

ggrammel commented 4 years ago

@egriserimailto:notifications@github.com

  1. what is your understanding of an Operational Mode? Is this understanding in line with OpenConfig definitions or any other organization? Would be great to align here.
  2. If the interoperability is done by matching of (organization-identifier, operational-mode), then there is no need to check anything. However when you add a frequency range to organizational modes and the frequency range of transmitter and receiver are different, then there is no interoperability on the non-overlapping range. This complicates the path calculation quite a bit.
  3. Thanks for confirming that the parameters are exactly the ones in discussion and are not going to be extended.
  4. What are your thoughts about how to circumvent the incompatibility issue?

From: egriseri notifications@github.com Reply-To: ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang reply@reply.github.com Date: Friday, October 30, 2020 at 19:32 To: ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang draft-ietf-ccamp-optical-impairment-topology-yang@noreply.github.com Cc: Gert Grammel ggrammel@juniper.net, Mention mention@noreply.github.com Subject: Re: [ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang] Modelling of Transponders (#29)

[External Email. Be cautious of content]

@ggrammelhttps://github.com/ggrammel

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

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

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

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

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

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

The explicit parameters are listed in @dieterbellerhttps://github.com/dieterbeller answer (and in the agreed Yang code). No more.

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

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

See answers above.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719725753, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADTQOVAF333TJFILE23J3N3SNMBEJANCNFSM4LC6BAFA.

Juniper Business Use Only

egriseri commented 4 years ago

@egriserimailto:notifications@github.com

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

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

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

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

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

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

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

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

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

ggrammel commented 3 years ago

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

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

sergiobelotti commented 3 years ago

closed issue with commit https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/pull/36/commits/8b7c07ee04c2db56b478ed4bb269308006a4e976