Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt
"Gabriele Maria Galimberti (ggalimbe)" <ggalimbe@cisco.com> Fri, 12 October 2018 06:59 UTC
Return-Path: <ggalimbe@cisco.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 E2092130E04 for <ccamp@ietfa.amsl.com>; Thu, 11 Oct 2018 23:59:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 jjSF_E6mjWkf for <ccamp@ietfa.amsl.com>; Thu, 11 Oct 2018 23:59:24 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04E90130DFD for <ccamp@ietf.org>; Thu, 11 Oct 2018 23:59:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=156363; q=dns/txt; s=iport; t=1539327564; x=1540537164; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cxXZV+3dAhCxV4RkdHzV8Ivqybv+V6KZj5po7pQGCMc=; b=AMFs1v9ZLqSx+/J7i6mSYGyu7GMTxV6gWX13JHbSaC5aEjvX+hoCHSNr f9+CfInulz0FodKXEJKJydFnXaUD7MgMJfnCdx0GUADozzhSbXeFxRJPw tiivPfY0NhvGhzFjgWQU/j+D8o+5porKkudcNnGIAOpCEV/hdZboVk7SL 0=;
X-Files: image001.png : 1632
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAAAsRcBb/4sNJK1kGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQxIL2Z/KAqDa4FfhjeMOIFoJXqWCRSBYwMIAQIBARgBCYRKAheEPiE0DQ0BAwEBAgEBAm0cDIU5AQEBBAEBAxUBCAICBgEbIwIIAw4CAgEGAg4DAwEBAQYBAQEYAQYDAgICBRABAwsBCxQJCAIEAQ0EAQYDBQ0Egks2AYIBD4o3m017Mx+EDAEHB4UbDwWLQReBQT+BEQEnDBOBTkk1gjk9GgsBAQEBAQEEEoEUARIBAyIICQkGEAIGgkMxgiYCiROFEIYIg1aBX4NlUwkChW8BYYoCF4FPTIQiiVeHOoR8gguHLwIRFIElDRA4ZHFwFRohKgGCQQmBbS0DF4NHhRSFPm8BAQEBiWqBH4EfAQE
X-IronPort-AV: E=Sophos;i="5.54,371,1534809600"; d="png'150?scan'150,208,217,150";a="247205358"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Oct 2018 06:59:21 +0000
Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id w9C6xLHV030277 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Oct 2018 06:59:21 GMT
Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 12 Oct 2018 01:59:20 -0500
Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1395.000; Fri, 12 Oct 2018 01:59:20 -0500
From: "Gabriele Maria Galimberti (ggalimbe)" <ggalimbe@cisco.com>
To: Gert Grammel <ggrammel@juniper.net>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
CC: "ccamp@ietf.org" <ccamp@ietf.org>
Thread-Topic: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt
Thread-Index: AQHUVkGUqSP4Q3uB/EiWIXlNNA4jtqUYQPIAgABbn4CAAAWsgIAAAsSAgAAEMYCAAAPkgIAACCuAgAAMToCAADl8AIAAv/QQgACUBPCAALNcgIAAuKYA
Date: Fri, 12 Oct 2018 06:59:20 +0000
Message-ID: <85AFFDB5-2435-4494-B648-F210975D6F84@cisco.com>
References: <153577337941.29073.132620799131044718@ietfa.amsl.com> <3be83a17-85af-c425-5228-b4b28eb48598@nokia.com> <ECBD0632-0CAB-4BB2-8D8F-377E5CFFE2C3@juniper.net> <7AEB3D6833318045B4AE71C2C87E8E173D0680EF@sjceml521-mbx.china.huawei.com> <16D5DDC1-12C7-423F-8A3B-B72677AB68DE@juniper.net> <7AEB3D6833318045B4AE71C2C87E8E173D068160@sjceml521-mbx.china.huawei.com> <39E48A8E-BF12-4833-B4E3-A97ECB0E1BC6@juniper.net> <7AEB3D6833318045B4AE71C2C87E8E173D0681A3@sjceml521-mbx.china.huawei.com> <31D0ECD5-E958-4344-81EE-3BA5211601AA@juniper.net> <7AEB3D6833318045B4AE71C2C87E8E173D068250@sjceml521-mbx.china.huawei.com> <C35343D8-B85E-4F9E-8ADD-55B9F17933D6@juniper.net> <HE1PR07MB167568AAEAE5D06FF8330C97F0E10@HE1PR07MB1675.eurprd07.prod.outlook.com> <HE1PR07MB167563D9DA08FAD7CC11299CF0E10@HE1PR07MB1675.eurprd07.prod.outlook.com> <B6DC737B-3050-4D6E-ABF3-9238E69CFA24@juniper.net>
In-Reply-To: <B6DC737B-3050-4D6E-ABF3-9238E69CFA24@juniper.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1d.0.161209
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.228.192.21]
Content-Type: multipart/related; boundary="_004_85AFFDB524354494B648F210975D6F84ciscocom_"; type="multipart/alternative"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/RQniw2offu-GMevVAIWkwlAynW8>
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt
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: Fri, 12 Oct 2018 06:59:30 -0000
Hi All, I’d take the ITU application code as is and add new parameters in clear outside the A.C. Of course, I’d keep the vendor specific application code too. Best Regards, Gabriele [ttp://www.cisco.com/swa/i/logo.gif] Gabriele Galimberti Principal Engineer Cisco Photonics Srl 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: CCAMP <ccamp-bounces@ietf.org> on behalf of Gert Grammel <ggrammel@juniper.net> Date: Friday, 12 October 2018 at 00:58 To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Cc: "ccamp@ietf.org" <ccamp@ietf.org> Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt Daniele, appreciate your investigation. That RFC simply provides a switch that enables non-standard implementations, but does not define them. Moreover, the encoding is a 1:1 translation of the application code for standards An does not really provide definition for more or different parameters. You won’t find things like FEC gain ore even FEC on/off there. IOW it is hard to see the middle ground fir a hybrid approach.What exactly is the proposal to move forward? Best Gert Sent from my Apple ][ On 11. Oct 2018, at 18:22, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com>> wrote: Gert, Young, actually this sort of hybrid approach already exists in RFC 7581 section 4.1. Where both ITU and non-ITU application codes can be used: S (Standard bit): S=0: identifies non-ITU code points S=1: identifies ITU application codes With S=0, the OI Code Points field can take the following value: 0: reserved Future work may add support for vendor-specific application codes once the ITU-T has completed its work in that area. With S=1, the OI Code Points field can take the following values: 0: reserved 1: [G.698.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7581-23ref-2DG.698.1&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=jsbn4fnuT1-e93x59jI_EoA5TDTg3JmZrmmLl607E5M&s=h6wem3pHFOy661TSlfWdGhUlCpEsqYBolDMZx2JH2Jw&e=>] application code 2: [G.698.2<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7581-23ref-2DG.698.2&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=jsbn4fnuT1-e93x59jI_EoA5TDTg3JmZrmmLl607E5M&s=9FFDPD_s4D_EOWALj93Fd0432_rIxioObjmDCxNtPw4&e=>] application code 3: [G.959.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7581-23ref-2DG.959.1&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=jsbn4fnuT1-e93x59jI_EoA5TDTg3JmZrmmLl607E5M&s=_E_evT0wyzWMV0HYdOgSjh_R1F4PzPr7_5YXckU_EMs&e=>] application code 4: [G.695<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7581-23ref-2DG.695&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=jsbn4fnuT1-e93x59jI_EoA5TDTg3JmZrmmLl607E5M&s=Yo84CZN5aOmNuqcxIXV3tNtUM73BE-Af8qoLPBzfRkQ&e=>] application code BR Daniele From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> On Behalf Of Daniele Ceccarelli Sent: giovedì 11 ottobre 2018 09:33 To: Gert Grammel <ggrammel@juniper.net<mailto:ggrammel@juniper.net>>; Leeyoung <leeyoung@huawei.com<mailto:leeyoung@huawei.com>>; ccamp@ietf.org<mailto:ccamp@ietf.org> Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt Gert, Young, thanks for the discussion. That’s quite a dilemma. As Gert correctly said we’ve always been following ITU and used application codes, and I’d be inclined to continue along that path. However this would put us in a stuck position for those lacking or non future proof application codes. I’m wondering if an hybrid approach would be possible. Basically using the application codes where well defined ones exist and go for something non standard track and non application code based for the rest. While taking the action to discuss this with Fatai and Deborah, I would also like to hear 1) the feasibility of an hybrid approach and 2) the opinion of the WG. Thanks Daniele From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> On Behalf Of Gert Grammel Sent: mercoledì 10 ottobre 2018 22:00 To: Leeyoung <leeyoung@huawei.com<mailto:leeyoung@huawei.com>>; ccamp@ietf.org<mailto:ccamp@ietf.org> Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt Young, “My understanding of G.698.2 application code is that it does not cover all new tributary signal types and new fiber-types” is an observation we share (see https://tools.ietf.<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmany-2Dcoherent-2Ddwdm-2Dif-2Dcontrol-2D01&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=jsbn4fnuT1-e93x59jI_EoA5TDTg3JmZrmmLl607E5M&s=zsxj-yk_PSi3WrEIU8fcZ2Fgnxb8vlrY5BCidwhC1is&e=>https://tools.ietf.org/html/draft-many-coherent-dwdm-if-control-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmany-2Dcoherent-2Ddwdm-2Dif-2Dcontrol-2D01&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=jsbn4fnuT1-e93x59jI_EoA5TDTg3JmZrmmLl607E5M&s=zsxj-yk_PSi3WrEIU8fcZ2Fgnxb8vlrY5BCidwhC1is&e=>org/html/draft-many-coherent-dwdm-if-control-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmany-2Dcoherent-2Ddwdm-2Dif-2Dcontrol-2D01&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=jsbn4fnuT1-e93x59jI_EoA5TDTg3JmZrmmLl607E5M&s=zsxj-yk_PSi3WrEIU8fcZ2Fgnxb8vlrY5BCidwhC1is&e=> ). Yet that doesn’t solve the issue. Either ccamp accepts to follow ITU and use application codes, or ccamp needs to change track going for non-standard extensions and drop dependency on application codes. So far ccamp follows the first option. Gert From: 'Leeyoung' <leeyoung@huawei.com<mailto:leeyoung@huawei.com>> Date: Wednesday, October 10, 2018 at 18:34 To: Gert Grammel <ggrammel@juniper.net<mailto:ggrammel@juniper.net>>, CCAMP <ccamp@ietf.org<mailto:ccamp@ietf.org>> Cc: Dieter Beller <Dieter.Beller@nokia.com<mailto:Dieter.Beller@nokia.com>>, "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <zhenghaomian@huawei.com<mailto:zhenghaomian@huawei.com>> Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt Hi Gert, We introduced TTP augmentation to describe transponders. My understanding of G.698.2 application code is that it does not cover all new tributary signal types and new fiber-types. So if the application code in G.698.2 is forward-compatible, we can make use of it with a better YANG style format. Thanks, Young From: Gert Grammel [mailto:ggrammel@juniper.net] Sent: Wednesday, October 10, 2018 10:50 AM To: Leeyoung <leeyoung@huawei.com<mailto:leeyoung@huawei.com>>; ccamp@ietf.org<mailto:ccamp@ietf.org> Cc: Dieter Beller <Dieter.Beller@nokia.com<mailto:Dieter.Beller@nokia.com>>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <zhenghaomian@huawei.com<mailto:zhenghaomian@huawei.com>> Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt Young, are you suggesting to do 1) and 2)? To me 1) and 2) are mutually exclusive options and I don’t really understand what is proposed. My aim is to point out that if we keep the WSON-topology as a base, much of the augmentation proposed in your draft would be redundant. If e.g. the Application code already defines the FEC, why adding the FEC again as a separate parameter? Moreover your proposal allows to enable/disable the FEC. Doing so would also change the application code (with and without trailing-F). This doesn’t look like an elegant solution for the problem at hand. Probably some clarifying words from our chairs could help to provide further guidance on the general approach. Gert From: 'Leeyoung' <leeyoung@huawei.com<mailto:leeyoung@huawei.com>> Date: Wednesday, October 10, 2018 at 17:20 To: Gert Grammel <ggrammel@juniper.net<mailto:ggrammel@juniper.net>>, CCAMP <ccamp@ietf.org<mailto:ccamp@ietf.org>> Cc: Dieter Beller <Dieter.Beller@nokia.com<mailto:Dieter.Beller@nokia.com>>, "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <zhenghaomian@huawei.com<mailto:zhenghaomian@huawei.com>> Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt Hi Gert, The direction is to keep WSON as is and would add explicit property of Modulation/FEC types, etc. in the augmented impairment model. For WSON-topology, the format is series of “string”. We would keep this format in WSON-model. What do you need to see more for this case? typedef operational-mode { type string; description "Vendor-specific mode that guarantees interoperability. It must be an string with the following format: B-DScW-ytz(v) where all these attributes are conformant to the ITU-T recomendation"; reference "ITU-T G.698.2 (11/2009) Section 5.3"; } Now, when you want impairment model augmented from WSON, we would like to use the TTP to describe explicitly each component. Let us know what do you want to see more from the following? augment /nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point: +--ro available-modulation* identityref +--ro modulation-enabled? boolean +--ro modulation-type? identityref +--ro available-FEC* identityref +--ro FEC-enabled? boolean +--ro FEC-type? identityref +--ro FEC-code-rate? decimal64 +--ro FEC-threshold? decimal64 Thanks. Young From: Gert Grammel [mailto:ggrammel@juniper.net] Sent: Wednesday, October 10, 2018 10:07 AM To: Leeyoung <leeyoung@huawei.com<mailto:leeyoung@huawei.com>>; ccamp@ietf.org<mailto:ccamp@ietf.org> Cc: Dieter Beller <Dieter.Beller@nokia.com<mailto:Dieter.Beller@nokia.com>>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <zhenghaomian@huawei.com<mailto:zhenghaomian@huawei.com>> Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt Young, Unfortunately I wasn’t able to properly compile your last email. What do you have in mind with “THAT”? <snip> Yes, THAT is the direction we are taking with the impairment model. <snip> 1. If “that” means using G.698.2 application codes, the draft would need to be changed substantially 2. If “that” means draft-lee-ccamp-wson-impairment-yang-00 as-is, it would question the use of application codes and discussion in the WG. Thanks Gert From: 'Leeyoung' <leeyoung@huawei.com<mailto:leeyoung@huawei.com>> Date: Wednesday, October 10, 2018 at 16:51 To: Gert Grammel <ggrammel@juniper.net<mailto:ggrammel@juniper.net>>, CCAMP <ccamp@ietf.org<mailto:ccamp@ietf.org>> Cc: Dieter Beller <Dieter.Beller@nokia.com<mailto:Dieter.Beller@nokia.com>>, "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <zhenghaomian@huawei.com<mailto:zhenghaomian@huawei.com>> Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt Hi Gert, Yes, that is the direction we are taking with the impairment model. Thanks. Young From: Gert Grammel [mailto:ggrammel@juniper.net] Sent: Wednesday, October 10, 2018 9:42 AM To: Leeyoung <leeyoung@huawei.com<mailto:leeyoung@huawei.com>>; ccamp@ietf.org<mailto:ccamp@ietf.org> Cc: Dieter Beller <Dieter.Beller@nokia.com<mailto:Dieter.Beller@nokia.com>>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <zhenghaomian@huawei.com<mailto:zhenghaomian@huawei.com>> Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt Yang, I was referring to augment /nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point: +--ro available-modulation* identityref +--ro modulation-enabled? boolean +--ro modulation-type? identityref +--ro available-FEC* identityref +--ro FEC-enabled? boolean +--ro FEC-type? identityref +--ro FEC-code-rate? decimal64 +--ro FEC-threshold? decimal64 For example: The modulation is part of the application code (from the actual G.698.2 a bit shortened for readability): The application code notation is constructed as follows: DScW-ytz(v) where, D is the indicator of DWDM applications. S indicates options of maximum spectral excursion such as: · – N indicating narrow spectral excursion. · – W indicating wide spectral excursion. c is the channel spacing in GHz. W indicates the black link dispersion compensation regime as follows: · – C indicating that the chromatic dispersion values are appropriate to a black link that is dispersion compensated. · – U indicating that the chromatic dispersion values are appropriate to a black link that is dispersion uncompensated. y indicates the highest class of optical tributary signal supported: o – 1 indicating NRZ 2.5G. o – 2 indicating NRZ 10G. t is a letter indicating the configuration supported by the application code. In the current version of this Recommendation, the only value used is: – A indicating that the black link may contain optical amplifiers. z indicates the fibre types, as follows: · – 2 indicating ITU-T G.652 fibre. · – 3 indicating ITU-T G.653 fibre. · – 5 indicating ITU-T G.655 fibre. v indicates the operating wavelength range in terms of spectral bands (see [b-ITU-T G-Sup.39]): If more than one spectral band is used, then v becomes the band letters separated by "+", e.g., for an application requiring the use of both of the C and L bands, v would be "C+L". For some application codes, a suffix is added to the end of the code. The only suffix currently defined is: – F to indicate that this application requires FEC bytes as specified in [ITU-T G.709] to be transmitted. So under the assumption the application code is defined for the tunnel termination point: augment /nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point: +--ro available-modulation* identityref --> Parameter y +--ro modulation-enabled? Boolean --> the code defines only one modulation, not enabled/disabled +--ro modulation-type? Identityref --> parameter y +--ro available-FEC* identityref --> parameter F is a Boolean +--ro FEC-enabled? Boolean --> enabled/disabled would result in two different application codes (with and without tailing F) +--ro FEC-type? Identityref --> F +--ro FEC-code-rate? decimal64 --> since F is defined, this one is defined too +--ro FEC-threshold? decimal64 --> since F is defined, this one is defined too Best Gert From: 'Leeyoung' <leeyoung@huawei.com<mailto:leeyoung@huawei.com>> Date: Wednesday, October 10, 2018 at 16:21 To: Gert Grammel <ggrammel@juniper.net<mailto:ggrammel@juniper.net>>, CCAMP <ccamp@ietf.org<mailto:ccamp@ietf.org>> Cc: Dieter Beller <Dieter.Beller@nokia.com<mailto:Dieter.Beller@nokia.com>>, "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <zhenghaomian@huawei.com<mailto:zhenghaomian@huawei.com>> Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt Hi Gert, In the current WSON model, we have the following: augment /nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point: +--rw supported-operational-modes* te-wson-types:operational-mode +--rw configured-operational-modes? te-wson-types:operational-mode +--rw supported-fec-types* identityref +--rw supported-termination-types* identityref +--rw supports-bit-stuffing? boolean So we are describing application codes in the TTP. Is this what you meant to describe application code in the Termination Point? Thanks. Young From: Gert Grammel [mailto:ggrammel@juniper.net] Sent: Wednesday, October 10, 2018 3:54 AM To: ccamp@ietf.org<mailto:ccamp@ietf.org> Cc: Dieter Beller <Dieter.Beller@nokia.com<mailto:Dieter.Beller@nokia.com>>; Leeyoung <leeyoung@huawei.com<mailto:leeyoung@huawei.com>>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <zhenghaomian@huawei.com<mailto:zhenghaomian@huawei.com>> Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt The draft triggered a question about the approach we are using in ccamp to address WSON going forward. In the past, the group aimed for alignment with ITU-T and using application codes to describe optical capabilities. Is this still the way forward? If so, my expectation would be to find application codes as description of termination points. If the view changed, it should be spelled out. Gert From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> on behalf of Dieter Beller <Dieter.Beller@nokia.com<mailto:Dieter.Beller@nokia.com>> Organization: Nokia Date: Thursday, September 27, 2018 at 11:07 To: 'Leeyoung' <leeyoung@huawei.com<mailto:leeyoung@huawei.com>>, Zhenghaomian <zhenghaomian@huawei.com<mailto:zhenghaomian@huawei.com>> Cc: CCAMP <ccamp@ietf.org<mailto:ccamp@ietf.org>> Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt Hi Young and Haomian, I had a look at draft-lee-ccamp-wson-impairment-yang-00, which you submitted a few weeks ago and I have the following concerns: The abstract and introduction states: Abstract This document provides a YANG data model for the impairment-aware TE topology in wavelength switched optical networks (WSONs). 1. Introduction ... This document provides a YANG data model for the impairment-aware Traffic Engineering (TE) topology in wavelength switched optical networks (WSONs). The YANG model described in this document is a WSON technology-specific Yang model based on the information model developed in [RFC7446<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7446&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=zk3zS00lx60_LBxIKggxhMkHsPCBJ4biAFdpDYpeTGA&s=t3EVJKIBbfBziQCv67C_SIGqCsL1lLO5QfzEzD1wC0Y&e=>] and the two encoding documents [RFC7581<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7581&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=zk3zS00lx60_LBxIKggxhMkHsPCBJ4biAFdpDYpeTGA&s=S4OUJ2my7xLw9DxcGX9NUyph3GbY44XOtQud1wwYp-A&e=>] and [RFC7579<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7579&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=zk3zS00lx60_LBxIKggxhMkHsPCBJ4biAFdpDYpeTGA&s=V6LYiY4JVdT0RvJb6BoDJ0MWyLwIBz-nlotLCl8iNWk&e=>] that developed protocol independent encodings based on [RFC7446<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7446&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=zk3zS00lx60_LBxIKggxhMkHsPCBJ4biAFdpDYpeTGA&s=t3EVJKIBbfBziQCv67C_SIGqCsL1lLO5QfzEzD1wC0Y&e=>]. Based on this scope, I was expecting that this I-D provides te-link augmentations for WSON networks. Examples of WSON specific te-link attributes are fiber type, spectrum availability, chromatic dispersion, PMD, PDL, OSNR contribution (if the link includes ILAs) just to list a few. However, the only te-link augmentation is: augment /nw:networks/nw:network/nt:link/tet:te/tet:te-link-attributes: +--ro power? int32 It is also reasonable to define WSON augmentations for termination points representing the line side of optical transponders as they can be considered as topological elements even if these attributes are not representing optical impairments!: augment /nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point: +--ro available-modulation* identityref +--ro modulation-enabled? boolean +--ro modulation-type? identityref +--ro available-FEC* identityref +--ro FEC-enabled? boolean +--ro FEC-type? identityref +--ro FEC-code-rate? decimal64 +--ro FEC-threshold? decimal64 I don't understand why all the OT attributes are defined as ro attributes. State of the art OTs typically provide multiple operational modes. Hence, these attributes should be defined as rw attributes. All other augmentations are defined for paths (te-tunnels) or termination points, which is a bit strange! Here are two examples: augment /nw:networks/nw:network/nt:link/tet:te/tet:te-link- attributes/tet:underlay/tet:primary-path/tet:path- element/tet:type/tet:label/tet:label-hop/tet:te-label/tet:technology: +--:(wson-imp-topo) +--rw (grid-type)? | +--:(dwdm) | | +--ro channel-freq? decimal64 | +--:(cwdm) | +--ro channel-wavelength? uint32 +--ro bit-rate? decimal64 +--ro BER? decimal64 +--ro pmd? decimal64 +--ro cd? decimal64 +--ro osnr? decimal64 +--ro q-factor? decimal64 channel-freq/channel-wavelength, bit-rate, BER are definitively service (te-tunnel) attributes and do not represent optical impairments for a WSON network topology. For pmd, cd, and q-factor (definition?), it looks like these are attributes for all the links along the path. Why are these impairments defined for a path and are not te-link augmentations? I was expecting that this draft defines optical impairments for the topological entities in a WSON network where optical impairments matter. Could you please clarify. Thanks, Dieter On 01.09.2018 05:42, internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Yang Data Model for Impairment-Aware WSON Optical Networks Authors : Young Lee Haomian Zheng Filename : draft-lee-ccamp-wson-impairment-yang-00.txt Pages : 18 Date : 2018-08-31 Abstract: This document provides a YANG data model for the impairment-aware TE topology in wavelength switched optical networks (WSONs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-lee-ccamp-wson-impairment-yang/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dlee-2Dccamp-2Dwson-2Dimpairment-2Dyang_&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=zk3zS00lx60_LBxIKggxhMkHsPCBJ4biAFdpDYpeTGA&s=uI9XVdKyAYxfJxgBNbJzFb7PcL4ucbR7pQ3vwpUtFww&e=> There are also htmlized versions available at: https://tools.ietf.org/html/draft-lee-ccamp-wson-impairment-yang-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dlee-2Dccamp-2Dwson-2Dimpairment-2Dyang-2D00&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=zk3zS00lx60_LBxIKggxhMkHsPCBJ4biAFdpDYpeTGA&s=9LRKj19B6QDmn2a-h5BQmCAtnorDM8ZXdbZeH9OrK3U&e=> https://datatracker.ietf.org/doc/html/draft-lee-ccamp-wson-impairment-yang-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dlee-2Dccamp-2Dwson-2Dimpairment-2Dyang-2D00&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=zk3zS00lx60_LBxIKggxhMkHsPCBJ4biAFdpDYpeTGA&s=yYQwBhf6k5pjyQs5AzU42jJPSWagS6hRERQh6xmBKpQ&e=> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=zk3zS00lx60_LBxIKggxhMkHsPCBJ4biAFdpDYpeTGA&s=INR37WxNxA8xTIwaS6H619I9PtANk9yce9uZ5K0JUPo&e=> _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org> https://www.ietf.org/mailman/listinfo/i-d-announce<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_i-2Dd-2Dannounce&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=zk3zS00lx60_LBxIKggxhMkHsPCBJ4biAFdpDYpeTGA&s=y7F8N-yRSsfKTyuRhcdGIldonUXJm1JjYAVeCDOpKGA&e=> Internet-Draft directories: http://www.ietf.org/shadow.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_shadow.html&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=zk3zS00lx60_LBxIKggxhMkHsPCBJ4biAFdpDYpeTGA&s=3I5S3Q84_0hym70TgOlwjPHUfcqCWflXKfQQNwLIdTE&e=> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_ietf_1shadow-2Dsites.txt&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=zk3zS00lx60_LBxIKggxhMkHsPCBJ4biAFdpDYpeTGA&s=nqyp7tceQcl0YDvaQkoXSngBC3d39UaNlPP564Bjj0A&e=>
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Dieter Beller
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Gert Grammel
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Leeyoung
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Gert Grammel
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Leeyoung
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Gert Grammel
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Leeyoung
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Gert Grammel
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Leeyoung
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Gert Grammel
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Daniele Ceccarelli
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Daniele Ceccarelli
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Gert Grammel
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Gabriele Maria Galimberti (ggalimbe)
- [CCAMP] 答复: I-D Action: draft-lee-ccamp-wson-impa… Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Jonas Mårtensson
- Re: [CCAMP] 答复: I-D Action: draft-lee-ccamp-wson-… Gabriele Maria Galimberti (ggalimbe)
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Leeyoung
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Dieter Beller
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Leeyoung
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Jonas Mårtensson
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Beller, Dieter (Nokia - DE/Stuttgart)
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Leeyoung
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Leeyoung
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Jonas Mårtensson
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Beller, Dieter (Nokia - DE/Stuttgart)
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Gabriele Maria Galimberti (ggalimbe)
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Beller, Dieter (Nokia - DE/Stuttgart)
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Daniele Ceccarelli
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Jonas Mårtensson
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Daniele Ceccarelli
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Jonas Mårtensson
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Daniele Ceccarelli
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Gabriele Maria Galimberti (ggalimbe)
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Leeyoung
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Leeyoung
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Belotti, Sergio (Nokia - IT/Vimercate)
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Beller, Dieter (Nokia - DE/Stuttgart)
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Huub van Helvoort
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Gert Grammel
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Jonas Mårtensson
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Leeyoung
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Jonas Mårtensson
- [CCAMP] 答复: I-D Action: draft-lee-ccamp-wson-impa… Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Gert Grammel
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Daniele Ceccarelli
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Beller, Dieter (Nokia - DE/Stuttgart)
- [CCAMP] 答复: I-D Action: draft-lee-ccamp-wson-impa… Fatai Zhang
- [CCAMP] 答复: I-D Action: draft-lee-ccamp-wson-impa… Fatai Zhang
- Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impa… Huub van Helvoort