Re: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-06-13

Xufeng Liu <xliu@kuatrotech.com> Wed, 22 June 2016 20:30 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 BC39A12D685 for <teas@ietfa.amsl.com>; Wed, 22 Jun 2016 13:30:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 bugb2yLLHEsO for <teas@ietfa.amsl.com>; Wed, 22 Jun 2016 13:30:05 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0059.outbound.protection.outlook.com [104.47.2.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C959312D66C for <teas@ietf.org>; Wed, 22 Jun 2016 13:30:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=H65bViIPqddTEdb11F2Yk60Ol6Yio84ZXwvsKUo9hAE=; b=xOiaDmd59mwy3ZTTa0jLXHEMAzzSz0l05HocOX+2d/ftz8ZE0E449LpJsVrs7eKObrro6jqdwXQWEDzUv1tapEJqlKEwo9k48fyAnOZF8fZvdLUryFop7S7tjUciO2sHcma+S+6QKGbtFeuO8RFsCf74PliqMuvxO0eoyX45sjo=
Received: from VI1PR06MB1488.eurprd06.prod.outlook.com (10.164.86.30) by VI1PR06MB1488.eurprd06.prod.outlook.com (10.164.86.30) with Microsoft SMTP Server (TLS) id 15.1.523.4; Wed, 22 Jun 2016 20:30:00 +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.0523.015; Wed, 22 Jun 2016 20:29:59 +0000
From: Xufeng Liu <xliu@kuatrotech.com>
To: Xufeng Liu <xliu@kuatrotech.com>, Vishnu Pavan Beeram <vbeeram@juniper.net>, Igor Bryskin <Igor.Bryskin@huawei.com>, 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-06-13
Thread-Index: AdHIxUMMAasegqAwRm+k9LcVSoE0ZAD/X6ZA
Date: Wed, 22 Jun 2016 20:29:58 +0000
Message-ID: <VI1PR06MB1488321471B9183F07ED5B9DB12C0@VI1PR06MB1488.eurprd06.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=xliu@kuatrotech.com;
x-originating-ip: [98.191.72.170]
x-ms-office365-filtering-correlation-id: c4281384-902d-46a3-e438-08d39adbfb99
x-microsoft-exchange-diagnostics: 1; VI1PR06MB1488; 6:uCzIJllC+UqnJ9fLvpLla/C+q+TXcwQh3yxBiz3Vdb3Ej8cl7VTfMRetcGNf1xT8F2lQsxQOihJ1x+x95U3vjqWG4xCk/l8bp8CKBd0jE99S12yHxYy+P9eqlqgELY50z0pO+D8Wvr09strvpS4Bv2ndEZbezMT2ab5TWuHAvp6WeJOl3kjwHvsjmv9Mom51ldCwOsFAnbiZKF4D9q5nznQ1xjagq1ak0l+uyRS7d+7UPkBhyhA5KhhOuBjx2sTS3PTFqkf/u8ZO0cp0+PeaC+1K1syZYneoycR8dhNJPLCrrKFMgajFbQ10tldjvoBkEweGFU6B0sjRXSLdUrauBw==; 5:WKqhpB1q9HkJ3ZsT7GKWnXdU0sXMY0RFH0GiOJ6Pohw3R6GCMgG6pUsc3AeceapdASoACt9uG6NvI1SIE/faFUS541RGl2vtAr8fRDb2n2849PoZYOsBdtN6GtPexA8jnYUTK0bZPugPyz35g/NCpA==; 24:yFxEXnuxjEDUuNV2t+THre/ea0sckm77mmLBoxBWmlPToIsTPx7v/qw7pVpotFfLYAM0lHa9NIL71cTh21GZXFah8bIe2HNIPBLphtF1Bl8=; 7:v72hWXEzXm9OZYXJ4WIop2cXW4x+ECm2I2dcrJMbqmt7cjs6BK+pUDXJDAHhzOxVmfFopWyg7KjoK5fSIPVf8fFQgPV5Hk7s72K+kWxxHPsUc037JwIbUjHpVtf4ZxKge5E04Vr86nMBbihwnXZ5AVwwg4S1a1xCg2C2dyHWG+D2mJX0aFgHcAppfAJQiHTTsipgUFWQ1bUQzy5ljW8T9VOme3vLu11k20Rzyh3rt4Ys3QBPaqtc3g4W4FGoklNxnyvzaM/gLzpRxdU2pzhQWQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR06MB1488;
x-microsoft-antispam-prvs: <VI1PR06MB148837AD6792127E7520B022B12C0@VI1PR06MB1488.eurprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(40392960112811)(158342451672863)(138986009662008)(82608151540597)(97927398514766)(95692535739014)(136967371223342)(17755550239193)(50582790962513)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041072)(6043046); SRVR:VI1PR06MB1488; BCL:0; PCL:0; RULEID:; SRVR:VI1PR06MB1488;
x-forefront-prvs: 0981815F2F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377424004)(189002)(5423002)(377454003)(199003)(122556002)(8676002)(50986999)(2900100001)(8666005)(92566002)(2906002)(74316001)(86362001)(15975445007)(87936001)(790700001)(586003)(106356001)(102836003)(3846002)(5002640100001)(16236675004)(3900700001)(6116002)(19580405001)(1941001)(105586002)(3280700002)(19580395003)(5001770100001)(19625215002)(8936002)(2501003)(68736007)(81156014)(230783001)(66066001)(5003600100003)(77096005)(189998001)(97736004)(9686002)(10400500002)(7846002)(33656002)(4326007)(76576001)(54356999)(3660700001)(19300405004)(81166006)(7696003)(101416001)(7736002)(7059030)(921003)(1121003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR06MB1488; H:VI1PR06MB1488.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: kuatrotech.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR06MB1488321471B9183F07ED5B9DB12C0VI1PR06MB1488eurp_"
MIME-Version: 1.0
X-OriginatorOrg: kuatrotech.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2016 20:29:59.2438 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR06MB1488
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/cY0UIysZOMYL18qPXy1QzYpG9iM>
Cc: "teas@ietf.org" <teas@ietf.org>
Subject: Re: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-06-13
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: Wed, 22 Jun 2016 20:30:09 -0000

Participants:
Igor, Xufeng, Pavan, Sergio, Mateusz, Manali, Dieter, Tarek, Oscar, Anurag

- Preparing draft update
  > Dieter described multi-layer and transitional link.

3.2. TE Node
...
ADD:
Multi-layer TE nodes providing switching functions at multiple network layers are an example where a physical node can be decomposed into multiple logical TE nodes (fractions of a node). Some of these (logical) TE nodes may reside in the client layer TE topology while the remaining TE nodes belong to the server layer TE topology.

ADD:
3.4.  Transitional TE Link for Multi-layer Topologies
Networks are typically composed of multiple network layers where one or multiple signals in the client layer network can be multiplexed and encapsulated into a server layer signal. The server layer signal can be carried in the server layer network across multiple nodes until the server layer signal is terminated and the client layer signals reappear in the node that terminates the server layer signal. Examples of multi-layer networks are: IP over MPLS over Ethernet, low order ODUk signals multiplexed into a high order ODUl (l>k) carried over an OCh signal (optical transport network).
TE links as defined in 3.3. can be used to represent links within a network layer. In case of a multi-layer network, nodes and TE links only allow representation of each network layer as a separate TE topology Each of these single layer TE topologies would be isolated from their client and their server layer TE topology, if present (the highest and the lowest network layer in the hierarchy only have a single adjacent layer below or above, respectively). Multiplexing of client layer signals and encapsulating them into a server layer signal requires a function that is provided inside a node (typically realized in hardware). This function is also called layer transition.
One of the key requirements for path computation is to be able to calculate a path between two endpoints across a multi-layer network based on the TE topology representing this multi-layer network. This means that an additional TE construct is needed that represents potential layer transitions in the multi-layer TE-topology that connects the TE-topologies representing each separate network layer. The so-called transitional TE link is such a construct and it represents the layer transition function residing inside a node that is decomposed into multiple logical nodes that are represented as TE nodes. Hence, a transitional TE link connects a client layer node with a server layer node. A TE link as defined in 3.3. has LTPs of exactly the same kind on each link end whereas the transitional TE link has client layer LTPs on the client side of the transitional link and in most cases a single server layer LTP on the server side. It should be noted that transitional links are a helper construct in the multi-layer TE topology and they only exist as long as they are not in use (as they represent potential connectivity). When the server layer trail has been established between the server layer LTP of two transitional links in the server layer network, the resulting client layer link in the data plane will be represented as a normal TE link in the client layer topology. The transitional TE links will re-appear when the server layer trail has been torn down.
Figure: to be added


  > To add more descriptions to node-id.

- Discussed inter-domain Access link
  > Agreed to add an attribute "plug-id" on an access link, to facilitate the topology merge of a customized TE topology and the  client's native TE topology.
  > Debated the attribute type: uint32, uri, or string?
  > Will ask WG for comments.

- Router ID
  > Fix the format to use the type "dotted-quad".

- Discussed event notification
  > We currently have notifications for node and link. There is a comment about if we need more.
  > Agreed to use pub-sub mechanism as much as we can. Hopefully we don't need any more. Will confirm.

Thanks,

- Xufeng

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

From: Xufeng Liu
Sent: Friday, June 17, 2016 2:24 PM
To: 'Xufeng Liu' <xliu@kuatrotech.com>; 'Vishnu Pavan Beeram' <vbeeram@juniper.net>; 'Igor Bryskin' <Igor.Bryskin@huawei.com>; '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>
Cc: 'teas@ietf.org' <teas@ietf.org>
Subject: IETF TE Topology YANG Model Design Meeting Notes - 2016-06-13

Participants:
Igor, Xufeng, Pavan, Sergio, Mateusz, Manali, Dieter, Anurag, Tarek, Oscar

- Connectivity Matrix
  > Continued last week's discussion on label restrictions.
  > Agreed on model changes:

       |     +--rw connectivity-matrix* [id]
       |     |  +--rw id                         uint32
       |     |  +--rw from
       |     |  |  +--rw tp-ref?   leafref
@@ -209,6 +209,11 @@ augment /nw:networks/nw:network/nw:node:
       |     |  +--rw to
       |     |  |  +--rw tp-ref?   leafref
       |     |  +--rw is-allowed?                boolean
+      |     |  +--rw label-restriction* [inclusive-exclusive label-start]
+      |     |  |  +--rw inclusive-exclusive    enumeration
+      |     |  |  +--rw label-start            binary
+      |     |  |  +--rw label-end?             binary
+      |     |  |  +--rw range-bitmap?          binary
       |     |  +--rw max-link-bandwidth?        decimal64
       |     |  +--rw max-resv-link-bandwidth?   decimal64
       |     |  +--rw unreserved-bandwidth* [priority]
@@ -262,6 +267,11 @@ augment /nw:networks/nw:network/nw:node:
       |  |  |  +--ro to
       |  |  |  |  +--ro tp-ref?   leafref
       |  |  |  +--ro is-allowed?                boolean
+      |  |  |  +--ro label-restriction* [inclusive-exclusive label-start]
+      |  |  |  |  +--ro inclusive-exclusive    enumeration
+      |  |  |  |  +--ro label-start            binary
+      |  |  |  |  +--ro label-end?             binary
+      |  |  |  |  +--ro range-bitmap?          binary
       |  |  |  +--ro max-link-bandwidth?        decimal64
       |  |  |  +--ro max-resv-link-bandwidth?   decimal64
       |  |  |  +--ro unreserved-bandwidth* [priority]
@@ -326,6 +336,11 @@ augment /nw:networks/nw:network/nw:node:
       |     |  +--ro to
       |     |  |  +--ro tp-ref?   leafref
       |     |  +--ro is-allowed?                boolean
+      |     |  +--ro label-restriction* [inclusive-exclusive label-start]
+      |     |  |  +--ro inclusive-exclusive    enumeration
+      |     |  |  +--ro label-start            binary
+      |     |  |  +--ro label-end?             binary
+      |     |  |  +--ro range-bitmap?          binary
       |     |  +--ro max-link-bandwidth?        decimal64
       |     |  +--ro max-resv-link-bandwidth?   decimal64
       |     |  +--ro unreserved-bandwidth* [priority]
@@ -371,6 +386,11 @@ augment /nw:networks/nw:network/nw:node:
          |  +--rw protection-type?          identityref
          |  +--rw termination-capability* [link-tp]
          |     +--rw link-tp              leafref
+         |     +--rw label-restriction* [inclusive-exclusive label-start]
+         |     |  +--rw inclusive-exclusive    enumeration
+         |     |  +--rw label-start            binary
+         |     |  +--rw label-end?             binary
+         |     |  +--rw range-bitmap?          binary

- Continued to discuss optmization options (cost, delay)
  > Model changes:

@@ -337,6 +337,24 @@ module ietf-te-topology {
   /*
    * Identities
    */
+  identity te-optimization-criterion {
+    description
+      "Base identity for TE optimization criterion.";
+    reference
+      "RFC3272: Overview and Principles of Internet Traffic
+       Engineering.";
+  }
+
+  identity cost {
+    base te-optimization-criterion;
+    description "Optimized on cost.";
+  }
+
+  identity delay {
+    base te-optimization-criterion;
+    description "Optimized on delay.";
+  }

+  identity not-optimized {
+    base te-optimization-criterion;
+    description "Optimization is not applied.";
+  }

@@ -180,7 +180,8 @@ augment /nw:networks/nw:network:
       |  |     +--rw start?               yang:date-and-time
       |  |     +--rw schedule-duration?   string
       |  |     +--rw repeat-interval?     string
-      |  +--rw preference?   uint8
+      |  +--rw preference?               uint8
+      |  +--rw optimization-criterion?   identityref
       +--ro state
          +--ro schedules
          |  +--ro schedule* [schedule-id]
@@ -188,7 +189,8 @@ augment /nw:networks/nw:network:
          |     +--ro start?               yang:date-and-time
          |     +--ro schedule-duration?   string
          |     +--ro repeat-interval?     string
-         +--ro preference?   uint8
+         +--ro preference?               uint8
+         +--ro optimization-criterion?   identityref

- Prepare draft
  > Dieter to describe multi-layer and transitional link.

Thanks,

- Xufeng