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

Igor Bryskin <> Fri, 21 July 2017 20:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 857CC129B61 for <>; Fri, 21 Jul 2017 13:25:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4hPZuH-7Gl4M for <>; Fri, 21 Jul 2017 13:25:15 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 668A3124E15 for <>; Fri, 21 Jul 2017 13:25:14 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id DLA46392; Fri, 21 Jul 2017 20:25:12 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 21 Jul 2017 21:25:11 +0100
Received: from ([]) by ([]) with mapi id 14.03.0301.000; Fri, 21 Jul 2017 13:25:04 -0700
From: Igor Bryskin <>
To: Leeyoung <>, "" <>, "" <>
Thread-Topic: [CCAMP] Connectivity-matrix in YANG models for WSON devices
Thread-Index: AQHTAhNiK05vBTcKf0eruRs6wCNo3qJetvwAgAADuy0=
Date: Fri, 21 Jul 2017 20:25:03 +0000
Message-ID: <etPan.5972b74c.75686250.2b65@localhost>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_etPan5972b74c756862502b65localhost_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59726329.0039, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 136eab6cf547b90a8834d33b3bbdc435
Archived-At: <>
Subject: Re: [CCAMP] Connectivity-matrix in YANG models for WSON devices
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Jul 2017 20:25:17 -0000

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.

To:Dieter Beller,,
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.


From: CCAMP [] On Behalf Of Dieter Beller
Sent: Friday, July 21, 2017 1:20 PM
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:

I was suggesting to have a look at the definition of the connectivity-matrix in 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.