Re: [CCAMP] Connectivity-matrix in YANG models for WSON devices

Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Mon, 24 July 2017 14:30 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 80079131D69; Mon, 24 Jul 2017 07:30:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 rpMRySW-br-N; Mon, 24 Jul 2017 07:30:26 -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 111DF1316C3; Mon, 24 Jul 2017 07:30:24 -0700 (PDT)
X-AuditID: c1b4fb3a-bea2a9c000001b2f-73-5976047e35f3
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C5.86.06959.E7406795; Mon, 24 Jul 2017 16:30:23 +0200 (CEST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.81) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 24 Jul 2017 16:30:22 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kCATjGk96g1wIAF/8TMhV5CrLwbafajsm16coirC3Lc=; b=bI2A3gVNcD7qj3Uvuxfh+RgE/HpFZLKd0CFY+uI0ZFf10pxGRrX0fTdOBOSi/mCJG58ebJ2ECMkqYBocSD7z7t+CUuynl+kKrabh/uOezqCGP81jvzPtgEaqshK8zV/02ugXZY93A7tNVfOs5gQ0xGL0U45FIijkHhl1EBXnJkU=
Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0914.eurprd07.prod.outlook.com (10.162.36.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Mon, 24 Jul 2017 14:30:17 +0000
Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([fe80::8512:cee5:a76e:ebf7]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([fe80::8512:cee5:a76e:ebf7%13]) with mapi id 15.01.1304.011; Mon, 24 Jul 2017 14:30:17 +0000
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: Igor Bryskin <Igor.Bryskin@huawei.com>, Leeyoung <leeyoung@huawei.com>, "Dieter.Beller@nokia.com" <Dieter.Beller@nokia.com>, "ccamp@ietf.org" <ccamp@ietf.org>, "TEAS WG (teas@ietf.org)" <teas@ietf.org>
Thread-Topic: [CCAMP] Connectivity-matrix in YANG models for WSON devices
Thread-Index: AQHTAhNm45PUhEcPfkCBz5eI8YKk3KJeQaMAgAB5FICAALPjAIAAaVMAgAMuiQA=
Date: Mon, 24 Jul 2017 14:30:17 +0000
Message-ID: <AM2PR07MB0994BF2E1B831020D551622DF0BB0@AM2PR07MB0994.eurprd07.prod.outlook.com>
References: <705fac3d-bcfe-4e86-b854-4b9ab9434f39@nokia.com>, <7AEB3D6833318045B4AE71C2C87E8E172B3EF2BA@SJCEML702-CHM.china.huawei.com> <etPan.5972b74c.75686250.2b65@localhost> <7AEB3D6833318045B4AE71C2C87E8E172B3EFD38@SJCEML702-CHM.china.huawei.com> <0C72C38E7EBC34499E8A9E7DD007863909BAB172@SJCEML702-CHM.china.huawei.com>
In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863909BAB172@SJCEML702-CHM.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.40.1.108]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM2PR07MB0914; 7:nlXTn0qrQgYiTU3+V11HZ+apaZfCgyeKqBmSCy5QhaD8mebnG31OA0TjFjpMnABYBsPMkdpWsuxE8H+nIVXtvZ1zyl2oB9TWcjgee1C8OtjlTqQQCJFEnT779IiqFXHJidQT4CPf2nro5XgkPYasXPqz9dLJcpcaKdfuvAA2JbaUjGxgaa7nztpX0F1OpyfAlxmiAR2hHEkDBK84n+DOZ1hu9iHKI2s9IYivdhknczzvpuYLt3W0G6F1ydpJtIl/fpMnFI2zxJvZuUFBkJS3e2/bcXeoQrX8XFEvfYEwJoZQI3nZRAxFdm1Z+OLETB7FWLfIpd1zehizFCjRSj/DIt2P6y8mOipI2Cm9dMm92D4wGhXsZtZuM7sAaTVOYOYTi4FClMieLwANQ8c0M4XdlRVdFBram8dFpraO614cAH6eyb2VUhCM4zD8K3XRvc9jRPRtqHUeSbDoCGWOh93QjC0Do1V9Z7ayZRkmNQM52yoVihOiDSS5BNb7y0uOg+3ULGsa4gKXSEvGZh1Ax68tMKS1Owea/l+M+cKSAKQjnrLEJQB1RWBexbuICFttdK7x7fReZK3UiVf4KXzmLaUfLoFH8DJHjnwGMvLwKBMNSS4vgaBltZa3Rikr+X/cv0TBnisAipNo5yMbMIbqBpFx0GednbeJbGzXjoqoZRdQbxfLu6rGsQqxkVLax9L+4WPHzMulJesaWz5SNv6jfDAP9LXPrPzYvLu6aynKWB0lhlwcdNcIleIFlWV3IoRhIeBGdwOFAS44GFPUqEwNKXNa+CynfFzfUPd6yuC6y0xCjK0=
x-ms-office365-filtering-correlation-id: ccd9ccf7-5b6a-485b-11f8-08d4d2a081a8
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM2PR07MB0914;
x-ms-traffictypediagnostic: AM2PR07MB0914:
x-exchange-antispam-report-test: UriScan:(120809045254105)(131327999870524)(50582790962513)(82608151540597)(21748063052155);
x-microsoft-antispam-prvs: <AM2PR07MB091421830B5E2110E665BB2DF0BB0@AM2PR07MB0914.eurprd07.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR07MB0914; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR07MB0914;
x-forefront-prvs: 0378F1E47A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39850400002)(39410400002)(39860400002)(39840400002)(39400400002)(199003)(189002)(377454003)(377424004)(54356999)(76176999)(6306002)(54896002)(101416001)(6246003)(33656002)(53936002)(5660300001)(97736004)(66066001)(74316002)(3660700001)(6116002)(790700001)(102836003)(38730400002)(14454004)(9686003)(236005)(606006)(93886004)(53546010)(8936002)(50986999)(2950100002)(6436002)(189998001)(561944003)(55016002)(7736002)(229853002)(966005)(99286003)(105586002)(86362001)(25786009)(106356001)(5250100002)(2906002)(2900100001)(7696004)(478600001)(2201001)(2501003)(81166006)(81156014)(68736007)(3280700002)(3846002)(6506006)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0914; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM2PR07MB0994BF2E1B831020D551622DF0BB0AM2PR07MB0994eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2017 14:30:17.7017 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0914
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0iTURjGO99l+xwtjkvxzRRhEsWyTBFaUqmQZFDShWxKpEu/vF/Ypysl UiujFDWoLLs5ZXYxSlLT4TR1arkyvCWZlwi30FD/0cQs1Nq+T/C/33me55yH9+UwpKyZdmXi U9JZTYo6SS6SUKWqhmM7silt+K5yw3ql9eEQpXylH6WUS2YfZcnjYGXebwMVSIdc7ZihQ/T6 RSJkbLifOEpGSPbGsEnxWlbjvT9KEvdl7pcobbCZuHD7bkAOuvWAyEcODGA/mK430/lIwshw B4LF1iraZshwF4Ki4uM2g8KFJLS8uSyk7hBgnm0X8wcLghbrZ5SPGEaE/cFqOmzTnXAfgg9z OvtTG3EItLeNIxs74UPwqLeQ5DkUJr++tmcovAWKyrvtuhSfBl1JJ8UXdBNQVL1gv+yAw+BF caPYxgi7w01jhV0nsQsMW8uEgTDom3pInp3hp2WZ5vNnoTrPIGQ8YKzyIc2zO/SXFSBbGeDv IqiwmIXQEZifyiV5o4+Ab3dyBUMBH3uuCHwRfhd007bxASfCZP9xPm+i4frfEaHBDQp1RoEb RdBgzOI3zMLTl3noJlLcXzMEz6kw+a5SfN++DUcwl1opXvcCnXFWxPN2eFI+Ra5yd6uFWKvr kLgKOXMsxyXH+vruZDXx0RyXmrIzhU2vQf8/VVvdX38DapsIMiHMIPl6qWGdNlxGq7VcZrIJ AUPKnaTkTEa4TBqjzsxiNamRmowkljOhzQwld5EGvu1VyXCsOp1NZNk0VrPqEoyDaw7yWLdS F1cqmRd7ko0LG92y3QvaQ7XVj1tqlxOf/VR5nPc/kz3kGH2rvvZeqGJPRoTnvm1Mw4aEk8FT BzclJ3RePNeiavqze0PYiYnWH5cGU7cOjkQ9io40eU/PiKU3lhPGu+ZP+a0oBpRVZQPXDkjf +0/PP1/yUrWPlrA1QZ9caUuAnOLi1D4KUsOp/wHKAlNuUAMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/Gw9oa8QrZ_wzhKvtTAWhqylGocA>
Subject: Re: [CCAMP] Connectivity-matrix in YANG models for WSON devices
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 24 Jul 2017 14:30:28 -0000

Hi Igor, Young, all,

(adding TEAS)

> My doubt is if you can capture all tech specific properties for Optical (WSON/Flexi-grid) Device model in one type.

This shouldn't be done for 2 reasons:

  1.  Different WGs responsibility
  2.  Future extensibility.

The TE-Topology is ok, but there are too many technology specific extensions in the TE tunnel model in my opinion. I don't want to stop or slow down this work but I'd like not to see this overlap again in the future.

>Another question I have (similar to Italo's) is that would it be more sensible to keep techn specific TE types in each tech-specific layer rather than lumping all in one TE: type Yang model. If we need to add unforeseeable technology specific technology model later, tech specific TE: Type might have some benefit.
>IB>> As mentioned I like this proposal, but we need Xufeng to tell us whether this approach is feasible and how to make this happen

Couldn't agree more.

Thanks
Daniele

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: sabato 22 luglio 2017 15:26
To: Leeyoung <leeyoung@huawei.com>;; Dieter.Beller@nokia.com; ccamp@ietf.org
Subject: Re: [CCAMP] Connectivity-matrix in YANG models for WSON devices

Young,


From: Leeyoung
Sent: Saturday, July 22, 2017 3:09 AM
To: Igor Bryskin; Dieter.Beller@nokia.com<mailto:Dieter.Beller@nokia.com>; ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: RE: [CCAMP] Connectivity-matrix in YANG models for WSON devices

Hi Igor,

I understand your proposal for moving generic property like b/w, labels and others such as C.M. to TE:type where you specify all technology specific details in the groupings. My doubt is if you can capture all tech specific properties for Optical (WSON/Flexi-grid) Device model in one type. For instance, C.M. in Optical is a node property in which we have interfaces for WAN ports and may have interfaces to other elements within the node such as resource pools, etc.

IB>> I agree that CM i s a TE node's property describing the TE node's LTP to LTP switching limitations , which we believe (Dieter including)  we can describe in a generic way. The quantative  characteristics (cost vector)  of a CM entry can be layer specific (e.g. application code, available bandwidth spectrum, OSNR penalty, etc.), but this is a problem of modeling of TE paths (in this case intra-node TE paths connecting the restricted LTPs). There are multiple places where TE path is involved:

TE topology model:

-          node's detailed CM,

-          TTP's detailed LLCL,

-          underlay primary and  secondary TE paths

TE Tunnel model:


-          explicit EROs and their limits

-          computed EROs and their properties

-          provisioned EROs(RROs)

So the suggestion is to define TE path and iys layer specific properties just once and to use the grouping everywhere we need, rather than provide numerous separate explicit augmentations in the data stores, exactly the same reason why we are defang bandwidth  as a grouping (with layer specific choice statements) instead of generic type. In other words, TE path property grouping will include all the necessary layer specific attributes, hence the TE path could be used in all CM, LLCL, underlay nodes in TE topology model, explicit/computed paths in TE tunnel model (including its RPCs) without worrying which layer the TE path belongs tp.

But before we get into details, I'd like to see your proposed TE:Type for Connectivity Matrix; then Jorge and I can provide more meaningful feedback to you.

IB>> Don't understand why you worry about CM and ignore other places with exact same problem

Another question I have (similar to Italo's) is that would it be more sensible to keep techn specific TE types in each tech-specific layer rather than lumping all in one TE: type Yang model. If we need to add unforeseeable technology specific technology model later, tech specific TE: Type might have some benefit.

IB>> As mentioned I like this proposal, but we need Xufeng to tell us whether this approach is feasible and how to make this happen

Thanks.
Young



From: Igor Bryskin
Sent: Friday, July 21, 2017 10:25 PM
To: Leeyoung <leeyoung@huawei.com<mailto:leeyoung@huawei.com>>; Dieter.Beller@nokia.com<mailto:Dieter.Beller@nokia.com>; ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: Re: [CCAMP] Connectivity-matrix in YANG models for WSON devices

Young,
When you said you wanted to  augment  basic connectivity matrix to include, for example, application code on per CM entry basis, you really meant to augment TE path proprties with things like application code, OSNR at the edgges, etc. -detailed CM entry attributes.
This means that the same augmentation will be needed every time when a TE path is involved. This happens in multiple places in both TE Topology and Tunnel models. Thus it is much better to provide somehow just once layer specific choice statements for TE path properties and then use the grouping everywhere in both models - exactly the same argunent for defining the bandwidth  the way we did.

Igor
From:Leeyoung
To:Dieter Beller,ccamp@ietf.org,
Date:2017-07-21 09:12:16
Subject:Re: [CCAMP] Connectivity-matrix in YANG models for WSON devices

Hi Dieter,

Please see inline for my comment.

Thanks.
Young

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Friday, July 21, 2017 1:20 PM
To: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: [CCAMP] Connectivity-matrix in YANG models for WSON devices

Hi CCAMPers,

during the joint session an YANG and the CCAMP session yesterday, I commented that the following two drafts are defining a connectivity matrix in the
YANG models for WSON devices:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-yang/
https://datatracker.ietf.org/doc/draft-vergara-ccamp-flexigrid-yang/

I was suggesting to have a look at the definition of the connectivity-matrix in https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/ and re-use
that definition unless there are good reasons to define the connectivity matrix for WSON devices differently.
YL>> We have not finished the model. We will add a few items to the Conn. Matrix which are physical layer specific information augmentation. I can foresee the ports/interfaces in and out of the device may be associated with FEC/Modulation constraints and other impairment aspect as well. I also foresee within a device, we may have embedded resource pool models, etc. But as you say, anything has defined in the TE-topo will be augmented and we will only describe additional properties peculiar to optical.

Moreover, the connectivity-matrix of a WSON device (e.g. a ROADM) typically reflects the connectivity limitations of the wavelength selective switching
fabric of the device and hence should be read-only (ro) as opposed to read-writable (rw). Why would an operator further restrict  the connectivity
capabilities of a WSON device?
YL>> With the physical data added, there may be administrative issues where some restriction would apply. We don't have specific use-case at this moment, but leaving +rw may be sensible thing.

Thanks,
Dieter