Re: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-09-12
Igor Bryskin <Igor.Bryskin@huawei.com> Mon, 19 September 2016 12:18 UTC
Return-Path: <Igor.Bryskin@huawei.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 88380127735 for <teas@ietfa.amsl.com>; Mon, 19 Sep 2016 05:18:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.536
X-Spam-Level:
X-Spam-Status: No, score=-6.536 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=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 vI7rPmt_q21s for <teas@ietfa.amsl.com>; Mon, 19 Sep 2016 05:18:34 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AC8F12B051 for <teas@ietf.org>; Mon, 19 Sep 2016 05:18:33 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CWL35235; Mon, 19 Sep 2016 12:18:27 +0000 (GMT)
Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 19 Sep 2016 13:18:20 +0100
Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Mon, 19 Sep 2016 05:18:10 -0700
From: Igor Bryskin <Igor.Bryskin@huawei.com>
To: "Zhangxian (Xian)" <zhang.xian@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>, "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-09-12
Thread-Index: AdIPlNPZbbDC05QkQN2PhGOqOOswgQByl0AwAEQdMiA=
Date: Mon, 19 Sep 2016 12:18:10 +0000
Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F066AA@dfweml501-mbx>
References: <AM5PR0601MB2641B92135374262B8B5F855B1F00@AM5PR0601MB2641.eurprd06.prod.outlook.com> <C636AF2FA540124E9B9ACB5A6BECCE6B7DF3C0E1@SZXEMA512-MBS.china.huawei.com>
In-Reply-To: <C636AF2FA540124E9B9ACB5A6BECCE6B7DF3C0E1@SZXEMA512-MBS.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.254.228]
Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F066AAdfweml501mbx_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.57DFD795.0182, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: a92d2e9d66c8f29405c223753ae3b6b7
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/M2qOiO4eh11kEg8hXPLiclfQTiE>
Cc: "teas@ietf.org" <teas@ietf.org>
Subject: Re: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-09-12
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: Mon, 19 Sep 2016 12:18:37 -0000
Hi Xian, The ODUk counters will be on per priority level, correct? Igor From: Zhangxian (Xian) Sent: Saturday, September 17, 2016 11:53 PM 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; xufeng.liu.ietf@gmail.com; Belotti, Sergio (Nokia - IT); Anurag Sharma Cc: teas@ietf.org Subject: Re: IETF TE Topology YANG Model Design Meeting Notes - 2016-09-12 Hi, Xufeng, All, Thanks for the minutes. For the following point: “ > The data type "decimal64" is not convenient for OTN because the bandwidth is desired to be expressed as the number of channels, like 2 ODU1's. Participants agreed to suggest an augmentation in the OTN model, and not to change this model. “ We do plan to update the OTN topology model to include this information: augment /nd:networks/nd:network/lnk:link/tet:te/tet:config: +--rw available-odu-info* [odu-type] | +--rw odu-type identityref | +--rw number? uint16 Any comments are welcome. Another point related to this discussion: I notice the following attributes in TE-topology model: should they be removed? | +--rw time-division-multiplex-capable | +--rw minimum-lsp-bandwidth? decimal64 | +--rw indication? enumeration Regards, Xian 发件人: Xufeng Liu [mailto:xliu@kuatrotech.com] 发送时间: 2016年9月16日 5:14 收件人: 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; Belotti, Sergio (Nokia - IT); Anurag Sharma 抄送: teas@ietf.org 主题: IETF TE Topology YANG Model Design Meeting Notes - 2016-09-12 Participants: Igor, Xufeng, Anurag, Dieter, Sergio - Discussed attributes that are potentially technology specific. > Dieter has sent an email describing a list of such attributes. > Participants discussed the list. > The following section is not applicable to non-packet networks such as OCH and OTN, because the delay and bandwidth variations do not exist. We will move the section to packet augmentation: | +-rw performance-metric-throttle {te-performance-metric}? | | +-rw unidirectional-delay-offset? uint32 | | +-rw measure-interval? uint32 | | +-rw advertisement-interval? uint32 | | +-rw suppression-interval? uint32 | | +-rw threshold-out | | | +-rw unidirectional-delay? uint32 | | | +-rw unidirectional-min-delay? uint32 | | | +-rw unidirectional-max-delay? uint32 | | | +-rw unidirectional-delay-variation? uint32 | | | +-rw unidirectional-packet-loss? decimal64 | | | +-rw unidirectional-residual-bandwidth? decimal64 | | | +-rw unidirectional-available-bandwidth? decimal64 | | | +-rw unidirectional-utilized-bandwidth? decimal64 | | +-rw threshold-in | | | +-rw unidirectional-delay? uint32 | | | +-rw unidirectional-min-delay? uint32 | | | +-rw unidirectional-max-delay? uint32 | | | +-rw unidirectional-delay-variation? uint32 | | | +-rw unidirectional-packet-loss? decimal64 | | | +-rw unidirectional-residual-bandwidth? decimal64 | | | +-rw unidirectional-available-bandwidth? decimal64 | | | +-rw unidirectional-utilized-bandwidth? decimal64 | | +-rw threshold-accelerated-advertisement | | +-rw unidirectional-delay? uint32 | | +-rw unidirectional-min-delay? uint32 | | +-rw unidirectional-max-delay? uint32 | | +-rw unidirectional-delay-variation? uint32 | | +-rw unidirectional-packet-loss? decimal64 | | +-rw unidirectional-residual-bandwidth? decimal64 | | +-rw unidirectional-available-bandwidth? decimal64 | | +-rw unidirectional-utilized-bandwidth? decimal64 To retain the delay information, add the following: delay-metric? uint32 > The data type "decimal64" is not convenient for OTN because the bandwidth is desired to be expressed as the number of channels, like 2 ODU1's. Participants agreed to suggest an augmentation in the OTN model, and not to change this model. | +-rw interface-switching-capability* [switching-capability] | | +-rw switching-capability identityref | | +-rw encoding? identityref | | +-rw max-lsp-bandwidth* [priority] | | | +-rw priority uint8 | | | +-rw bandwidth? decimal64 | +-rw max-link-bandwidth? decimal64 | +-rw max-resv-link-bandwidth? decimal64 | +-rw unreserved-bandwidth* [priority] | | +-rw priority uint8 | | +-rw bandwidth? decimal64 > Discussed the deficiency of the above data type "decimal64", because it cannot represent very large number. Agreed to change the data type to a type representing IEEE 32 bit floating point number. - Discussed the operator requirement to have the geo-location on node and link-tp (3 GPS values) > Following is the proposal. > Add the section on node, link-tp, and tunnel-tp. > Discussed whether to use rw or ro? Most agreed to use ro since user requested update does not make sense. If the attribute needs to be updated by provider operator, some other mechanism is needed. > precision: 8th decimal place will have the precision 1.1mm. Oscar to check with the operator use cases. augment /nw:networks/nw:network/nw:node: +--rw te-node-id? te-types:te-node-id +--rw te! +--rw config +--ro state | +--ro te-node-attributes | | +--ro schedules | | +--ro admin-status? te-types:te-admin-status | | +--ro connectivity-matrix* [id] | | +--ro domain-id? uint32 + | | +--ro geolocation + | | | +--ro altitude? int64 + | | | +--ro latitude? geographic-coordinate-degree + | | | +--ro longitude? geographic-coordinate-degree typedef geographic-coordinate-degree { type decimal64 { fraction-digits 8; } description "Decimal degree (DD) used to express latitude and longitude geographic coordinates."; } Thanks, - Xufeng Note: Please drop me an email if you need an invite for joining the weekly call. P.S. We are planning to change the weekly meeting time. Please send your preference.
- [Teas] IETF TE Topology YANG Model Design Meeting… Xufeng Liu
- Re: [Teas] IETF TE Topology YANG Model Design Mee… Zhangxian (Xian)
- Re: [Teas] IETF TE Topology YANG Model Design Mee… Igor Bryskin
- Re: [Teas] OTN topology YANG model (draft-zhang-c… Zhangxian (Xian)
- Re: [Teas] OTN topology YANG model (draft-zhang-c… Igor Bryskin
- Re: [Teas] OTN topology YANG model (draft-zhang-c… Daniele Ceccarelli
- Re: [Teas] OTN topology YANG model (draft-zhang-c… Dieter Beller
- Re: [Teas] [CCAMP] OTN topology YANG model (draft… Belotti, Sergio (Nokia - IT)
- Re: [Teas] IETF TE Topology YANG Model Design Mee… Dieter Beller
- Re: [Teas] [CCAMP] OTN topology YANG model (draft… Zhangxian (Xian)
- Re: [Teas] [CCAMP] OTN topology YANG model (draft… Belotti, Sergio (Nokia - IT)
- Re: [Teas] IETF TE Topology YANG Model Design Mee… Xufeng Liu
- Re: [Teas] IETF TE Topology YANG Model Design Mee… Zhangxian (Xian)