Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Tue, 23 October 2018 12:28 UTC

Return-Path: <daniele.ceccarelli@ericsson.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 CE311130EC9 for <ccamp@ietfa.amsl.com>; Tue, 23 Oct 2018 05:28:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.769
X-Spam-Level:
X-Spam-Status: No, score=-4.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=fg2+v6KH; dkim=pass (1024-bit key) header.d=ericsson.com header.b=me+zMKPM
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 3JOJNxnF-EV5 for <ccamp@ietfa.amsl.com>; Tue, 23 Oct 2018 05:28:45 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2EB130EB7 for <ccamp@ietf.org>; Tue, 23 Oct 2018 05:28:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1540297722; x=1542889722; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=GMfooGHYhX4IZ6v5xOFDki2Ai6mTtwuHS0yiN4MnJ1s=; b=fg2+v6KHs7o5LExRbFuAxFbgZ6bFn83X1F8sZC+vongAGsYE+Pmo57zTV4CG8Xou Hb2hC/yYOAuE555x6PkR/3kgCCpiTyLzmzARdw51W1ozG2krRyrcYyr+uikHbw71 c6SiQKb76psPUqGpyQx/OM0Wx4k+b4VwTRqctzQ/8S4=;
X-AuditID: c1b4fb3a-171ff700000012ff-1c-5bcf13fafd0e
Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 12.11.04863.AF31FCB5; Tue, 23 Oct 2018 14:28:42 +0200 (CEST)
Received: from ESESSMR505.ericsson.se (153.88.183.127) by ESESBMB502.ericsson.se (153.88.183.185) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 23 Oct 2018 14:28:41 +0200
Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESSMR505.ericsson.se (153.88.183.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 23 Oct 2018 14:28:42 +0200
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 23 Oct 2018 14:28:41 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GMfooGHYhX4IZ6v5xOFDki2Ai6mTtwuHS0yiN4MnJ1s=; b=me+zMKPMJ6ljFOtdOavj3UOR2FPmCXcfnbqRmXl+vu1ISrg08G8uWCE/divFdhV6ZU3nZJX3Ypjws2HlhDf+rWrvvKXrOk25TG3abu3P+PCNOFVE/vF8tn2TlQBHI+OhKjID9sSa15fJFPDX9TaWCAUEq2J0jhzvJ6ug6PiohxM=
Received: from HE1PR07MB1675.eurprd07.prod.outlook.com (10.166.124.141) by HE1PR07MB4250.eurprd07.prod.outlook.com (20.176.166.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.10; Tue, 23 Oct 2018 12:28:40 +0000
Received: from HE1PR07MB1675.eurprd07.prod.outlook.com ([fe80::2911:de12:18b4:deab]) by HE1PR07MB1675.eurprd07.prod.outlook.com ([fe80::2911:de12:18b4:deab%5]) with mapi id 15.20.1273.014; Tue, 23 Oct 2018 12:28:40 +0000
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <zhenghaomian@huawei.com>, =?utf-8?B?Sm9uYXMgTcOlcnRlbnNzb24=?= <jonas.martensson@ri.se>, Leeyoung <leeyoung@huawei.com>, "Beller, Dieter (Nokia - DE/Stuttgart)" <dieter.beller@nokia.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/EiWIXlNNA4jtqUbxM6A///5z/CABUahgP//i75QgAEIQgCAAEj9AIAAkF+AgARn+ICAABt8IIABUCWAgALwcjCAABDygIAANcSAgABDCwCAAAKwgIAA4L4AgAADHACAAEFd4A==
Date: Tue, 23 Oct 2018 12:28:39 +0000
Message-ID: <HE1PR07MB1675ED0595882A3E011F63EBF0F50@HE1PR07MB1675.eurprd07.prod.outlook.com>
References: <153577337941.29073.132620799131044718@ietfa.amsl.com> <3be83a17-85af-c425-5228-b4b28eb48598@nokia.com> <2034a3e97fd34423817dafc5bb0800f9@ri.se> <7AEB3D6833318045B4AE71C2C87E8E173D068BD0@sjceml521-mbx.china.huawei.com> <38f96492-312e-8c45-b52f-8a09096bbee9@nokia.com> <7AEB3D6833318045B4AE71C2C87E8E173D07A0E5@sjceml521-mbx.china.huawei.com> <fb323dd848714af683ed6ee88be7b4d0@ri.se> <4c14cb75-02e5-ef5a-3e15-4b74ed1063be@nokia.com> <7AEB3D6833318045B4AE71C2C87E8E173D07B6C6@sjceml521-mbx.china.huawei.com> <4f7eb2c3-4fd2-1f09-2dd0-3c9082df56ba@nokia.com> <HE1PR07MB167573189AC173575A8FA329F0F90@HE1PR07MB1675.eurprd07.prod.outlook.com> <7fd5f59bdaf44b82b9776d65b316386d@ri.se> <HE1PR07MB1675A06216EC0958493D2A50F0F40@HE1PR07MB1675.eurprd07.prod.outlook.com> <7ac2a67dc4ee402487d1abc255a4eb9f@ri.se> <7AEB3D6833318045B4AE71C2C87E8E173D07D824@sjceml521-mbx.china.huawei.com> <df2f2ca24179453aa222ea90272e323d@ri.se> <7AEB3D6833318045B4AE71C2C87E8E173D07D959@sjceml521-mbx.china.huawei.com> <c7340fe2815f4e06ba5245703d017f9b@ri.se> <E0C26CAA2504C84093A49B2CAC3261A43B7162A5@dggeml511-mbx.china.huawei.com>
In-Reply-To: <E0C26CAA2504C84093A49B2CAC3261A43B7162A5@dggeml511-mbx.china.huawei.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com;
x-originating-ip: [93.38.67.165]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HE1PR07MB4250; 6:uLB1yFLzlhgd9D6eDuL2Zb1uTfdgz/k9Wf4x701ueMuvvlCr8uNVDXQoGAPAHRwp2+xL8jPS6GcZn58YN/KMgGoKK8d0wYovREZl5ep+z/v9UGqmcCnHNTu3QK2jWtbgFlgXEpoWgIdZteWiHhlfkI4I+1uHv3qcqgQF4In7D8TzIQxEOgXqAcur/7nM9Al9MlJkiyRObY0v61JJ0D9377SHGZKfrdkguC5/WYtiuUp24rQNIyqWxXulo/VjmSleFcRt7QfAttS7mQLh8KU1rdWqMe1HNfa6/DFsiBk4M1qavB4d2ml7U3efSFxNkP+SBhLTyW6mwKXS4DMq0QAV1kOUbRSTII7vjiV9KYBAvjoYHj+hGnX/Np3swxMxWuFajOwDS/XBi39e7SPs2XjKImzaRZ5QWJYiJGM49+AVrKWaTLTvTCHhwuCAIIpE4zPw6BvyqR1wDdupnw7JF3H2Sg==; 5:sA/Fi9oi8h8HG352vtWOd9/jz+gEPRWmX2oIfOI0oF5kHiZ93r+/fLgOUirE2lXbUp+oDbNW7SSwBnoGrV/SmpxEku6PiddA5l5apKhyAqQjrk2W74rPrlxAswXTK+afYMqSA5wBDXqwfAYCZ0hUuYJmjBJ49wOD4HPWJ39YFZ0=; 7:+oF8kCZR+W+34ULnIIMIV7XBcU3ff2HuzlUwLJ1P1Ke1tJ2KOnlWJpw06CM59IpZy5OW3Ng6gxJiurKZ7kfmIQg5IaDYrF2iCsbeBVt808FwSLrju7ZRPIivpKtp/UDUl2/OC3Gb7dfmmQNwms5Lwg==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 99f8542c-0e0e-4079-1201-08d638e31050
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4250;
x-ms-traffictypediagnostic: HE1PR07MB4250:
x-microsoft-antispam-prvs: <HE1PR07MB42507C774DEA11A57AEA6197F0F50@HE1PR07MB4250.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(50582790962513)(248295561703944)(37575265505322)(195916259791689)(82608151540597)(109105607167333)(166708455590820)(120809045254105)(21748063052155)(28532068793085);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231355)(944501410)(4982022)(52105095)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:HE1PR07MB4250; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB4250;
x-forefront-prvs: 0834BAF534
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(136003)(346002)(376002)(366004)(51444003)(189003)(199004)(53754006)(6246003)(5250100002)(102836004)(99286004)(81166006)(71200400001)(71190400001)(53546011)(81156014)(6506007)(74316002)(8676002)(66574009)(7696005)(8936002)(7736002)(4744004)(76176011)(14454004)(105586002)(2906002)(68736007)(5660300001)(478600001)(229853002)(6436002)(2900100001)(33656002)(606006)(55016002)(561944003)(53946003)(16200700003)(106356001)(236005)(54896002)(6306002)(9686003)(6116002)(790700001)(966005)(25786009)(3846002)(97736004)(53936002)(256004)(14444005)(5024004)(4326008)(86362001)(316002)(476003)(93886005)(110136005)(446003)(11346002)(21615005)(44832011)(486006)(186003)(66066001)(26005)(579004)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4250; H:HE1PR07MB1675.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: my+dzTYAdOyXwUco7sJgZdf9oDbFOI8rZX8Zep1D+GfQtOjJLHArPDLHtU76UpQ5pl1/FARFcLSL8W68v5X0UrFhHRwpBNvzeO3TP3gEM0dv13wB9sI7GrWUKTroRVgkzjTNCap9cWWbWbr3SqDxUi0AGmUNcI+hnMFT+ZLh8/qXM5xtpIZDTjtHxc2MUSzp9CsDXe5Efe5GKR3zMHquI0gRy4Prl+gb44OIkscE1lmN0V3EIsfTVjxHAHXEAybIue/2N3mfyqBxWpQPeK7kbxOIOwWSXydOBDsGQAG3ktE/YoIhQQNKXyIOKeXj0/mGUalbubW0tohtpnxDN5KCfQhg1Vpkwf7qZrQK7VmuleE=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_HE1PR07MB1675ED0595882A3E011F63EBF0F50HE1PR07MB1675eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 99f8542c-0e0e-4079-1201-08d638e31050
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2018 12:28:40.0512 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4250
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+c45m8fh4mvOfFsJuixKvKQULBHJQFugURghWunKo67NCztm mlJmKqI1LLykaJquKCXN0jQTcyOVxBxZXvICmZMQCUNU1FLa8Vj03+99n+d9vufAoUlJl0BG qxOSGV2CSisXiqiysFbWY83eHHFwql+msFSMUooGwwSl6KmfIRUlDwIVS52XjwqU2e9+CJQG wyqhnBwbJJSPsl4Sp6hwkV80o1WnMDov/yhRXJN5TpBUN0+nvm3ttslEeYN0PrKlAR+ChtIh Mh+JaAnuRnC/JnNrWEaQ96Sa+jcUz88KuBMJNhAwZiE4gcKFJOgbPwl4VzEBVfPDBD98Q2C8 bbQqNC3EvmAxBXN7KS4kIKt8keSiSLwXckf6NmPtcTD0D9QijqU4BAbyn1P8wWME9Q1NBCdQ 1oNVfT7FhYrxOTBWnuErbdBQei+dY1t8FlZvTWzaEXaCwjc1iH/L0dq6iuC/GoOhw0zy7ACz 0xsC3n8RGnPatjzO0DLYS/HsBINVBYjnYSF8Np/k2QN+Fhdv5YTAXcvEFvcimHkt5WoCdoO+ 2n38WgNVA3eEPJsR6B/uLkTe5f+14zkRvubVCDkW4+3wvsxClVuTSHwAGtu9eIsLFBVM2fC8 H3IqKm3+31cjmzrkwDIsGx/r4+PJ6NSXWDYxwTOBSX6BrP+VsfmXbxsyfg8wIUwjuZ3Yq2Mg QiJQpbBp8SYENCmXiv06rStxtCrtGqNLjNRd0TKsCe2iKbmj+FiMIlyCY1XJjIZhkhjdX5Wg bWWZyNHOMtGypJWlt2Tv6Dr/21nrGpocIj0hNF7fWb5SMbm8mnLEZaFo3JwyNDcc8yrsuJ+j Xhn47PSFkaDO9ZLI2KjGgtRuUca6TqTJCM0d/RAQe/Wme9GKXU+Xq/tiiEjj+XHb+MLhnPag 6Rsm1m9P8xfZWgPo4/31i0/j5ctOUWo5xcapvN1IHav6AxH5DadTAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/3J-0cHjNzaBuQuWO3wuX78ZLcVg>
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: Tue, 23 Oct 2018 12:28:50 -0000

Hi,

i was basically identifying option 1 in which we keep on using “standard vs non standard” code points (i.e. ITU vs non ITU) and option 2 which allows further defining the non standard “group” into e.g. vendor specific, MSA, IA, open source etc.

If we go on with option 1 I would keep on using the terminology defined in RFC7581 (i.e. ITU application codes vs non ITU code points). If on the other hands you prefer to further specify categories for the non ITU code points, we can discuss about it.

The WG seems to be more or less equally split between the two options. I don’t have a strong opinion, both of them work for me. Probably further splitting the non standard ones allows for a cleaner allocation.

BR
Daniele

From: Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <zhenghaomian@huawei.com>;
Sent: martedì 23 ottobre 2018 10:24
To: Jonas Mårtensson <jonas.martensson@ri.se>;; Leeyoung <leeyoung@huawei.com>;; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>;; Beller, Dieter (Nokia - DE/Stuttgart) <dieter.beller@nokia.com>;
Cc: ccamp@ietf.org
Subject: 答复: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi,

I think we are converging with categorizing into “standardized” and “non-standardized”, we just need two terms on these.

For “standardized”, I would say “ITU-T G.698.2 Application code” is very explicit and will not have any misleading issue; it seems we don’t have other opinions neither.
For “non-standardized”, we have terms “vendor-specific” VS. “MSA/IA”. Personally I am preferring “vendor-specific”, which is implying it may be agreed by one or multiple vendors but is not standardized. I would not prefer using “MSA/IA”, as the standard (G.698.2 application code) is also a “MSA/IA”, which will be slightly misleading.

My 2 cents,
Haomian

发件人: Jonas Mårtensson [mailto:jonas.martensson@ri.se]
发送时间: 2018年10月23日 16:13
收件人: Leeyoung <leeyoung@huawei.com<mailto:leeyoung@huawei.com>>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com>>; Beller, Dieter (Nokia - DE/Stuttgart) <dieter.beller@nokia.com<mailto:dieter.beller@nokia.com>>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <zhenghaomian@huawei.com<mailto:zhenghaomian@huawei.com>>
抄送: ccamp@ietf.org<mailto:ccamp@ietf.org>
主题: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi,

“My understanding is that MSA/IA still uses vendor optics (component vendor). Is this correct?”

I’m not sure I understand this statement/question. What is the alternative? The optics must come from somewhere, whether it’s a standard interface of not.

/Jonas

From: Leeyoung <leeyoung@huawei.com<mailto:leeyoung@huawei.com>>
Sent: den 22 oktober 2018 20:48
To: Jonas Mårtensson <jonas.martensson@ri.se<mailto:jonas.martensson@ri.se>>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com>>; Beller, Dieter (Nokia - DE/Stuttgart) <dieter.beller@nokia.com<mailto:dieter.beller@nokia.com>>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <zhenghaomian@huawei.com<mailto:zhenghaomian@huawei.com>>
Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi Jonas,

My understanding is that MSA/IA still uses vendor optics (component vendor). Is this correct? If so, I would create leaf-list of identifiers that apply to any non-G.698.2 application code. Would this work for you?

Thanks.
Young

From: Jonas Mårtensson [mailto:jonas.martensson@ri.se]
Sent: Monday, October 22, 2018 1:39 PM
To: Leeyoung <leeyoung@huawei.com<mailto:leeyoung@huawei.com>>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com>>; Beller, Dieter (Nokia - DE/Stuttgart) <dieter.beller@nokia.com<mailto:dieter.beller@nokia.com>>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <zhenghaomian@huawei.com<mailto:zhenghaomian@huawei.com>>
Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi,

I would prefer Option 2 but rename “Open source specific” with “MSA/IA” (multi-source agreement / implementation agreement).

I don’t see why this should be part of “Vendor specific”, also considering that the organizations I referred to earlier have multiple operator members.

/Jonas

From: Leeyoung <leeyoung@huawei.com<mailto:leeyoung@huawei.com>>
Sent: den 22 oktober 2018 16:39
To: Jonas Mårtensson <jonas.martensson@ri.se<mailto:jonas.martensson@ri.se>>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com>>; Beller, Dieter (Nokia - DE/Stuttgart) <dieter.beller@nokia.com<mailto:dieter.beller@nokia.com>>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <zhenghaomian@huawei.com<mailto:zhenghaomian@huawei.com>>
Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi Daniele,

Option 1 sounds better to me.  Perhaps rename ‘Standard ITU’ with ‘G.698 application code’ and ‘non-standard’ with ‘vendor-specific’. Open-source specific is a part of vendor-specific category. Have you consulted Deborah on this issue? It would be good to know the direction of the WG on this issue.

Thanks,
Young


From: Jonas Mårtensson [mailto:jonas.martensson@ri.se]
Sent: Monday, October 22, 2018 6:26 AM
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com>>; Beller, Dieter (Nokia - DE/Stuttgart) <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>>
Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Out of curiosity, what or who decides what can be considered a “standard”?

/Jonas

From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com>>
Sent: den 22 oktober 2018 12:30
To: Jonas Mårtensson <jonas.martensson@ri.se<mailto:jonas.martensson@ri.se>>; Beller, Dieter (Nokia - DE/Stuttgart) <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>>
Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

That’s a good proposal Jonas, we could go for a third branch called “open source” maybe. That’s something that can’t be considered standard, so I’m fine with both the options:
Option 1:

  *   Standard ITU
  *   Non standard
Option 2:

  *   Standard ITU
  *   Vendor specific
  *   Open source specific.

Regarding the use cases that’s the first and I agree with that , but I understood there is also the willingness from operators to open up to scenarios in which transport from vendor A interworks with transponder from vendor B (over vendor A,B,C,D…)

BR
Daniele

From: Jonas Mårtensson <jonas.martensson@ri.se<mailto:jonas.martensson@ri.se>>
Sent: sabato 20 ottobre 2018 15:33
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com>>; Beller, Dieter (Nokia - DE/Stuttgart) <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>>
Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi all,

In addition to G.698.2 and ITU-T, what about referring to transponder interoperability specifications from other organizations, e.g. the Open ROADM MSA (100G DP-QPSK with Staircase FEC) and upcoming OIF 400ZR (400G DP-16QAM with Hamming SD-FEC + Staircase HD-FEC)?

Daniele, the scope defined in the draft under discussion is “to provide a Yang data model, which can be utilized by an MDSC to collect states of WSON impairment data from the Transport PNCs to enable impairment-aware optical path computation”. One use case that I see is computing all-optical paths between two transponders from vendor A over vendor B (+C+D+…) optical domains.

/Jonas

From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com>>
Sent: den 19 oktober 2018 21:25
To: Beller, Dieter (Nokia - DE/Stuttgart) <dieter.beller@nokia.com<mailto:dieter.beller@nokia.com>>; Leeyoung <leeyoung@huawei.com<mailto:leeyoung@huawei.com>>; Jonas Mårtensson <jonas.martensson@ri.se<mailto:jonas.martensson@ri.se>>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <zhenghaomian@huawei.com<mailto:zhenghaomian@huawei.com>>
Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

That should be the approach and I’m happy to see quite some alignment on that.
As Gert pointed out RFC7581 “provides a switch that enables non-standard implementations, but does not define them”. That is fine, it’s the switch we are talking about. That allows us continue working standard application codes as well as defining new non it code points.

--- end of chair statement and start of contributor mode

I wonder whether here we are speaking about vendor specific code points or rather operator specific code points.
if we speak about vendor specific code points this means that we most likely end up with Vendor 1 supporting code points A,B,C and vendor 2 supporting D,E,F.
IMHO it is pointless to have vendor specific code points if the final scope is having equipment from vendor A interwork with equipment form vendor B. Why a standard way of configuring proprietary parameters is needed at all?

What OTOH would be useful is a set of agreed code points that allow an operator to have two equipments from different vendors interwork in a non ITU-standard way.

BR
Daniele

From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> On Behalf Of Beller, Dieter (Nokia - DE/Stuttgart)
Sent: venerdì 19 ottobre 2018 17:51
To: Leeyoung <leeyoung@huawei.com<mailto:leeyoung@huawei.com>>; Jonas Mårtensson <jonas.martensson@ri.se<mailto:jonas.martensson@ri.se>>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <zhenghaomian@huawei.com<mailto:zhenghaomian@huawei.com>>
Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi Young, all,

I think that we need both, the G.698.2 application codes, which are standardized (standardized operational modes), and vendor-specific operational modes.

Operational modes represent optical transponder settings which have to be the same for the two optical transponders terminating a photonic tunnel or segment
in case the tunnel includes 3R regenerators.

The vendor-ID attribute should be of type string. We can further discuss this in Bangkok.


Thanks,
Dieter
On 16.10.2018 22:33, Leeyoung wrote:
Hi Dieter,

Thanks for providing good comments. Please see inline for my response.

Best regards,
Young

From: Beller, Dieter (Nokia - DE/Stuttgart) [mailto:dieter.beller@nokia.com]
Sent: Tuesday, October 16, 2018 6:57 AM
To: Jonas Mårtensson <jonas.martensson@ri.se><mailto:jonas.martensson@ri.se>; Leeyoung <leeyoung@huawei.com><mailto:leeyoung@huawei.com>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <zhenghaomian@huawei.com><mailto:zhenghaomian@huawei.com>
Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi Young, Jonas, all,

I checked again the YANG tree<https://github.com/younglee-ietf/actn-wson-flexi-grid/blob/master/ietf-optical-impairment-topology%402018-10-08.tree#L75> (ietf-optical-impairment-topology@2018-10-08.tree<mailto:ietf-optical-impairment-topology@2018-10-08.tree>) and particularly looked at the following augmentation:

  augment /nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point:
    +--rw transponder-id?         uint32
    +--ro available-modulation*   identityref
    +--rw modulation-enabled?     boolean
    +--rw modulation-type?        identityref
    +--ro available-FEC*          identityref
    +--rw FEC-enabled?            boolean
    +--rw FEC-type?               identityref
    +--ro FEC-code-rate?          decimal64
    +--rw FEC-threshold?          decimal64
    +--ro power?                  int32
    +--ro power-min?              int32
    +--ro power-max?              int32

these are clearly optical transponder attributes and I am wondering why the following grouping wson-ttp-attributes<https://github.com/younglee-ietf/actn-wson-flexi-grid/blob/master/ietf-optical-impairment-topology%402018-10-09.yang#L410> is not used:

  grouping wson-ttp-attributes {
     description
       "WSON tunnel termination point (e.g.tranponder) attributes";
        leaf-list available-operational-mode {
          type te-wson-types:operational-mode;
          description "List of all vendor-specific supported
          mode identifiers";
        }
        leaf operational-mode {
          type te-wson-types:operational-mode;
          description "Vendor-specific mode identifier";
        }
  }

This would make the optical transponder configuration attributes related to modulation and FEC obsolete.
YL>> Yes, we are discussing if the application codes are going to be used or not. If we are limited to application code usage, then you are correct.

A vendor-ID attribute has to be added because the operational modes vcan only be interpreted properly in the scope of a specific vendor.
YL>> Can you provide some idea as to vendor-ID attribute?

More discussion is also needed regarding power attributes.
YL>> Agree.

Thanks,
Dieter
On 16.10.2018 09:35, Jonas Mårtensson wrote:
Hi Young,

I had a look at the model in the github and I have some questions:

About modulation: You have DP_ (Dual Polarization) variants for QPSK and QAM16 but not for QAM8. Is that just an oversight? Also you have DC_ (Dual Carrier?) only for DP_QAM16. Why not for the others?

About link (fiber) attributes: since you added a number of attributes in the latest version (e.g. cd and pmd) why not also add loss and distance?

Specifically about link attribute “power”: The description now says “Total Input Power Level at the line port of the link”. In the previous version it said "Input Power Level of the receiver side of the link". So which side of the link does the attribute refer to? Why not include power level both at the transmit and receive sides? On the other hand, how is this attribute supposed to be used for path computation since the power level anyway does not represent the new connection (not yet setup) for which path computation is performed.

How are the “path” attributes (BER, etc.) meant to be used for path computation?

About transponder attributes: Why is the exact FEC-type needed for path computation? Would it not be sufficient to know the FEC-threshold? Another transponder attribute that could be useful to have is required OSNR (per modulation-type).

/Jonas

From: Leeyoung <leeyoung@huawei.com><mailto:leeyoung@huawei.com>
Sent: den 15 oktober 2018 19:03
To: Dieter Beller <Dieter.Beller@nokia.com><mailto:Dieter.Beller@nokia.com>; Jonas Mårtensson <jonas.martensson@ri.se><mailto:jonas.martensson@ri.se>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <zhenghaomian@huawei.com><mailto:zhenghaomian@huawei.com>
Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi Dieter,

What I meant a new scope of this draft is to combine flexi-grid with WSON (fixed-grid) as we discussed in the last week’s meeting. In regards to your point on separating the topology and the tunnel model, I agree. We haven’t got to the tunnel model yet. Please check the latest model in the github: https://github.com/younglee-ietf/actn-wson-flexi-grid

Please find the latest model per our meeting:
https://github.com/younglee-ietf/actn-wson-flexi-grid/blob/master/ietf-optical-impairment-topology%402018-10-09.yang

and its tree:
https://github.com/younglee-ietf/actn-wson-flexi-grid/blob/master/ietf-optical-impairment-topology%402018-10-08.tree

Thanks.
Young

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Monday, October 15, 2018 10:46 AM
To: Leeyoung <leeyoung@huawei.com<mailto:leeyoung@huawei.com>>; Jonas Mårtensson <jonas.martensson@ri.se<mailto:jonas.martensson@ri.se>>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <zhenghaomian@huawei.com<mailto:zhenghaomian@huawei.com>>
Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi Young, all,

it would be great if you could share the new scope on the list before you submit the new version. This will allow folks to send comments to the list.

One of my comments was that the current 00-draft is defining augmentations, which are TE-topology related, and other augmentations that are tunnel-related
not aligned with the current scope.

I would clearly prefer separate drafts for these 2 different categories.


Thanks,
Dieter
On 12.10.2018 16:14, Leeyoung wrote:
Hi Jonas,

Thanks for your comment. We are updating the draft including the change of the names and the scope. As Haomiana and Gabriele shared their view, we are trying to harmonize with other impairment-related work for GMPLS/WSON.

Thanks.
Young

From: Jonas Mårtensson [mailto:jonas.martensson@ri.se]
Sent: Friday, October 12, 2018 2:34 AM
To: Leeyoung <leeyoung@huawei.com><mailto:leeyoung@huawei.com>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <zhenghaomian@huawei.com><mailto:zhenghaomian@huawei.com>
Cc: 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,

Interesting draft. What is the relation to other WSON impairment drafts (wson-iv-info and wson-iv-encode)? Are you proposing a completely different approach here since you do not refer to those drafts?

/Jonas

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/



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-lee-ccamp-wson-impairment-yang-00

https://datatracker.ietf.org/doc/html/draft-lee-ccamp-wson-impairment-yang-00





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.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



_______________________________________________

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

Internet-Draft directories: http://www.ietf.org/shadow.html

or ftp://ftp.ietf.org/ietf/1shadow-sites.txt




_______________________________________________

CCAMP mailing list

CCAMP@ietf.org<mailto:CCAMP@ietf.org>

https://www.ietf.org/mailman/listinfo/ccamp



--

Dieter Beller
Open Agent & Routing Project Manager
IP/Optical Networks, Optics, Nokia

m : +49 175 7266874 | j: 8831186<ciscotel://8831186>
Dieter.Beller@nokia.com<mailto:Dieter.Beller@nokia.com>
Nokia Solutions and Networks GmbH & Co. KG
Lorenzstr. 10, 70435 Stuttgart
Sitz der Gesellschaft: München / Registered office: Munich
Registergericht: München / Commercial registry: Munich, HRA 88537
WEEE-Reg.-Nr.: DE 52984304
Persönlich haftende Gesellschafterin / General Partner: Nokia Solutions and Networks Management GmbH
Geschäftsleitung / Board of Directors: Dr. Wolfgang Hackenberg, Nils-Peter Daetz, Wilhelm Dresselhaus
Vorsitzender des Aufsichtsrats / Chairman of supervisory board: Hans-Jürgen Bill
Sitz der Gesellschaft: München / Registered office: Munich
Registergericht: München / Commercial registry: Munich, HRB 163416
This e-mail and its attachments, if any, may contain confidential information.
If you have received this e-mail in error, please notify us and delete or destroy the e-mail and its attachments, if any, immediately.
If you have received this e-mail in error, you must not forward or make use of the e-mail and its attachments, if any.