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

"Belotti, Sergio (Nokia - IT/Vimercate)" <sergio.belotti@nokia.com> Tue, 15 October 2019 09:24 UTC

Return-Path: <sergio.belotti@nokia.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564B4120025 for <ccamp@ietfa.amsl.com>; Tue, 15 Oct 2019 02:24:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level:
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9HdTFTmhlWe for <ccamp@ietfa.amsl.com>; Tue, 15 Oct 2019 02:24:10 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50106.outbound.protection.outlook.com [40.107.5.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B484120071 for <ccamp@ietf.org>; Tue, 15 Oct 2019 02:24:07 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Kh1G9RWyNekYwRRhKTftTdspCHxyWoyieZItALh1VakCkIpTuV0qnFZ+/pFKOqVYBPWECu3ODIcyeoHYS8npKH3sRrb3huRQ9taWvztnetJcnoLUyAyMKA64gqrmrlNbVQI3qNN/RnJxtLNuDNamw9Wskg9kJ2VLs0yMXpBUYvNpI0HoOXNyz7J6D9hJZlRzcWcM7tuA4/n+R6Vt7bi3Uhgdl0HH3qcQBvsdMgRpCpfL6sDgyU7gUU/vkMVq2gHynQBrhprTQkIXPVKe3ccBPQ8H44c20YT1K6iG7Ahlzl3ozTf7F86E0V32r77xqBRXTrKGgUyRHfxswBmf26qVjA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9k07W1Z+Grf9jLelIp57Sfb5WR0pkVPsijsT49W6O04=; b=OerSvSV9aMoCNSB4/0zttZB/sJi59d+SSvjBqYtxhrRYLY4NZ9lTDunJlKOz68HruQMaIFc55WF4U74Z/U8bC0nFID2GqkBQ1eHChBk2T2VqHayNFvLHMBioLwF19ugltTGsl/qA3qfKbXsckK5ikbfnmoSCOK+9SgfCAeko4C3kklGKNz2vvM18veltiH7OJRcdSjQmBCCw1BLCOTSljw7De96XT02oOXPDvGZDPnmpXQuD9x48a8c9LUeLRQiaxatN5m8D4Bb2HKtZGgoLggRWB4Kx+ubkYSEjK1KYKcZk2W3NFaQMCln68qg5qXlJStALtlkviJOJh6/7t+JK0Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9k07W1Z+Grf9jLelIp57Sfb5WR0pkVPsijsT49W6O04=; b=ZFggDAufxFU0PBE4WpLmmJZG4kov2KMEPmA8aMZlETeDpfNwR+enuRLXZQU5/KctDR2FPPjIewlnvAJxgq3biQgejoNRVRsLsVee8aaksaJLf/T2k6HIaoWWzB/XD5A+Nlqf6Gd8OjcejyCUhYsbeGb8CQlgeg1p4phL2r99ugU=
Received: from AM0PR07MB5121.eurprd07.prod.outlook.com (20.178.19.26) by AM0PR07MB5492.eurprd07.prod.outlook.com (20.178.21.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.13; Tue, 15 Oct 2019 09:24:02 +0000
Received: from AM0PR07MB5121.eurprd07.prod.outlook.com ([fe80::fcdf:7b7d:fc0b:35c4]) by AM0PR07MB5121.eurprd07.prod.outlook.com ([fe80::fcdf:7b7d:fc0b:35c4%6]) with mapi id 15.20.2347.023; Tue, 15 Oct 2019 09:24:02 +0000
From: "Belotti, Sergio (Nokia - IT/Vimercate)" <sergio.belotti@nokia.com>
To: "Gabriele Maria Galimberti (ggalimbe)" <ggalimbe@cisco.com>, "julien.meuric@orange.com" <julien.meuric@orange.com>, Gert Grammel <ggrammel@juniper.net>, Italo Busi <Italo.Busi@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli=40ericsson.com@dmarc.ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>
Thread-Topic: [CCAMP] Webex meeting invitation: Optical Impairments - occurrence of week 40
Thread-Index: AQHVd4dXsnp1bNeTPUKMgYbATp2NBqdEIESAgAAR8ICABnmSAIAAG5GAgAgNGwCAAAz0AIAArjaAgAAFa4CAAAQFsIAAJk2AgAA0/ICAAC0kgIAHYN0w
Date: Tue, 15 Oct 2019 09:23:59 +0000
Message-ID: <AM0PR07MB5121E89F4FF6E07992D62D1791930@AM0PR07MB5121.eurprd07.prod.outlook.com>
References: <1898196316.43081569845112588.JavaMail.nobody@rva2rmd101.webex.com> <AM0PR07MB6098625720E7177F12DA2127F0820@AM0PR07MB6098.eurprd07.prod.outlook.com> <64F20F40-C684-43B4-9BD7-58E26074E85A@cisco.com> <AM0PR07MB51218775C2B017256A42BD7C919E0@AM0PR07MB5121.eurprd07.prod.outlook.com> <EA79C712-47C9-4308-A1BF-EB487CEA4249@juniper.net> <f8a3086e2c364d2eaf8676b67e53b572@huawei.com> <5D060223-AC98-4CBB-B2B0-AEE5E6E526CF@juniper.net> <8a210d5e7d204209a8bf302c057bfe92@huawei.com> <17CC67D4-9518-4E35-91C0-B0570FA6B1A6@juniper.net> <AM0PR07MB512176402B208DBADB0E096791940@AM0PR07MB5121.eurprd07.prod.outlook.com> <18D800AF-D222-4177-A05E-D18AD6C3816B@juniper.net> <12985_1570715443_5D9F3733_12985_107_1_e88d2356-e536-4752-900e-fa335ac67d25@OPEXCAUBM23.corporate.adroot.infra.ftgroup> <9C7233CC-5663-4D95-ACCA-E38F163F25FF@cisco.com>
In-Reply-To: <9C7233CC-5663-4D95-ACCA-E38F163F25FF@cisco.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=sergio.belotti@nokia.com;
x-originating-ip: [131.228.32.183]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 79e6cdf1-afc6-4589-0757-08d751516ad6
x-ms-office365-filtering-ht: Tenant
x-ms-traffictypediagnostic: AM0PR07MB5492:
x-ms-exchange-purlcount: 7
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <AM0PR07MB5492AA31F7B17BEF8B5032F491930@AM0PR07MB5492.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-forefront-prvs: 01917B1794
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(136003)(396003)(346002)(366004)(189003)(199004)(51444003)(53754006)(6246003)(81156014)(186003)(8936002)(74316002)(3846002)(86362001)(6666004)(9686003)(236005)(790700001)(54896002)(55016002)(733005)(16799955002)(229853002)(107886003)(7696005)(99936001)(6436002)(52536014)(8676002)(99286004)(81166006)(71190400001)(71200400001)(26005)(76116006)(54906003)(64756008)(66446008)(110136005)(966005)(53546011)(66066001)(66576008)(66946007)(25786009)(1941001)(7736002)(76176011)(478600001)(66556008)(6306002)(2501003)(6116002)(66476007)(316002)(5660300002)(476003)(606006)(4326008)(30864003)(14444005)(5024004)(486006)(102836004)(6506007)(2906002)(11346002)(33656002)(446003)(14454004)(256004)(12620500001)(579004)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB5492; H:AM0PR07MB5121.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: nDkz7I+PGfY+2jsvWwlKLoXiwEsMnkqfPkrIK3GMWOih9O7R593hD2UfamUYewHK0aPmy3Bw10ZhfBWWpcvrH9/v1IxZ1sOBPHi/rBVxH/IXrOOsgJ+1RXVVVKtXT8xIRD6xVs7B6LknldvTToNJTpfmk+I96IKww2xEPdwAYZC/vj5ApIvDA/Snj0aPU48zYHKVQG95cwmvU5W8s1FfhG6p0aqFXhzKtCvHGvh0Rqs1nJBEBbrkqBORS5hX035Wra7MUkyqV/CUleS9fgBpPmDhawr/hP3ke1xcGQvmLu7MZTYd8JW3xAdyLcGyljHhRRYMEzn/BxErtzQ5aiJ4uSRh40cm1eLlXoPFJlc6qRVbMDPhNpDI0V2rRRgyEITwHjs8t/cMsoH/QWB1Om3RxJrcJ4p6Oy4zOUGfbMtCBJI9yGXiQVzkJ2Okgown6TLhgWbSGikDea54Lo2prf7Emw==
Content-Type: multipart/related; boundary="_007_AM0PR07MB5121E89F4FF6E07992D62D1791930AM0PR07MB5121eurp_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 79e6cdf1-afc6-4589-0757-08d751516ad6
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2019 09:23:59.9830 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 42MsR1redX71QzTzMH8Pzu7Qn9mVdqEZIk6aC5yaz3GEDc9BVN6C5QnXK+Txi8TCUD2MXqbxdsGuZItenX2NajKuk79lfXLtARyq4Q4xhn0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5492
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/4XvnYo5qI0uLHVViasg9vOYzmNU>
Subject: Re: [CCAMP] Webex meeting invitation: Optical Impairments - occurrence of week 40
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Oct 2019 09:24:14 -0000

Hi Gabriele, all,
Sincerely we did not reach agreement during the call .
I agree to what Julien said, but, on the other side I do not see difference with respect what represented in the contribution provided by Dieter on different ROADM architecture.
I think that both slide 2 and slide 3 of presentation already provide OT and ROADM separation . If there are other use cases not represented in the Dieter’s slide , I would suggest to contribute and add clear architecture scenario to be addressed .
I guess we should start to converge in a stepwise approach with respect different architecture and start addressing optical parameters discussion , since we have only three weeks to update the draft.

Thanks
Sergio

Sergio Belotti
Senior System Engineer and Standardization Architect
IP/Optical Networks, Optics BU
Nokia
M: +39-335761776
Via Energy Park, 20871 Vimercate (MB) , Italy
sergio.belotti@nokia.com<mailto:sergio.belotti@nokia.com>



From: Gabriele Maria Galimberti (ggalimbe) <ggalimbe@cisco.com>
Sent: Thursday, October 10, 2019 6:32 PM
To: julien.meuric@orange.com; Gert Grammel <ggrammel@juniper.net>; Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com>; Italo Busi <Italo.Busi@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli=40ericsson.com@dmarc.ietf.org>; ccamp@ietf.org
Cc: esther.lerouzic@orange.com; Beller, Dieter (Nokia - DE/Stuttgart) <dieter.beller@nokia.com>; Griseri, Enrico (Nokia - IT/Vimercate) <enrico.griseri@nokia.com>
Subject: Re: [CCAMP] Webex meeting invitation: Optical Impairments - occurrence of week 40

I agree with Julien,

And probably You reach an agreement during the call.
I had issues with my network connection I apologize not being present and active for all the all.

Best Regards,

Gabriele


[cid:image001.png@01D5834B.080440E0]


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.com<mailto:ggalimbe@cisco.com>
Phone :+39 039 2091462
Mobile :+39 335 7481947
Fax :+39 039 2092049











From: "julien.meuric@orange.com<mailto:julien.meuric@orange.com>" <julien.meuric@orange.com<mailto:julien.meuric@orange.com>>
Organization: Orange
Date: Thursday, 10 October 2019 at 18:11
To: Gert Grammel <ggrammel@juniper.net<mailto:ggrammel@juniper.net>>, Sergio Belotti <sergio.belotti@nokia.com<mailto:sergio.belotti@nokia.com>>, Italo Busi <Italo.Busi@huawei.com<mailto:Italo.Busi@huawei.com>>, Gabriele Galimberti <ggalimbe@cisco.com<mailto:ggalimbe@cisco.com>>, Daniele Ceccarelli <daniele.ceccarelli=40ericsson.com@dmarc.ietf.org<mailto:daniele.ceccarelli=40ericsson.com@dmarc.ietf.org>>, "ccamp@ietf.org<mailto:ccamp@ietf.org>" <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Cc: LE ROUZIC Esther IMT/OLN <esther.lerouzic@orange.com<mailto:esther.lerouzic@orange.com>>, Dieter Beller <dieter.beller@nokia.com<mailto:dieter.beller@nokia.com>>, "Griseri, Enrico (Nokia - IT/Vimercate)" <enrico.griseri@nokia.com<mailto:enrico.griseri@nokia.com>>
Subject: Re: [CCAMP] Webex meeting invitation: Optical Impairments - occurrence of week 40

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)" <sergio.belotti@nokia.com><mailto:sergio.belotti@nokia.com>
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 <ggrammel@juniper.net><mailto:ggrammel@juniper.net>
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 <Italo.Busi@huawei.com<mailto:Italo.Busi@huawei.com>>
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 : +39 345 4721946
Email : italo.busi@huawei.com<mailto:italo.busi@huawei.com>
[cid:image006.png@01D5834B.080440E0]

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:ggrammel@juniper.net]
Sent: mercoledì 9 ottobre 2019 23:27

Italo,

In our call we discussed an extension of  https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-22<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-teas-yang-te-topo-22__;!8WoA6RjC81c!QZ5vjOymZTtm_a_MEUBz4o1f_B88GQ_F2ZQ-sLAxVqd6gTLoNB_OuZkRauwcfLtP$> 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 <Italo.Busi@huawei.com<mailto:Italo.Busi@huawei.com>>
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 : +39 345 4721946
Email : italo.busi@huawei.com<mailto:italo.busi@huawei.com>
[cid:image008.png@01D5834B.080440E0]

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:ggrammel@juniper.net]
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)" <sergio.belotti@nokia.com<mailto:sergio.belotti@nokia.com>>
Date: Friday, October 4, 2019 at 18:16

Hi all,

Related to the meeting on Wednesday October 2nd ,
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: +39-335761776
Via Energy Park, 20871 Vimercate (MB) , Italy
sergio.belotti@nokia.com<mailto:sergio.belotti@nokia.com>



From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> On Behalf Of Gabriele Maria Galimberti (ggalimbe)
Sent: Monday, September 30, 2019 3:12 PM

Thanks a lot Daniele,

Best regards,

Gabriele

[cid:image009.png@01D5834B.080440E0]


Gabriele Galimberti
Principal Engineer
Cisco Photonics Srl
Italy

via S.Maria Molgora, 48 C
20871 - Vimercate (MB)
Italy
www.cisco.com/global/IT/<https://urldefense.com/v3/__http:/www.cisco.com/global/IT/__;!8WoA6RjC81c!VNA3Ua3wQopzX2hjSjg5KbXc0x3eqKz0HGmKOPaQHfT2OS-mbk8EbFwU4AVRSscg$>

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











From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> on behalf of Daniele Ceccarelli <daniele.ceccarelli=40ericsson.com@dmarc.ietf.org<mailto:daniele.ceccarelli=40ericsson.com@dmarc.ietf.org>>
Date: Monday, 30 September 2019 at 14:08

Hi WG,

ONLY FOR THIS WEEK the Optical Impairments call we be moved to Wednesday 2nd instead of usual Thursday slot.
Starting from next week we’ll be back to Thursday as usual.

Thanks,

Daniele

From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> On Behalf Of CCAMP Working Group
Sent: den 30 september 2019 14:05
To: ccamp@ietf.org<mailto:ccamp@ietf.org>
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



Join<https://urldefense.com/v3/__https:/ietf.webex.com/ietf/j.php?MTID=m05017815004a8c36f611a6df37c3a58f__;!8WoA6RjC81c!VNA3Ua3wQopzX2hjSjg5KbXc0x3eqKz0HGmKOPaQHfT2OS-mbk8EbFwU4OPR3Kc2$>



Join by phone
Tap to call in from a mobile device (attendees only)
1-650-479-3208<tel:%2B1-650-479-3208,,*01*644305032%23%23*01*> Call-in toll number (US/Canada)
1-877-668-4493<tel:1-877-668-4493,,*01*644305032%23%23*01*> Call-in toll free number (US/Canada)
Global call-in numbers<https://urldefense.com/v3/__https:/ietf.webex.com/ietf/globalcallin.php?MTID=mc116499fdee8a2248ced73570ee727c8__;!8WoA6RjC81c!VNA3Ua3wQopzX2hjSjg5KbXc0x3eqKz0HGmKOPaQHfT2OS-mbk8EbFwU4C9nALTN$>  |  Toll-free calling restrictions<https://urldefense.com/v3/__https:/www.webex.com/pdf/tollfree_restrictions.pdf__;!8WoA6RjC81c!VNA3Ua3wQopzX2hjSjg5KbXc0x3eqKz0HGmKOPaQHfT2OS-mbk8EbFwU4Gf1-Muy$>



Need help? Go to http://help..webex.com<https://urldefense.com/v3/__http:/help.webex.com__;!8WoA6RjC81c!VNA3Ua3wQopzX2hjSjg5KbXc0x3eqKz0HGmKOPaQHfT2OS-mbk8EbFwU4Eg-3Mvn$>




_________________________________________________________________________________________________________________________



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.