Modeling of optical impairments for ROADMs

[dieterbeller]

Up to now, only optical impairments imposed by the ingress and egress amplifier of a ROADM are reflected in the L0 topology YANG model. Other significant optical impairments imposed by the ROADM (e.g. OSNR degradation, WSS impairments like cross-talk, etc.) also have to be reflected in the model. The following aspects have to be addressed:

• What ROADM architectures shall the model support (integrated ROADM vs dis-aggregated ROADM)
• What are the impairments that have to be considered - which of them are significant
• Find the right balance between accuracy and simplicity of the model (has impacts on the path computation algorithm!)

[dieterbeller]

As input for discussion, I put some slides together showing 3 possible ROADM architectures. These slides are addressing the first bullet item above: What ROADM architectures shall the model support (integrated ROADM vs dis-aggregated ROADM)?

ROADM architectures.pptx

[italobusi]

Slides discussed during the 2019-10-02 call: ROADM-mapping-to-TE-node.pptx

[italobusi]

I have a question based on the discussion during the 2019-10-02 which we can discuss tomorrow

The OMS Link is built by the serial concatenation of "OMS elements", such as amplifiers and fibers. From a topological perspective, it is modeled as a TE-Link. From optical impairments perspective, all the "OMS elements" that compose the OMS Link are exposed (as a list under the TE-Link), together with their attributes related with optical impairments.

A (pass-through or add/drop) "path" across the ROADM is built by the serial concatenation of "ROADM elements", such as amplifiers and fibers (within the ROADM). From a topological perspective, a pass-through "path" can be modeled as an entry of the detailed-connectivity-matrix while an add/drop "path" can be modeled as an entry of the local-link-connectivity-list. From optical impairments perspective, I have understood that it is desirable not to expose these "ROADM elements" but just to provide a set of attributes that abstract/summarize the optical impairments of the serial concatenation of these elements.

My doubt/question is that, if it is possible to abstract/summarize the optical impairments of the serial concatenation of these elements, such as amplifiers and fibers, when they are within the ROADM, why it is not possible to do the same when they on an OMS Link?

[ggalimba56]

Hi Italo,

Your question is fare… the big difference between the internal (to the node) and The “esternal” interconnections is the is:

• the fiber length (meter vs. km)
• kind of amplifiers (power, noise figure or even raman)
• existence of VOA per channel (in ROADMs) able to fine equalize the signals

It is given that we need to take in account of the impairments introduced by the ROADM:

• in pass trough (w/o amplifiers – already counted in the OMS line)
• in ADD/DROP potentially including ADD/DROP amplification

Finally there in the possibility to model the line (OMS) giving a single parameter (e.g. OSNR and OSNR sigma) In case of full coherent network, but this is the result of a (complex) calculation using the Ampli parameters, Fiber length and type, etc…. and have a very simplified model. In this way we just mode the issue somewhere else.

Best Regards,

Gab.

[cid:image001.png@01D57F5E.6FCB5E70]

Gabriele Galimberti Principal Engineer Cisco Photonics Srl Italy

via S.Maria Molgora, 48 C 20871 - Vimercate (MB) Italy www.cisco.com/global/IT/http://www.cisco.com/global/IT/

ggalimbe@cisco.commailto:ggalimbe@cisco.com Phone :+39 039 2091462 Mobile :+39 335 7481947 Fax :+39 039 2092049

From: italobusi notifications@github.com Reply-To: younglee-ietf/ietf-optical-impairment-yang reply@reply.github.com Date: Wednesday, 9 October 2019 at 19:55 To: younglee-ietf/ietf-optical-impairment-yang ietf-optical-impairment-yang@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [younglee-ietf/ietf-optical-impairment-yang] Modeling of optical impairments for ROADMs (#9)

I have a question based on the discussion during the 2019-10-02 which we can discuss tomorrow

The OMS Link is built by the serial concatenation of "OMS elements", such as amplifiers and fibers. From a topological perspective, it is modeled as a TE-Link. From optical impairments perspective, all the "OMS elements" that compose the OMS Link are exposed (as a list under the TE-Link), together with their attributes related with optical impairments.

A (pass-through or add/drop) "path" across the ROADM is built by the serial concatenation of "ROADM elements", such as amplifiers and fibers (within the ROADM). From a topological perspective, a pass-through "path" can be modeled as an entry of the detailed-connectivity-matrix while an add/drop "path" can be modeled as an entry of the local-link-connectivity-list. From optical impairments perspective, I have understood that it is desirable not to expose these "ROADM elements" but just to provide a set of attributes that abstract/summarize the optical impairments of the serial concatenation of these elements.

My doubt/question is that, if it is possible to abstract/summarize the optical impairments of the serial concatenation of these elements, such as amplifiers and fibers, when they are within the ROADM, why it is not possible to do the same when they on an OMS Link?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/younglee-ietf/ietf-optical-impairment-yang/issues/9?email_source=notifications&email_token=ADQWFMC5G6V4MOKWQQWAL5LQNYLJZA5CNFSM4HPHWILKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAYYGUI#issuecomment-540115793, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADQWFMDHEKWNNWVC6RKPZJDQNYLJZANCNFSM4HPHWILA.

[sergiobelotti]

We have internally prepared some slides to have a first proposal for optical impairments parameters for ROADM node. These slides are just an introduction of the parameters proposed. ROADM-optical-imp-v4.pptx

[EstherLerouzic]

As discussed last week I have tried to find where to include the roadm params (as defined in sergio and italo). you can find the augment yang here: https://github.com/EstherLerouzic/ietf-optical-impairment-yang/tree/roadm-params with the tree view (diff on the right part of the image)

could you please check if this correspond to our discussions and if this where the augment should be (I used the ietf-te-topo appendix C )

[sergiobelotti]

Hi Esther, I have some comments in the proposal, I'm sorry to have had no time to put direcly encoding. 1) Type-variety usage for ROADM is not what is proposed in the optical impairments for ROADM nodes since every parameters cannot be linke to a type of ROADM technology and equipement but can vary form ROADM to ROADM and so must be explicitly represented .

2) Grouping roadm-attributes is fine but my understanding was to have a parameter value non dependent of element , so I would delete list related to element (for express, add and drop E.g. for express list express-elements { key "elt-index"; description "defines the different crossed elements in drop path"; leaf elt-index { type uint16; description "ordered list of Index of roadm element"; } uses roadm-detailed-element; 3) You put all the structure of roadm-attributes under te-node-attribute: I think we should use connectivity matrix and LLCL . augment "/nw:networks/nw:network/nw:node/tet:te/"

• "tet:te-node-attributes/tet:connectivity-matrices/" { when "/nw:networks/nw:network/nw:network-types" +"/tet:te-topology/optical-imp-topo:optical-impairment-topology" { description "This augment is only valid for Optical Impairment."; } description "Optical Node augmentation for impairment data."; container ROADM-attributes { config false; description "ROADM attributes"; uses roadm-attributes; } }

When you use "connectivity-matrices" you match with the requirement of scalability since these attrubutes are valid for any entry, as required.

For particular case in which we need to have specific for entry , we need to use connectivity-matrix[id], with choice depending if express/add/drop . We can use connectivity matrix construct for LTP to LTP path. This can be also the case we have a colored interface entering ADD/DROP block due to remote OT.

4) The we can put under LLCL the case for ADD/DROP , normal case, with OT not remote. WE have here a TTP-LTP relationship . The drawback of the usage of LLCL is that we can define TTP-LTP optical impairments attributes , only by single OT, not possible to have attributes description for "any" TTP to "any" LTP , only single TTP to "any" LTP. Also here, for specific case we can use "entry" of LLCL , augmenting +--rw local-link-connectivities | +--rw number-of-entries? uint16 | +--rw label-restrictions | | +--rw label-restriction* [index] | | +--rw restriction? enumeration | | +--rw index uint32 | | +--rw label-start | | | +--rw te-label | | | +--rw (technology)?

[ggalimba56]

Dear All,

I can not attend the today meeting, I’ll synch off line with Sergio.

Best Regards,

Gabriele

[http://www.cisco.com/swa/i/logo.gif]

Gabriele Galimberti Principal Engineer Cisco Photonics Srl Italy

via S.Maria Molgora, 48 C 20871 - Vimercate (MB) Italy www.cisco.com/global/IT/http://www.cisco.com/global/IT/

ggalimbe@cisco.commailto:ggalimbe@cisco.com Phone :+39 039 2091462 Mobile :+39 335 7481947 Fax :+39 039 2092049

From: sergiobelotti notifications@github.com Reply-To: younglee-ietf/ietf-optical-impairment-yang reply@reply.github.com Date: Thursday, 24 October 2019 at 15:39 To: younglee-ietf/ietf-optical-impairment-yang ietf-optical-impairment-yang@noreply.github.com Cc: Gabriele Galimberti ggalimbe@cisco.com, Comment comment@noreply.github.com Subject: Re: [younglee-ietf/ietf-optical-impairment-yang] Modeling of optical impairments for ROADMs (#9)

Hi Esther, I have some comments in the proposal, I'm sorry to have had no time to put direcly encoding.

1. Type-variety usage for ROADM is not what is proposed in the optical impairments for ROADM nodes since every parameters cannot be linke to a type of ROADM technology and equipement but can vary form ROADM to ROADM and so must be explicitly represented .
2. Grouping roadm-attributes is fine but my understanding was to have a parameter value non dependent of element , so I would delete list related to element (for express, add and drop E.g. for express list express-elements { key "elt-index"; description "defines the different crossed elements in drop path"; leaf elt-index { type uint16; description "ordered list of Index of roadm element"; } uses roadm-detailed-element;
3. You put all the structure of roadm-attributes under te-node-attribute: I think we should use connectivity matrix and LLCL . augment "/nw:networks/nw:network/nw:node/tet:te/"
   • "tet:te-node-attributes/tet:connectivity-matrices/" { when "/nw:networks/nw:network/nw:network-types" +"/tet:te-topology/optical-imp-topo:optical-impairment-topology" { description "This augment is only valid for Optical Impairment."; } description "Optical Node augmentation for impairment data."; container ROADM-attributes { config false; description "ROADM attributes"; uses roadm-attributes; } }

When you use "connectivity-matrices" you match with the requirement of scalability since these attrubutes are valid for any entry, as required.

For particular case in which we need to have specific for entry , we need to use connectivity-matrix[id], with choice depending if express/add/drop . We can use connectivity matrix construct for LTP to LTP path. This can be also the case we have a colored interface entering ADD/DROP block due to remote OT.

1. The we can put under LLCL the case for ADD/DROP , normal case, with OT not remote. WE have here a TTP-LTP relationship . The drawback of the usage of LLCL is that we can define TTP-LTP optical impairments attributes , only by single OT, not possible to have attributes description for "any" TTP to "any" LTP , only single TTP to "any" LTP. Also here, for specific case we can use "entry" of LLCL , augmenting +--rw local-link-connectivities | +--rw number-of-entries? uint16 | +--rw label-restrictions | | +--rw label-restriction* [index] | | +--rw restriction? enumeration | | +--rw index uint32 | | +--rw label-start | | | +--rw te-label | | | +--rw (technology)?

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/younglee-ietf/ietf-optical-impairment-yang/issues/9?email_source=notifications&email_token=ADQWFMEVLUBV5IEKYNEXBZDQQGQRXA5CNFSM4HPHWILKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECFB5MY#issuecomment-545922739, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADQWFME2OXIE3HRJ5EE5XA3QQGQRXANCNFSM4HPHWILA.

[sergiobelotti]

We have uploaded a new version of model for optical impairments parameters for ROADM node. ROADM attributes_IETF_v2-311019.pptx

[sergiobelotti]

New version of slides about the model for optical impairments parameters for ROADM node ROADM attributes_IETF_v3-b.pptx

[ggrammel]

ROADM.attributes_IETF_v3-c.pptx from GNPy (with some edits related to auto-design for brevity): ROADMs existing parameters:

field	type	description
target_pch_out_db	(number)	This is the default value
		Roadm/params/target_pch_out_db if no value
		is given in the Roadm element in the
		topology input description.
		This default value is ignored if a
		params/target_pch_out_db value is input in
		the topology for a given ROADM.
add_drop_osnr	(number)	OSNR contribution from the add/drop ports
restrictions | (dict of | If non-empty, keys preamp_variety_list
	strings)	and booster_variety_list represent
		list of type_variety amplifiers which
		are allowed for auto-design within ROADM's
		line degrees.
		If no booster should be placed on a degree,
		insert a Fused node on the degree
		output.

Additionally but not necessarily linked to a particular ROADM: The SpectralInformation object defines a spectrum of N identical carriers. While the code libraries allow for different carriers and power levels, the current user parametrization only allows one carrier type and one power/channel definition.

field	type	description
f_min,	(number)	In Hz. Carrier min max excursion.
f_max
baud_rate	(number)	In Hz. Simulated baud rate.
spacing	(number)	In Hz. Carrier spacing.
roll_off	(number)	Not yet used.
tx_osnr	(number)	In dB. OSNR out from transponder.
power_dbm	(number)	Reference channel power. In gain mode
		(see spans/power_mode = false), all gain
		settings are offset w/r/t this reference
		power.
sys_margins	(number)	In dB. Added margin on min required
		transceiver OSNR.

[sergiobelotti]

Hi Gert, I put also Colin in cc, to be sure he can receive it.

Thanks Sergio

From: Gert Grammel notifications@github.com Sent: Wednesday, January 15, 2020 2:01 PM To: ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang draft-ietf-ccamp-optical-impairment-topology-yang@noreply.github.com Cc: Belotti, Sergio (Nokia - IT/Vimercate) sergio.belotti@nokia.com; Comment comment@noreply.github.com Subject: Re: [ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang] Modeling of optical impairments for ROADMs (#9)

from GNPy (with small edits related to auto-design for brevity): ROADMs existing parameters: field type description target_pch_out_db (number) This is the default value Roadm/params/target_pch_out_db if no value is given in the Roadm element in the topology input description. This default value is ignored if a params/target_pch_out_db value is input in the topology for a given ROADM. add_drop_osnr (number) OSNR contribution from the add/drop ports restrictions (dict of If non-empty, keys preamp_variety_list strings) and booster_variety_list represent list of type_variety amplifiers which are allowed for auto-design within ROADM's line degrees. If no booster should be placed on a degree, insert a Fused node on the degree output.

Additionally: The SpectralInformation object defines a spectrum of N identical carriers. While the code libraries allow for different carriers and power levels, the current user parametrization only allows one carrier type and one power/channel definition. field type description f_min, (number) In Hz. Carrier min max excursion. f_max baud_rate (number) In Hz. Simulated baud rate. spacing (number) In Hz. Carrier spacing. roll_off (number) Not yet used. tx_osnr (number) In dB. OSNR out from transponder. power_dbm (number) Reference channel power. In gain mode (see spans/power_mode = false), all gain settings are offset w/r/t this reference power. In power mode, it is the reference power for Spans/delta_power_range_db. For example, if delta_power_range_db = [0,0,0], the same power=power_dbm is launched in every spans. The network design is performed with the power_dbm value: even if a power sweep is defined (see after) the design is not repeated. power_range_db (number) Power sweep excursion around power_dbm. It is not the min and max channel power values! The reference power becomes: power_range_db + power_dbm. sys_margins (number) In dB. Added margin on min required transceiver OSNR.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/9?email_source=notifications&email_token=ADCABXCTWJYW44LM3EQ3HADQ54CHLA5CNFSM4HPHWILKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJAHKIY#issuecomment-574649635, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADCABXDSUQQC4RGFQ6MZRR3Q54CHLANCNFSM4HPHWILA.

[ggrammel]

No problem, I am also trying to edit the slides. How did you upload them?

Gert

From: sergiobelotti notifications@github.com Reply-To: ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang reply@reply.github.com Date: Wednesday, January 15, 2020 at 14:05 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, Comment comment@noreply.github.com Subject: Re: [ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang] Modeling of optical impairments for ROADMs (#9)

Hi Gert, I put also Colin in cc, to be sure he can receive it.

Thanks Sergio

From: Gert Grammel notifications@github.com Sent: Wednesday, January 15, 2020 2:01 PM To: ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang draft-ietf-ccamp-optical-impairment-topology-yang@noreply.github.com Cc: Belotti, Sergio (Nokia - IT/Vimercate) sergio.belotti@nokia.com; Comment comment@noreply.github.com Subject: Re: [ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang] Modeling of optical impairments for ROADMs (#9)

from GNPy (with small edits related to auto-design for brevity): ROADMs existing parameters: field type description target_pch_out_db (number) This is the default value Roadm/params/target_pch_out_db if no value is given in the Roadm element in the topology input description. This default value is ignored if a params/target_pch_out_db value is input in the topology for a given ROADM. add_drop_osnr (number) OSNR contribution from the add/drop ports restrictions (dict of If non-empty, keys preamp_variety_list strings) and booster_variety_list represent list of type_variety amplifiers which are allowed for auto-design within ROADM's line degrees. If no booster should be placed on a degree, insert a Fused node on the degree output.

Additionally: The SpectralInformation object defines a spectrum of N identical carriers. While the code libraries allow for different carriers and power levels, the current user parametrization only allows one carrier type and one power/channel definition. field type description f_min, (number) In Hz. Carrier min max excursion. f_max baud_rate (number) In Hz. Simulated baud rate. spacing (number) In Hz. Carrier spacing. roll_off (number) Not yet used. tx_osnr (number) In dB. OSNR out from transponder. power_dbm (number) Reference channel power. In gain mode (see spans/power_mode = false), all gain settings are offset w/r/t this reference power. In power mode, it is the reference power for Spans/delta_power_range_db. For example, if delta_power_range_db = [0,0,0], the same power=power_dbm is launched in every spans. The network design is performed with the power_dbm value: even if a power sweep is defined (see after) the design is not repeated. power_range_db (number) Power sweep excursion around power_dbm. It is not the min and max channel power values! The reference power becomes: power_range_db + power_dbm. sys_margins (number) In dB. Added margin on min required transceiver OSNR.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/9?email_source=notifications&email_token=ADCABXCTWJYW44LM3EQ3HADQ54CHLA5CNFSM4HPHWILKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJAHKIY#issuecomment-574649635, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADCABXDSUQQC4RGFQ6MZRR3Q54CHLANCNFSM4HPHWILA.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/9?email_source=notifications&email_token=ADTQOVH6KAEUA7JIHBUWBILQ54CYPA5CNFSM4HPHWILKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJAHWCI#issuecomment-574651145, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADTQOVDUF7X7DTMLEZVDLELQ54CYPANCNFSM4HPHWILA.

[sergiobelotti]

Gert, In the bottom part of any rectangle for the comment there is the bottom for the upload of the document. You need first to sign in.

Cheers Sergio

From: Gert Grammel notifications@github.com Sent: Wednesday, January 15, 2020 2:06 PM To: ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang draft-ietf-ccamp-optical-impairment-topology-yang@noreply.github.com Cc: Belotti, Sergio (Nokia - IT/Vimercate) sergio.belotti@nokia.com; Comment comment@noreply.github.com Subject: Re: [ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang] Modeling of optical impairments for ROADMs (#9)

No problem, I am also trying to edit the slides. How did you upload them?

Gert

From: sergiobelotti notifications@github.com<mailto:notifications@github.com> Reply-To: ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang reply@reply.github.com<mailto:reply@reply.github.com> Date: Wednesday, January 15, 2020 at 14:05 To: ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang draft-ietf-ccamp-optical-impairment-topology-yang@noreply.github.com<mailto:draft-ietf-ccamp-optical-impairment-topology-yang@noreply.github.com> Cc: Gert Grammel ggrammel@juniper.net<mailto:ggrammel@juniper.net>, Comment comment@noreply.github.com<mailto:comment@noreply.github.com> Subject: Re: [ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang] Modeling of optical impairments for ROADMs (#9)

Hi Gert, I put also Colin in cc, to be sure he can receive it.

Thanks Sergio

From: Gert Grammel notifications@github.com<mailto:notifications@github.com> Sent: Wednesday, January 15, 2020 2:01 PM To: ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang draft-ietf-ccamp-optical-impairment-topology-yang@noreply.github.com<mailto:draft-ietf-ccamp-optical-impairment-topology-yang@noreply.github.com> Cc: Belotti, Sergio (Nokia - IT/Vimercate) sergio.belotti@nokia.com<mailto:sergio.belotti@nokia.com>; Comment comment@noreply.github.com<mailto:comment@noreply.github.com> Subject: Re: [ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang] Modeling of optical impairments for ROADMs (#9)

from GNPy (with small edits related to auto-design for brevity): ROADMs existing parameters: field type description target_pch_out_db (number) This is the default value Roadm/params/target_pch_out_db if no value is given in the Roadm element in the topology input description. This default value is ignored if a params/target_pch_out_db value is input in the topology for a given ROADM. add_drop_osnr (number) OSNR contribution from the add/drop ports restrictions (dict of If non-empty, keys preamp_variety_list strings) and booster_variety_list represent list of type_variety amplifiers which are allowed for auto-design within ROADM's line degrees. If no booster should be placed on a degree, insert a Fused node on the degree output.

Additionally: The SpectralInformation object defines a spectrum of N identical carriers. While the code libraries allow for different carriers and power levels, the current user parametrization only allows one carrier type and one power/channel definition. field type description f_min, (number) In Hz. Carrier min max excursion. f_max baud_rate (number) In Hz. Simulated baud rate. spacing (number) In Hz. Carrier spacing. roll_off (number) Not yet used. tx_osnr (number) In dB. OSNR out from transponder. power_dbm (number) Reference channel power. In gain mode (see spans/power_mode = false), all gain settings are offset w/r/t this reference power. In power mode, it is the reference power for Spans/delta_power_range_db. For example, if delta_power_range_db = [0,0,0], the same power=power_dbm is launched in every spans. The network design is performed with the power_dbm value: even if a power sweep is defined (see after) the design is not repeated. power_range_db (number) Power sweep excursion around power_dbm. It is not the min and max channel power values! The reference power becomes: power_range_db + power_dbm. sys_margins (number) In dB. Added margin on min required transceiver OSNR.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/9?email_source=notifications&email_token=ADCABXCTWJYW44LM3EQ3HADQ54CHLA5CNFSM4HPHWILKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJAHKIY#issuecomment-574649635, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADCABXDSUQQC4RGFQ6MZRR3Q54CHLANCNFSM4HPHWILA.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/9?email_source=notifications&email_token=ADTQOVH6KAEUA7JIHBUWBILQ54CYPA5CNFSM4HPHWILKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJAHWCI#issuecomment-574651145, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADTQOVDUF7X7DTMLEZVDLELQ54CYPANCNFSM4HPHWILA.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/9?email_source=notifications&email_token=ADCABXF2YLXB2Z7EYAYRWZLQ54C4FA5CNFSM4HPHWILKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJAHYQQ#issuecomment-574651458, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADCABXF3HCKGT6P5CEYSXFLQ54C4FANCNFSM4HPHWILA.

[sergiobelotti]

As we agreed a couple of weekly calls ago, Esther , Italo and myself had an analysis of the model and we propose two options for ROADM model. Two assumptions have been put at the options: 1) The usage of connectivity matrix also for TTP-LTP and LTP-TTP case when no specific attributes/info need to be reported in the Local Link Connectivity List (LLCL) structure: this assumption is for the case in which any TTP-LTP (or viceversa) have the same attributes , no differentiation (node scope and not only TTP scope) . This case is no addressable with LLCL since the structure is "per TTP" specific. 2) We assume the existence of TTP even in the case the transponder is unequipped (maybe a new attribute will be added to distinguish the case . To be discussed with topology model authors) Option 1:

  augment /nw:networks/nw:network/nw:node/te:te/te:te-node-attributes/te:connectivity-matrices:
    +--ro ROADM-attributes
       +--ro express   // LTP->LTP [when no more specific info in CM entry]
       |  +--ro pmd?              decimal64
       |  +--ro <...>
       +--ro add       // TTP->LTP [when no more specific info in (LLCL) – to be checked]
       |  +--ro pmd?              decimal64
       |  +--ro <...>
       +--ro drop      // LTP->TTP [when no more specific info in (LLCL) – to be checked]
          +--ro pmd?              decimal64
          +--ro <...>

The CM provides all the information which is needed to describe the optical impairments in case of an “Integrated ROADM with homogeneous add/drop”.

However, the interpretation of CM values as being the default for TTP->LTP add/drop paths needs to be checked with TE-Topology authors.

In case of an “Integrated ROADM with heterogeneous add/drop” case, the optical impairments of the add/drop paths can be specified in the LLCL of each TTP:

  augment /nw:networks/nw:network/nw:node/te:te/te:tunnel-termination-point/te:local-link-connectivities:
    +--ro ROADM-attributes
       +--ro add       // TTP->LTP [when no more specific info in LLCL entry]
       |  +--ro pmd?              decimal64
       |  +--ro <...>
       +--ro drop      // LTP->TTP [when no more specific info in LLCL entry]
          +--ro pmd?              decimal64
          +--ro <...>

This information is not provided by the TTPs used within an “Integrated ROADM with homogeneous add/drop”, since the values provided by the CM are sufficient.

This option seems more straightforward from modelling point of view.

However, since the LLCL is defined for each TTP (and not for the node), the same set of attributes need to be reported multiple times in all the TTPs attached to the same add/drop block.

Option 2:

  augment /nw:networks/te:te:
    +--ro globals
       +--ro named-add-paths
       |  +--ro named-add-path* [name]
       |  |  +--ro name              string
       |  |  +--ro pmd?              decimal64
       |  |  +--ro <...>
       +--ro named-drop-paths
          +--ro named-drop-path* [name]
             +--ro name              string
             +--ro pmd?              decimal64
             +--ro <...>

The named-add-paths and named-drop-paths could be managed in the same way as the named-path-constraint in the te-tunnel or the named-bandwidth-profiles in the ietf-eth-tran-service model:

  augment /nw:networks/nw:network/nw:node/te:te/te:te-node-attributes/te:connectivity-matrices:
    +--ro ROADM-attributes
       +--ro express   // LTP->LTP [when no more specific info in CM entry]
       |  +--ro pmd?              decimal64
       |  +--ro <...>
       +--ro add       // TTP->LTP [when no more specific info in (LLCL) – to be checked]
       |  +--ro (style)?
       |     +--:(named)
       |     |  +--ro add-path-name?    leafref
       |     +--:(value)
       |        +--ro pmd?              decimal64
       |        +--ro <...>
       +--ro drop           // LTP->TTP [when no more specific info in (LLCL) – to be checked]
          +--ro (style)?
             +--:(named)
             |  +--ro drop-path-name?    leafref
             +--:(value)
                +--ro pmd?              decimal64
                +--ro <...>

Integrated ROADM with homogeneous add/drop would likely use the (value) choice, as in option 1.

Integrated ROADM with heterogeneous add/drop could use any choice (if a default is desired) or no choice (no default add/drop impairments are specified so each TTP should provide the information in its LLCL). The default value may be useful if almost all the add/drop are homogeneous and few heterogeneous exceptions.

We can discuss whether it makes sense to keep this flexibility or to keep only the (value) choice, as in option 1

  augment /nw:networks/nw:network/nw:node/te:te/te:tunnel-termination-point/te:local-link-connectivities:
    +--ro ROADM-attributes
       +--ro add       // TTP->LTP [when no more specific info in LLCL entry]
       |  +--ro (style)?
       |     +--:(named)
       |     |  +--ro add-path-name?    leafref
       |     +--:(value)
       |        +--ro pmd?              decimal64
       |        +--ro <...>
       +--ro drop           // LTP->TTP [when no more specific info in LLCL entry]
          +--ro (style)?
             +--:(named)
             |  +--ro drop-path-name?    leafref
             +--:(value)
                +--ro pmd?              decimal64
                +--ro <...>

Integrated ROADM with homogeneous add/drop would likely not use any choice, since the values provided by the CM are sufficient.

Integrated ROADM with heterogeneous add/drop would likely use (named) choice such that TTPs that are attached to the same add/drop block will point to the same named-add-path and named-drop-path, without reporting multiple times the same set of attributes.

We can discuss whether it makes sense to keep this flexibility or to keep only the (named) choice attached a slide that can easy the understanding of connectivity matrix vs. LLCL. dcm-llcl-rules v00.pptx

Esther, Italo, Sergio

[sergiobelotti]

Actions points after the weekly call held Thursday January 23rd : AP1 Sergio/Italo : to verify with TEAS topology model authors the validity to use connectivity matrix to create a default set of attrubutes for add/drop paths (TTP-LTP and LTP-TTP ) AP2 ALL: Analyze the second assumption regarding equipped/unequipped and his implication for the case of remote transponder (alien wavelength). Is possible to suppose TTP existence even in the case the transponder is remote from ROADM? Or a new virtual TTP entity has to be considered? AP3 ALL: provide a preference with respect the two proposed options.

[ggrammel]

2020-01-27-Model.pptx To better understand what has been proposed I took a stab on putting the model in ppt for discussion. It depicts the current (unaltered) TE-topology model, the proposed one (changing CM and introducing vTTP) as well as another option that would augment the original model. Italo and I will take the occasion of being at the same Meeting to discuss in person later the week to seek common understanding.

[sergiobelotti]

Slide 11 of the package proposed by Gert , describe possible issues with the proposal on the table.

-issue 1 :It us unclear why a CM would need to be homogeneous only, as it has specific entries for each possible connection. Comment: Since the optical impairments for all the express paths (between any degree) are the same, we have modelled them directly under container connectivity-matrices, following the guidelines of section 5.6 of draft-ietf-teas-yang-te-topo-22. With the assumption 1, we also have modeled the case of ADD/DROP path in case of homogeneous case under connectivity-matrices . This has perfectly sense exploiting the double capability of connectivity matrix to separate attributes for entry or for default , under connectivity-matrices.

issue 2- draft-ietf-teas-yang-te-topo-22 connectivity matrix is defined as LTP only matrix. Changing it to cover LTP and TTP is a change of the base model Comment: this is not an issue since as contributors of teas-topology draft, Italo and myself knows that very well, and this point is under discussion with the other authors/contributors of the draft . It would not be a changing in the model but in the usage of a defined structure.

issue 3- In case of above change, it is unclear if LLCL cannot/can/must exist and which cases would be covered since LLCL seems to be merged now with CM Comment: absolutely no, the proposal clearly show that LLCL is used for add-drop case for not homogeneous case . Please check the description.

issue 4 : draft-ietf-teas-yang-te-topo-22 considers a TE- tunnel as association between two TTPs, whereby a single TTP is associated to one Tunnel only. However the proposal introduces Virtual Tunnel Termination Points (VTTP) at intermediate points. Those VTTPs would therefore segment the concept of Tunnel and associating a single VTTP to two tunnels. Comment: you already jumped in to conclusion about the discussion on unequipped TTP. There were different opinion about the need to introduce a new entity that you named VTTP or to use e.g. an attribute to distinguish between equipped and unequipped case. But even in the case this entity would exist, what you describe would be a case of multi-domain tunnel, with VTTP that would be an inbound hand-off , since the source of the tunnel would outside on the remote TTP. But I do not see an issue here , it is a scenarios already addressed in the tutorial document.

[ggrammel]

Thanks for crosschecking the modeling aspect. Few more comments on the issues discussed:

issue 1: The point raised is that it was a design choice, not a design necessity to have a single set of impairments attached to the whole matrix. Impairments can well be attached to the entries of the CM. If so, impairments for unequipped add-drop can be conveniently covered in the CM.

Issue 2: Let's try to go for an informed discussion with the options on the table for a fair assessment. Are the authors of draft-ietf-teas-yang-te-topo-22 aware that alternative proposals that exist?

Issue-3: If we take the assumption that the CM contains impairments for express path as a default, then in practice LLCL must exist to describe the impairments of the add-drop path. This in turn requires the presence of a vTTP for unequipped wavelength because if no (v)TTP exists, LLCL doesn't exist either.

issue 4: The point is applying the topo-22 concepts (3.9. TE Path) to the proposal at hand: "TE path is an ordered list of TE links and/or TE nodes on the TE topology graph, inter-connecting a pair of TTPs to be taken by a potential connection." In the proposed model, a vTTP would be necessary to mark an unequipped port as a (v)TTP so that it can be included into the LLCL and therefore can have add/drop impairments attached. However by doing so (using the current topo-22 text) a (v)TTP would be a tunnel end-point (otherwise it would have been named LTP). (Please add a pointer to "tutorial document" was it "ROADM.attributes_IETF_v3-c.pptx"?

The "alternative proposal" in the same deck aims to avoid the issues aiming to stay within the topo-22 concepts as much as possible.

[sergiobelotti]

Thanks for crosschecking the modeling aspect. Few more comments on the issues discussed:

issue 1: The point raised is that it was a design choice, not a design necessity to have a single set of impairments attached to the whole matrix. Impairments can well be attached to the entries of the CM. If so, impairments for unequipped add-drop can be conveniently covered in the CM. SB> It seems you miss some points of the model: it is an advantage to have the possibility to use connectivity matrix as reference for default attribute definition when no need to specify per entry is needed. Model has been created on purpose to give the possibility to avoid burden to configure attribute per entry when that can be done as default. Btw when you say "impairments for unequipped add-drop can be conveniently covered in the CM." you assume exactly what you put as issue in point 2, so the usage of CM for add-drop case implying TTP-LTP.

Issue 2: Let's try to go for an informed discussion with the options on the table for a fair assessment. Are the authors of draft-ietf-teas-yang-te-topo-22 aware that alternative proposals that exist?

SB> Actions points after the weekly call held Thursday January 23rd : AP1 Sergio/Italo : to verify with TEAS topology model authors the validity to use connectivity matrix to create a default set of attrubutes for add/drop paths (TTP-LTP and LTP-TTP ) AP2 ALL: Analyze the second assumption regarding equipped/unequipped and his implication for the case of remote transponder (alien wavelength). Is possible to suppose TTP existence even in the case the transponder is remote from ROADM? Or a new virtual TTP entity has to be considered? AP3 ALL: provide a preference with respect the two proposed options.

do you see any AP related to alternative proposal ? We just followed what AP 1 reported. No definite answer yet for the moment.

Issue-3: If we take the assumption that the CM contains impairments for express path as a default, then in practice LLCL must exist to describe the impairments of the add-drop path. This in turn requires the presence of a vTTP for unequipped wavelength because if no (v)TTP exists, LLCL doesn't exist either. SB> our assumption is different please read carefully the proposal: CM is for both express and homogeneous AD/drop case with assumption 1 reported in the proposal. As we discussed last time the introducing of a new entity is not mandatory, and some negative comments were raised during the meeting. For unequipped you could simply consider the option to use TTP as it is with specific attribute . This is not good for remote case . But in fact AP2 was related to the need to analyze different possibilities. AP2 ALL: Analyze the second assumption regarding equipped/unequipped and his implication for the case of remote transponder (alien wavelength). Is possible to suppose TTP existence even in the case the transponder is remote from ROADM? Or a new virtual TTP entity has to be considered?

issue 4: The point is applying the topo-22 concepts (3.9. TE Path) to the proposal at hand: "TE path is an ordered list of TE links and/or TE nodes on the TE topology graph, inter-connecting a pair of TTPs to be taken by a potential connection." In the proposed model, a vTTP would be necessary to mark an unequipped port as a (v)TTP so that it can be included into the LLCL and therefore can have add/drop impairments attached. However by doing so (using the current topo-22 text) a (v)TTP would be a tunnel end-point (otherwise it would have been named LTP). (Please add a pointer to "tutorial document" was it "ROADM.attributes_IETF_v3-c.pptx"?

SB> Again , see answer above and AP 2. The scenario of AP 2 need to be analyzed and the case of unequipped and remote transponder is different. For the later , the termination point would be clearly not on the ROADM add-drop interface and so the TE path definition would be not applicable at the add/drop path .
The "alternative proposal" in the same deck aims to avoid the issues aiming to stay within the topo-22 concepts as much as possible.

SB> good to discuss that. My first reaction is that it seems you propose to have impairments attributes for any path for any LTP-LTP and TTP-LTP ..so long list of values .........

[ggrammel]

My suggestion is to keep procedural and modeling issues separate. Perhaps I misunderstood your comment related to issue 2. The way your comment read to me was "the "technical issue" is not an issue because "procedure" to include it in the te-draft already started and we do not further need to discuss the "technical issue". Perhaps that's not the intended message. My point was to discuss the technical options on technical merits. Maybe that read different on your end, but it was not intended as a blame.

About your last point: There is a list of impairment definitions (the impairment-list on the right) attached to the TE-node. In case of express path and two add/drop modules (with different impairments) the length of that list is 3 whereby each leaf holds the set of proper "tbd" impairments. Entries in CM and LLCL simply reference to one entry in the list "impairment-id" shown on the left of p.16+17.

[sergiobelotti]

@ggrammel I agree , procedural and modeling issues need to be kept separate. About issue 2, sorry not to be clear, I'd just said that when we contacted authors of teas-topology , an alternative proposal was not yet on the table, no problem to do that now if you prefer involve them in the discussion. My personal opinion, if I understood well your proposal, is that , while our first proposal would need a check with authors due to assumption 1 , on the usage of connectivity matrix when TTP-LTP was considered, your proposal does not touch any specific behavior of topology model and so theoretically can be discussed internally without problem. But again no problem to hear suggestion form authors as well for this alternative proposal.

@all About that, let me try to help our internal discussion trying to summarize advantages of both alternative.

First my summary of your proposal . The proposal has a list of "named" optical impairments (similar to option 2 of first proposal) , and in any entry of both connectivity matrix (CM) and local link connectivity list (LLCL) there is a pointer of named optical impairment package of attributes related to this entry.

Advantages of this solution are in my view:

• independently of type of connection point (LTP, TTP or if introduced V-TTP) no change in model behavior

Disadvantages:

• there is no default defined and you need to setup the pointer per entry , not exploiting the power to define default that in case of homogeneous architecture for add-drop path and always for express path could provide less complexity in the model (no per-entry setup even if only for pointer)

First proposal advantage:

• advantage: the model introduce a default both for express path and for add-drop case, avoiding , for add-drop case , to tied to the model constrain of defining TTP-LTP atribute per TTP, that in case of homogeneous case is limiting .
• disadvantages: imply verification of the possibility of the usage of connectivity matrix also for TTP-LTP case

This a first attempt , feel free to comment further . That would easy our next call on Thursday.

[ggrammel]

@sergiobelotti thanks for the comments. Indeed the aim of the "alternative proposal" aims to stay within the topo-22 concepts as much as possible.

@All about "no default defined": perhaps there are some implementations where such default is useful. To address them, a default-impairment-id could be added. This could be done either on a per-node basis or a per-matrix basis. A per-node default might look like e.g.:

+--rw te-node-attributes ...........
+--rw default-impairment-id uint32
+--rw impairment-list* [id] 
| | +--rw impairment-id uint32 
| | +--ro crosstalk uint32
| | +--ro noise dbm-t
| | +-- ........... 

or in case of matrix based:

     +--rw connectivity-matrices
        |  +--rw default-impairment-id uint32
        ...........
        |  +--rw connectivity-matrix* [id]
        ...........

[italobusi]

Regarding:

AP1 Sergio/Italo : to verify with TEAS topology model authors the validity to use connectivity matrix to create a default set of attrubutes for add/drop paths (TTP-LTP and LTP-TTP )

We have just checked with Igor and he agrees that the current te-topology lacks a per-node default for any TTP-LTP path. He disagrees on using the CM and suggests to add a new container, such as:

     +--rw te-node-attributes
     |  ...........
     |  +--rw connectivity-matrices
     |  ........... // default per -node CM (between any LTP and any LTP)
/* To be added (START) */
     |  +--rw default-ttp-ltp-connectivities
     |  ........... // default per-node (between any TTP and any LTP)
/* To be added (END) */
     +--rw tunnel-termination-point* [tunnel-tp-id]
        +--rw tunnel-tp-id               binary
        ...........
        +--rw local-link-connectivities
        ........... // default per-TTP (between this TTP (tunnel-tp-id) and any LTP)
        |  +--rw local-link-connectivity* [link-tp-ref]
        |     +--rw link-tp-ref                leafref
        |     ........... // path between this TTP (tunnel-tp-id) and this LTP (link-tp-ref)

[ggrammel]

Hi Italo,

/ To be added (START) /

 |  +--rw default-ttp-ltp-connectivities

 |  ........... // default per-node (between any TTP and any LTP)

/ To be added (END) /

I am not sure if I understood the proposal correctly. Is default-ttp-ltp-connectivities a default-connectivity or rather a default impairment per LLCL? With the same view, is TTP to LTP connectivity the same as an LLC or is it something different?

Gert

From: italobusi notifications@github.com Reply-To: ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang reply@reply.github.com Date: Tuesday, February 4, 2020 at 18:57 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] Modeling of optical impairments for ROADMs (#9)

Regarding:

AP1 Sergio/Italo : to verify with TEAS topology model authors the validity to use connectivity matrix to create a default set of attrubutes for add/drop paths (TTP-LTP and LTP-TTP )

We have just checked with Igor and he agrees that the current te-topology lacks a per-node default for any TTP-LTP path. He disagrees on using the CM and suggests to add a new container, such as:

 +--rw te-node-attributes

 |  ...........

 |  +--rw connectivity-matrices

 |  ........... // default per -node CM (between any LTP and any LTP)

/ To be added (START) /

 |  +--rw default-ttp-ltp-connectivities

 |  ........... // default per-node (between any TTP and any LTP)

/ To be added (END) /

 +--rw tunnel-termination-point* [tunnel-tp-id]

    +--rw tunnel-tp-id               binary

    ...........

    +--rw local-link-connectivities

    ........... // default per-TTP (between this TTP (tunnel-tp-id) and any LTP)

    |  +--rw local-link-connectivity* [link-tp-ref]

    |     +--rw link-tp-ref                leafref

    |     ........... // path between this TTP (tunnel-tp-id) and this LTP (link-tp-ref)

— 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/9?email_source=notifications&email_token=ADTQOVH3WN6KWIUUR6Q4RM3RBGT7PA5CNFSM4HPHWILKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKYSUBY#issuecomment-582035975, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADTQOVFAJGH3LBSJB2DCKADRBGT7PANCNFSM4HPHWILA.

[ggrammel]

Updated model after our call 2020-02-06: 2020-02-06-Model.pptx

[italobusi]

From @EstherLerouzic @ggrammel @italobusi @sergiobelotti (2020-02-12)

This would be the YANG tree based on the discussion last week:

          +--rw te-node-attributes
          |  +--rw admin-status?            te-types:te-admin-status
/* ADD (Start) */
          |  +--ro path-impairment* [path-impairment-id]
          |  |  +--ro path-impairment-id    uint32
          |  |  +--ro (impairment-type)?
          |  |     +--:(roadm-express-path)
          |  |     |  +--ro roadm-express-path
          |  |     |  |  +--ro pmd?         decimal64
          |  |     |  |  ...........
          |  |     +--:(roadm-add-path)
          |  |     |  +--ro roadm-add-path
          |  |     |  |  +--ro pmd?         decimal64
          |  |     |  |  +--ro osnr?        type?            // NA to express-path
          |  |     |  |  +--ro psd-abs-min? type?            // NA to express-path and to drop-path
          |  |     |  |  ...........
          |  |     +--:(roadm-drop-path)
          |  |        +--ro roadm-drop-path
          |  |           +--ro pmd?         decimal64
          |  |           +--ro osnr?        type?            // NA to express-path
          |  |           ...........
/* ADD (End) */
          |  +--rw connectivity-matrices
          |  |  +--rw number-of-entries?     uint16
          |  |  ...........
          |  |  +--rw is-allowed?            boolean
          |  |  ...........
          |  |  +--ro path-properties
          |  |  |  ...........
/* ADD (Start) */
          |  |  +--ro path-impairments    leafref
/* ADD (End) */
          |  |  +--rw connectivity-matrix* [id]
          |  |     +--rw id                  uint32
          |  |     +--rw from
          |  |     |  +--rw tp-ref?               leafref
          |  |     |  ...........
          |  |     +--rw to
          |  |     |  +--rw tp-ref?               leafref
          |  |     |  ...........
          |  |     +--rw is-allowed?         boolean
          |  |     ...........
          |  |     +--ro path-properties
          |  |     |  ...........
/* ADD (Start) */
          |  |     +--ro path-impairments    leafref
/* ADD (End) */
          +--rw tunnel-termination-point* [tunnel-tp-id]
             +--rw tunnel-tp-id                           binary
             ...........
             +--rw local-link-connectivities
             |  +--rw number-of-entries?         uint16
             |  ...........
             |  +--rw is-allowed?                boolean
             |  ...........
             |  +--ro path-properties
             |  |  ...........
/* ADD (Start) */
             |  +--ro add-path-impairments       leafref
             |  +--ro drop-path-impairments      leafref
/* ADD (End) */
             |  +--rw local-link-connectivity* [link-tp-ref]
             |     +--rw link-tp-ref
             |     |       -> ../../../../../nt:termination-point/tp-id
             |     ...........
             |     +--rw is-allowed?           boolean
             |     ...........
             |     +--ro path-properties
             |     |  ...........
/* ADD (Start) */
             |     +--ro add-path-impairments      leafref
             |     +--ro drop-path-impairments     leafref
/* ADD (End) */

[sergiobelotti]

ROADM attributes_IETF_v7draft.pptx

attached new updated version of "ROADM attributes" with in particularly on slide 11 , examples of calculation and a summary table on the left.

[ggalimba56]

Thanks Sergio,

I think it is a good example. It would be nice to map (as an example) the values To the Yang models definition (of the metrics).

Best Regards,

Gabriele

P.S. also today I’ll connect very late to the meeting ☹

[http://www.cisco.com/swa/i/logo.gif]

Gabriele Galimberti Principal Engineer Cisco Photonics Srl Italy

via S.Maria Molgora, 48 C 20871 - Vimercate (MB) Italy www.cisco.com/global/IT/http://www.cisco.com/global/IT/

ggalimbe@cisco.commailto:ggalimbe@cisco.com Phone :+39 039 2091462 Mobile :+39 335 7481947 Fax :+39 039 2092049

From: sergiobelotti notifications@github.com Reply to: ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang reply@reply.github.com Date: Thursday, 20 February 2020 at 14:51 To: ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang draft-ietf-ccamp-optical-impairment-topology-yang@noreply.github.com Cc: Gabriele Galimberti ggalimbe@cisco.com, Comment comment@noreply.github.com Subject: Re: [ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang] Modeling of optical impairments for ROADMs (#9)

ROADM attributes_IETF_v7draft.pptxhttps://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/files/4231013/ROADM.attributes_IETF_v7draft.pptx

attached new updated version of "ROADM attributes" with in particularly on slide 11 , examples of calculation and a summary table on the left.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/9?email_source=notifications&email_token=ADQWFMABF6QQ4YIDZ24XVATRD2DFTA5CNFSM4HPHWILKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMN7Y2Q#issuecomment-589036650, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADQWFME4IRN6OWFWQIGS2NLRD2DFTANCNFSM4HPHWILA.

[sergiobelotti]

As required during last weekly call , attached the new version of Colin's slide, with slide 13 , including "definitions" of power attributes proposed . ROADM attributes_IETF_v8draft.pptx

[sergiobelotti]

https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/pull/28

The YANG model has been extended with the above pull request.