Re: [CCAMP] Webex meeting invitation: Optical Impairments - occurrence of week 40

[<[e-mail]>]

Hi,

We can't ignore the fact that, on the market, the term "ROADM" may refer to a device including or excluding OTs, depending on the context. Being more explicit may be a way to avoid this ambiguity between the optical switching block and the fully equipped device:
- OT-equipped / OT-unequipped ROADMs?
- OT-embedding / OT-less ROADMs?
- ROADMs with integrated OTs / ROADM without OTs?

Talk to you soon,

Julien

On 10/10/2019 12:40, Gert Grammel wrote:

Sergio,

 

See the response to Italo’s last email. We figured out that we have a mismatch in what the term “ROADM” is supposed to represent that needs to be clarified because this is causing a lot of confusion. For example when you write “… we never discussed the link between OT and ROADM as a transitional link or inter-layer lock” it suggests that a OT is separate from a ROADM (which is my understanding) but you may have thought it differently as pointed out in the first sentence.

At this point let’s sit down together and come up with a terminology that has the same meaning for everyone on the table.

I think there is no more progress to achieve by email here.

 

Thanks

 

Gert

 

 

 

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[e-mail]>
Date: Thursday, October 10, 2019 at 10:37

 

Gert,

“Layer transition can only happen in devices”

This is exactly what Italo is saying mentioning inter-layer lock construct or transitional-link, since TTP in topology model exactly represent potential adaptation/termination capability inside the node hosting TTP . No absolutely contradiction in what Italo said.

BTW I do not remind (and in fact not reporting in our minute) we never discussed the link between OT and ROADM as a transitional link or inter-layer lock.

 

Cheers

Sergio

 

From: Gert Grammel <[e-mail]>
Sent: Thursday, October 10, 2019 10:10 AM

 

Italo,

 

A Layer transition cannot be performed at a link. Layer transition can only happen in devices. The client layer link would correspond to a “wavelength” or “Media channel” (aka OCH), while the server layer TTP is related to a “Media Link” (aka OMS). A Transitional link is only a logical construct to connect two layers in a topology. If you happen to have access to G.872 (1/2017), check out “8.1 Media constructs” and fig 8-2 that show the Layer relationship. HTH

 

Best

 

Gert

 

From: Italo Busi <[e-mail]>
Date: Thursday, October 10, 2019 at 09:50

 

Gert,

 

The transitional link (as well as the inter-layer lock-id) models the layer transition between the grey client access links (client layer LTP) and the OT (server layer TTP).

 

As far as I have understood, there are no layer transitions between the OT and the add/drop box.

 

Italo

 

Italo Busi

Principal Optical Transport Network Research Engineer

Huawei Technologies Co., Ltd.

Tel : [phone]

Email : [e-mail]

 

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

 

From: Gert Grammel [mailto:[e-mail]]
Sent: mercoledì 9 ottobre 2019 23:27

 

Italo,

 

In our call we discussed an extension of  https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-teas-yang-te-topo-22__;!8WoA6RjC81c!QZ5vjOymZTtm_a_MEUBz4o1f_B88GQ_F2ZQ-sLAxVqd6gTLoNB_OuZkRauwcfLtP$" rel="nofollow">https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-22 to cover optical impairments. Please refer to figure 2 for a TE-Topology of a multilayer node. We also discussed that the link between ROADM and OT is a transitional link and that LLCL is a candidate to attach optical impairments to. However LLCL would refer to a construct that relates to the “server layer node” (reference to Fig. 2).

It appears we have different understanding of what a “(dis-) aggregated ROADM” would mean. My understanding is that an aggregated ROADM is a group of interconnected WSS, splitters, Mux and fiber components, represented as a single TE-node. A disaggregated ROADM would represent the same construct as a set of interconnected TE-nodes. In either case, the OT is interfacing the ROADM with an transitional link, in line with the current te-topo model.

Whether it is more adequate to attach internal impairments to the LLCL or a transitional link remains to be seen. We did not have a detailed discussion about this and should not immediately jump into conclusions. Given the view expressed above, it seems the only open issue is to where an impairment construct for drop ports need to be attached.

 

Regards

 

Gert

 

 

 

From: Italo Busi <[e-mail]>
Date: Wednesday, October 9, 2019 at 22:40

 

Hi Gert,

 

The LLCL does not report the link between the OT and the line but it is intended to abstract the TE attributes of the “add/drop path” within the ROADM, in case the ROADM (including the OT) is modelled as a single TE node

 

My understanding is that during the call we have agreed that irrespectively on whether the ROADM architecture is integrated or disaggregated, the controller can abstract the ROADM as a single TE node and to focus, in the first phase, to the cases where the OT and the add/drop box are under the same controller’s and the link between them is not exposed

 

I agree with you that any solution that allows exposing the link between the OT and the add/drop box as an inter-domain link could be used also to expose this link as an intra-domain link. The difference between intra-domain and inter-domain links is just a set of attributes (e.g., the plug-id) which are used for multi-domain topology discovery.

In this case, the ROADM cannot be exposed as a single TE node but at least as two TE nodes with one or more TE links in between.

However, exposing these TE links as intra-domain, although possible, will not be mandatory and the solution identified in the first phase will be still applicable if the intra-domain link between the OT and the add/drop box is not exposed

 

In other words, the scenario where the link between the OT and the add/drop box is exposed as a TE link can be addressed in a second phase as an extensions to the solution developed in the first phase

 

My 2 cents

 

Italo

 

Italo Busi

Principal Optical Transport Network Research Engineer

Huawei Technologies Co., Ltd.

Tel : [phone]

Email : [e-mail]

 

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

 

From: Gert Grammel [mailto:[e-mail]]
Sent: venerdì 4 ottobre 2019 19:43

 

Sergio, Italo,

 

Thank you for the summary. Two clarifications:

• In the report it is stated that the LLCL is a Link between OT and the line (crossing ADD-DROP block) and is a candidate to be used to attach the impairment parameters on this. However further down it is said a domain controller would not expose it (which basically creates an aggregated model). Since the preference was for a disaggregated model, there has been no final conclusion on what exactly to expose and what not.
• The group also discussed that add/drop would only need to be exposed in case of a domain Boundary. My intervention aimed to clarify that this there are other use cases beyond domain boundaries that benefit from exposing such link between Add/Drop and OT. Given the preference expressed by the group for a disaggregated model, it seems pre-mature to state “In the first phase, we will consider the case where it is not exposed.”

 

Gert

 

 

 

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[e-mail]>
Date: Friday, October 4, 2019 at 18:16

 

Hi all,

 

Related to the meeting on Wednesday October 2^nd ,

Italo and myself put together some notes (attached), in the view to have common understanding of the topics been touched and so progressing of discussion for next meeting.

 

Please look at the attached word and provide your comments if any to complete the summary.

 

Thanks

Italo and Sergio

 

 

Sergio Belotti

Senior System Engineer and Standardization Architect

IP/Optical Networks, Optics BU

Nokia

M: [phone]

Via Energy Park, 20871 Vimercate (MB) , Italy

[e-mail]

 

 

 

From: CCAMP <[e-mail]> On Behalf Of Gabriele Maria Galimberti (ggalimbe)
Sent: Monday, September 30, 2019 3:12 PM

 

Thanks a lot Daniele,

 

Best regards,

 

Gabriele

 

Gabriele Galimberti Principal Engineer Cisco Photonics Srl Italy   via S.Maria Molgora, 48 C 20871 - Vimercate (MB) Italy https://urldefense.com/v3/__http:/www.cisco.com/global/IT/__;!8WoA6RjC81c!VNA3Ua3wQopzX2hjSjg5KbXc0x3eqKz0HGmKOPaQHfT2OS-mbk8EbFwU4AVRSscg$" rel="nofollow">www.cisco.com/global/IT/   [e-mail] Phone :[phone] Mobile :[phone] Fax :[phone]

 

 

From: CCAMP <[e-mail]> on behalf of Daniele Ceccarelli <daniele.ceccarelli=[e-mail]>
Date: Monday, 30 September 2019 at 14:08

 

Hi WG,

 

ONLY FOR THIS WEEK the Optical Impairments call we be moved to Wednesday 2^nd instead of usual Thursday slot.

Starting from next week we’ll be back to Thursday as usual.

 

Thanks,

 

Daniele 

 

From: CCAMP <[e-mail]> On Behalf Of CCAMP Working Group
Sent: den 30 september 2019 14:05
To: [e-mail]
Subject: [CCAMP] Webex meeting invitation: Optical Impairments - occurrence of week 40

 

CCAMP Working Group invites you to join this Webex meeting.     Meeting number (access code): 644 305 032   Meeting password: tyqTNm55     Wednesday, October 2, 2019 8:00 am  |  (UTC-05:00) Eastern Time (US & Canada)  |  1 hr     https://urldefense.com/v3/__https:/ietf.webex.com/ietf/j.php?MTID=m05017815004a8c36f611a6df37c3a58f__;!8WoA6RjC81c!VNA3Ua3wQopzX2hjSjg5KbXc0x3eqKz0HGmKOPaQHfT2OS-mbk8EbFwU4OPR3Kc2$" rel="nofollow">Join     Join by phone Tap to call in from a mobile device (attendees only) 1-650-479-3208 Call-in toll number (US/Canada) 1-877-668-4493 Call-in toll free number (US/Canada) https://urldefense.com/v3/__https:/ietf.webex.com/ietf/globalcallin.php?MTID=mc116499fdee8a2248ced73570ee727c8__;!8WoA6RjC81c!VNA3Ua3wQopzX2hjSjg5KbXc0x3eqKz0HGmKOPaQHfT2OS-mbk8EbFwU4C9nALTN$" rel="nofollow">Global call-in numbers  |  https://urldefense.com/v3/__https:/www.webex.com/pdf/tollfree_restrictions.pdf__;!8WoA6RjC81c!VNA3Ua3wQopzX2hjSjg5KbXc0x3eqKz0HGmKOPaQHfT2OS-mbk8EbFwU4Gf1-Muy$" rel="nofollow">Toll-free calling restrictions     Need help? Go to https://urldefense.com/v3/__http:/help.webex.com__;!8WoA6RjC81c!VNA3Ua3wQopzX2hjSjg5KbXc0x3eqKz0HGmKOPaQHfT2OS-mbk8EbFwU4Eg-3Mvn$" rel="nofollow"> http://help..webex.com

 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.