Re: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23

Xufeng Liu <xliu@kuatrotech.com> Fri, 27 May 2016 13:51 UTC

Return-Path: <xliu@kuatrotech.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F1912D528 for <teas@ietfa.amsl.com>; Fri, 27 May 2016 06:51:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.811
X-Spam-Level:
X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=kuatrotechnology.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 pUHo46Yt_7MC for <teas@ietfa.amsl.com>; Fri, 27 May 2016 06:50:59 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0056.outbound.protection.outlook.com [104.47.2.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3A112B019 for <teas@ietf.org>; Fri, 27 May 2016 06:50:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ho/ZLybN1k3iNkclgegoD6znMNh6b7UPxo28s+JaUEU=; b=d5guA/ebb/J4eGGrs971ZWXfQGLoHab5ryovv273Xgc8yQEzj0hqXUH4talV88XjjkCyhFxw7urZGDGIePszj7xyZhYmeyXSNGXgrxLEcQhQByXTMBf2uyhqNSUVi8wwh6Pe4nrErEvKWq6pSRumGvo+tCAB13uPYUXzTIEX0jI=
Received: from VI1PR06MB1488.eurprd06.prod.outlook.com (10.164.86.30) by VI1PR06MB1487.eurprd06.prod.outlook.com (10.164.86.29) with Microsoft SMTP Server (TLS) id 15.1.506.2; Fri, 27 May 2016 13:50:53 +0000
Received: from VI1PR06MB1488.eurprd06.prod.outlook.com ([10.164.86.30]) by VI1PR06MB1488.eurprd06.prod.outlook.com ([10.164.86.30]) with mapi id 15.01.0506.009; Fri, 27 May 2016 13:50:53 +0000
From: Xufeng Liu <xliu@kuatrotech.com>
To: Igor Bryskin <Igor.Bryskin@huawei.com>, Leeyoung <leeyoung@huawei.com>, Vishnu Pavan Beeram <vbeeram@juniper.net>, Oscar Gonzalez De Dios <oscar.gonzalezdedios@telefonica.com>, Tarek Saad <tsaad@cisco.com>, Himanshu Shah <hshah@ciena.com>, Lou Berger <lberger@labn.net>, "BRUNGARD, DEBORAH A (ATTLABS)" <db3546@att.com>, Susan Hares <shares@ndzh.com>, "Zafar Ali (zali)" <zali@cisco.com>, "Khaddam, Mazen (CCI-Atlanta)" <Mazen.Khaddam@cox.com>, Tony Le <tonyle@juniper.net>, "BELOTTI, SERGIO (SERGIO)" <sergio.belotti@alcatel-lucent.com>, "Beller, Dieter (Dieter)" <dieter.beller@alcatel-lucent.com>, Rajan Rao <rrao@infinera.com>, "Zhangxian (Xian)" <zhang.xian@huawei.com>, "xufeng.liu.ietf@gmail.com" <xufeng.liu.ietf@gmail.com>, "Belotti, Sergio (Nokia - IT)" <sergio.belotti@nokia.com>, Anurag Sharma <AnSharma@infinera.com>
Thread-Topic: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23
Thread-Index: AdG3XGalY3SICAUtQf2LvT1Umc0SGwABG4MAAALVFfAABDuCwAADMsUQACUNjwA=
Date: Fri, 27 May 2016 13:50:52 +0000
Message-ID: <VI1PR06MB14884888E2B10749B965F661B1420@VI1PR06MB1488.eurprd06.prod.outlook.com>
References: <DBXPR06MB623990C55CF493EFF51421EB1410@DBXPR06MB623.eurprd06.prod.outlook.com> <7AEB3D6833318045B4AE71C2C87E8E172A88ECF3@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908EDD175@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A88EDAD@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908EDD212@dfweml501-mbx>
In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908EDD212@dfweml501-mbx>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=kuatrotech.com;
x-originating-ip: [98.191.72.170]
x-ms-office365-filtering-correlation-id: 4b6e4177-012f-4419-ea9c-08d38635eb85
x-microsoft-exchange-diagnostics: 1; VI1PR06MB1487; 5:Gm+o1EDbcmCwkcVs9cltbwNHJT+mmwVQu7XLBBwetbh/T/Y5H7SF6uNe1kwUSMdz0qCCBn4h6BJqNA93dYeK5+P/5DZlln9m8UztMSaf3ip/zIG6AFkWdzh5kfhrAxyoBbMuOz3eq77ndRDDjKS56Q==; 24:+QYUuoWftQsckdDQh+mOv9Dt1K7Vvqj8t6Ne6mypiSPuLyDzBhCX1qBpNKWeS+1sagL9FUfFW8sNyklcF7E+DYVAugzCH5/0H2Zby/MaNnQ=; 7:bFmU2svCUUNXD8XmDZGdrTOmSYld1nO2WkcnEmOfEGisHvmAY6Jixs9RFzh8p/Sqwq2xgFaBWiYRNI94sZ01TFBot2Tgjt0ds8DQrf/LoZwbOhSvFOphdRejapg+S8kYordrxYtrSOI7ZY1L6Q2CVXkJ5m+L7z1C5Eo2SArHo6TgMwxo4B5dNAmo3LQh5GXX
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR06MB1487;
x-microsoft-antispam-prvs: <VI1PR06MB1487ACE469A8EF01C7D7F31AB1420@VI1PR06MB1487.eurprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(40392960112811)(158342451672863)(50582790962513)(82608151540597)(97927398514766)(95692535739014)(136967371223342)(138986009662008)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041072)(6043046); SRVR:VI1PR06MB1487; BCL:0; PCL:0; RULEID:; SRVR:VI1PR06MB1487;
x-forefront-prvs: 09555FB1AD
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377424004)(377454003)(76104003)(5423002)(76576001)(2906002)(9326002)(50986999)(76176999)(230783001)(3280700002)(92566002)(93886004)(122556002)(3660700001)(54356999)(10400500002)(8936002)(19580405001)(81166006)(8666003)(5004730100002)(8676002)(16236675004)(17750500001)(19580395003)(1220700001)(5001770100001)(33656002)(74316001)(586003)(87936001)(189998001)(77096005)(6116002)(790700001)(86362001)(9686002)(2501003)(19625215002)(2900100001)(5002640100001)(2950100001)(3846002)(4326007)(66066001)(19300405004)(102836003)(5003600100002)(15975445007)(11100500001)(5008740100001)(7059030)(921003)(1121003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR06MB1487; H:VI1PR06MB1488.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR06MB14884888E2B10749B965F661B1420VI1PR06MB1488eurp_"
MIME-Version: 1.0
X-OriginatorOrg: kuatrotech.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2016 13:50:52.6088 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR06MB1487
Archived-At: <http://mailarchive.ietf.org/arch/msg/teas/6s7rdbiB1sYftJLzY4xjd0IXfSE>
Cc: "teas@ietf.org" <teas@ietf.org>
Subject: Re: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 May 2016 13:51:03 -0000

Hi Young,

More below.
Thanks,

- Xufeng

From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: Thursday, May 26, 2016 4:18 PM
To: Leeyoung <leeyoung@huawei.com>; Xufeng Liu <xliu@kuatrotech.com>; Vishnu Pavan Beeram <vbeeram@juniper.net>; Oscar Gonzalez De Dios <oscar.gonzalezdedios@telefonica.com>; Tarek Saad <tsaad@cisco.com>; Himanshu Shah <hshah@ciena.com>; Lou Berger <lberger@labn.net>; BRUNGARD, DEBORAH A (ATTLABS) <db3546@att.com>; Susan Hares <shares@ndzh.com>; Zafar Ali (zali) <zali@cisco.com>; Khaddam, Mazen (CCI-Atlanta) <Mazen.Khaddam@cox.com>; Tony Le <tonyle@juniper.net>; BELOTTI, SERGIO (SERGIO) <sergio.belotti@alcatel-lucent.com>; Beller, Dieter (Dieter) <dieter.beller@alcatel-lucent.com>; Rajan Rao <rrao@infinera.com>; Zhangxian (Xian) <zhang.xian@huawei.com>; xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT) <sergio.belotti@nokia.com>; Anurag Sharma <AnSharma@infinera.com>
Cc: teas@ietf.org
Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23

Young,

"Another question on the TTP, can REG/WC (Wavelength Converter) element be considered as a type of the TTP? If so, I think TTP can be generalized to include Transponders and REG/WC elements."

One important role of TTP is to represent topologically a client/server layer adaptor to facilitate inter-layer path computations. REG/WC has no adaptation capabilities.
WDM augmentation could IMHO model REG/WC as a TTP with no adaptation caps, however, because this is only pertinent to OCh layer, it should not be part of the basic TE topology model.

Igor

From: Leeyoung
Sent: Thursday, May 26, 2016 2:58 PM
To: Igor Bryskin; Xufeng Liu; Vishnu Pavan Beeram; Oscar Gonzalez De Dios; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com<mailto:xufeng.liu.ietf@gmail.com>; Belotti, Sergio (Nokia - IT); Anurag Sharma
Cc: teas@ietf.org<mailto:teas@ietf.org>
Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23

Hi Igor,

Thanks for your comments.

In OTN, if you consider ODUk as labels, I am fine with that. I thought ODUk is more or less Switching/Encoding in the ISCD Link model than a label.

Youmg,


Thanks.
Young

From: Igor Bryskin
Sent: Thursday, May 26, 2016 11:44 AM
To: Leeyoung; Xufeng Liu; Vishnu Pavan Beeram; Oscar Gonzalez De Dios; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com<mailto:xufeng.liu.ietf@gmail.com>; Belotti, Sergio (Nokia - IT); Anurag Sharma
Cc: teas@ietf.org<mailto:teas@ietf.org>
Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23

Hi Young,

Please, see in-line,

Igor

From: Leeyoung
Sent: Thursday, May 26, 2016 11:31 AM
To: Xufeng Liu; Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com<mailto:xufeng.liu.ietf@gmail.com>; Belotti, Sergio (Nokia - IT); Anurag Sharma
Cc: teas@ietf.org<mailto:teas@ietf.org>
Subject: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23

Hi Xufeng,

Thanks for this update. Your notes are always very helpful to understand the latest progress of this draft.

I have a few questions on the potentially adding model for labels for the connectivity matrix.


1.      You said:


               For each label
               o exclusivity (true/false)

Do you mean this bitmap?
[Xufeng] This is the LINK_LABEL_EXCLUSIVITY in RFC 7579.


2.      Are you aware of label restrictions applied for the connectivity matrix other than WSON? If so, then this model addition makes sense; if not, then we can add the label model for the connectivity matrix in the WSON YANG model. If the extent to which label model addition is not really a major constraint in the switching technologies other than WSON, it would be worthwhile to evaluate if we should do label restriction model in a generic way (per this draft) or do it in WSON specific way?  I am not aware of any label restriction model for the connectivity matrix for GMPLS other than WSON.
IB>> We had this discussion many time already. There are physical OTN switches that have constraints on the ODUk type level. For example, a switch can switch ODU2 from link 1 to link2, but ODU2e from link 1 to only link3. This is especially true for abstract compound nodes which may represent entire network domains. As you know abstract TE modes are very important for this model. So, no, connectivity restriction on a label level does not apply only to WDM.




3.       If we were to extend the label model for the connectivity matrix, I would think we also need to have label restriction model for TTP LLCL as well. What do you think?
IB>> This is actually a good point. Thanks for pointing out.

Cheers,
Igor


Thanks.
Young


From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Xufeng Liu
Sent: Thursday, May 26, 2016 9:48 AM
To: Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); xufeng.liu.ietf@gmail.com<mailto:xufeng.liu.ietf@gmail.com>; Belotti, Sergio (Nokia - IT); Anurag Sharma
Cc: teas@ietf.org<mailto:teas@ietf.org>
Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23

Participants:
Igor, Xufeng, Pavan, Dieter, Sergio, Himanshu

- Information sources
  > Discussed two use cases related to information sources:
    1) Provider applies policies to pick the most preferred.
    2) Provider does not apply policies and the decision is done by customer.
  > The model currently supports 1) well, but is not clear on 2).
  > Agreed to clarify the model by:
    1) Change "alt-information-sources" to "information-sources" to
       include all sources, including the selected one.
    2) For use case 1), the applied attribute has the selected value, and
       "information-sources" list all available sources.
       For use case 2), the applied attribute does not have value, and
       "information-sources" list all available sources.

- Connectivity Matrix
  > Discussed the comment from Cyril "to add a Label (Following
    RFC7579) restrictions".
  > Participants agreed that such constraint information is useful.
  > Participants agreed that such constraint information is generic
    enough to be used in various layers and use cases, including optical
    OTN, and abstract network topologies.
  > Participants agreed to send the suggestion TEAS WG to add such
    information to te-topology model.
  > The potential model change can be:
    For each connectivity-matrix entry, add:
      list of labels
        list types
               o inclusive-list
               o exclusive-list
               o inclusive-range
               o exclusive-range
               For each label
               o exclusivity (true/false)

Working members: please provide any comments.

Thanks,

- Xufeng

Note: Please drop me an email if you need an invite for joining the weekly call.

PS. Meeting on May 30 will be canceled for US holiday.