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

Leeyoung <> Thu, 26 May 2016 15:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A850F12D724 for <>; Thu, 26 May 2016 08:31:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.644
X-Spam-Status: No, score=-5.644 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, 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=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 59xtdplutRLG for <>; Thu, 26 May 2016 08:31:30 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9DA6212D722 for <>; Thu, 26 May 2016 08:31:20 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id CPQ59584; Thu, 26 May 2016 15:31:18 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 26 May 2016 16:31:16 +0100
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Thu, 26 May 2016 08:31:08 -0700
From: Leeyoung <>
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)" <>, "" <>, "Belotti, Sergio (Nokia - IT)" <>, Anurag Sharma <>
Thread-Topic: IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23
Thread-Index: AdG3XGalY3SICAUtQf2LvT1Umc0SGwABG4MA
Date: Thu, 26 May 2016 15:31:08 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172A88ECF3@dfweml501-mbx>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E172A88ECF3dfweml501mbx_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.574716C6.0150, 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: d1c10d952ca2cdf6985ba037fa1f913d
Archived-At: <>
Cc: "" <>
Subject: Re: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 May 2016 15:31:33 -0000

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?

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.

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?


From: Teas [] 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);; Belotti, Sergio (Nokia - IT); Anurag Sharma
Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-05-23

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.


- 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.