Re: [Teas] [CCAMP] OTN topology YANG model (draft-zhang-ccamp-l1-topo-yang )
"Belotti, Sergio (Nokia - IT)" <sergio.belotti@nokia.com> Tue, 11 October 2016 07:48 UTC
Return-Path: <sergio.belotti@nokia.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 CFCCE12949B; Tue, 11 Oct 2016 00:48:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.41
X-Spam-Level:
X-Spam-Status: No, score=-6.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 bpcoEf-563YL; Tue, 11 Oct 2016 00:48:44 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D4412949A; Tue, 11 Oct 2016 00:48:43 -0700 (PDT)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 36586C0DE6B32; Tue, 11 Oct 2016 07:48:39 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u9B7meMc009343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Oct 2016 07:48:41 GMT
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u9B7mewr020578 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Oct 2016 09:48:40 +0200
Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.121]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Tue, 11 Oct 2016 09:48:39 +0200
From: "Belotti, Sergio (Nokia - IT)" <sergio.belotti@nokia.com>
To: "Zhangxian (Xian)" <zhang.xian@huawei.com>, "Beller, Dieter (Nokia - DE)" <dieter.beller@nokia.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Igor Bryskin <Igor.Bryskin@huawei.com>, "ccamp@ietf.org" <ccamp@ietf.org>
Thread-Topic: [Teas] [CCAMP] OTN topology YANG model (draft-zhang-ccamp-l1-topo-yang )
Thread-Index: AQHSI14DnajloK6Mw02djCkBO4CoNqCi4LrQ
Date: Tue, 11 Oct 2016 07:48:38 +0000
Message-ID: <B9FEE68CE3A78C41A2B3C67549A96F48B7740E6E@FR711WXCHMBA05.zeu.alcatel-lucent.com>
References: <AM5PR0601MB2641B92135374262B8B5F855B1F00@AM5PR0601MB2641.eurprd06.prod.outlook.com> <C636AF2FA540124E9B9ACB5A6BECCE6B7DF3C0E1@SZXEMA512-MBS.china.huawei.com> <0C72C38E7EBC34499E8A9E7DD007863908F066AA@dfweml501-mbx> <C636AF2FA540124E9B9ACB5A6BECCE6B7DF44A6F@SZXEMA512-MBS.china.huawei.com> <0C72C38E7EBC34499E8A9E7DD007863908F09409@dfweml501-mbx> <AM2PR07MB09947D86CC9833A608456F7DF0DB0@AM2PR07MB0994.eurprd07.prod.outlook.com> <d6c7553b-cffd-cd6d-f258-39559985819c@nokia.com> <B9FEE68CE3A78C41A2B3C67549A96F48B7740A7A@FR711WXCHMBA05.zeu.alcatel-lucent.com> <C636AF2FA540124E9B9ACB5A6BECCE6B7DF44F39@SZXEMA512-MBS.china.huawei.com>
In-Reply-To: <C636AF2FA540124E9B9ACB5A6BECCE6B7DF44F39@SZXEMA512-MBS.china.huawei.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.41]
Content-Type: multipart/alternative; boundary="_000_B9FEE68CE3A78C41A2B3C67549A96F48B7740E6EFR711WXCHMBA05z_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/wRSJObi6LISnuilRYlFpp2JvcXw>
Cc: "teas@ietf.org" <teas@ietf.org>
Subject: Re: [Teas] [CCAMP] OTN topology YANG model (draft-zhang-ccamp-l1-topo-yang )
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: Tue, 11 Oct 2016 07:48:48 -0000
Thanks Xian. Fine with the update . Regards Sergio From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Zhangxian (Xian) Sent: Tuesday, October 11, 2016 3:22 AM To: Belotti, Sergio (Nokia - IT) <sergio.belotti@nokia.com>; Beller, Dieter (Nokia - DE) <dieter.beller@nokia.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Igor Bryskin <Igor.Bryskin@huawei.com>; ccamp@ietf.org Cc: teas@ietf.org Subject: Re: [Teas] [CCAMP] OTN topology YANG model (draft-zhang-ccamp-l1-topo-yang ) Great; Thank you all for the feedbacks. I see a good support of it. I will update the ODU topology YANG model in the following manner to support per priority ODU availability: augment /nd:networks/nd:network/lnk:link/tet:te/tet:config: +--rw available-odu-info* [priority] | +---rw priority uint8 +----rw odulist[odu-type] +--rw odu-type identityref +--rw number? uint16 Regards, Xian 发件人: Belotti, Sergio (Nokia - IT) [mailto:sergio.belotti@nokia.com] 发送时间: 2016年10月10日 21:19 收件人: Beller, Dieter (Nokia - DE); Zhangxian (Xian); Daniele Ceccarelli; Igor Bryskin; ccamp@ietf.org<mailto:ccamp@ietf.org> 抄送: teas@ietf.org<mailto:teas@ietf.org> 主题: RE: [CCAMP] [Teas] OTN topology YANG model (draft-zhang-ccamp-l1-topo-yang ) +1. Yes Xian, I think we need to support that. Thanks Sergio From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller Sent: Monday, October 10, 2016 3:15 PM To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com>>; Igor Bryskin <Igor.Bryskin@huawei.com<mailto:Igor.Bryskin@huawei.com>>; Zhangxian (Xian) <zhang.xian@huawei.com<mailto:zhang.xian@huawei.com>>; ccamp@ietf.org<mailto:ccamp@ietf.org> Cc: teas@ietf.org<mailto:teas@ietf.org> Subject: Re: [CCAMP] [Teas] OTN topology YANG model (draft-zhang-ccamp-l1-topo-yang ) Hi Xian, all, I concur with Igor and Daniele - priority levels shall be supported in the same way as for GMPLS! Thanks, Dieter On 10.10.2016 14:48, Daniele Ceccarelli wrote: Hi Xian, Igor, I think Igor’s point is valuable, in the sense that up to now preemption was not widely deployed because of the distributed nature of the path computation, but in a centralized world like the SDN one it should be easier to support that. Moreover if a functionality is already supported by existing protocols (even if used by a small % of field deployments) I don’t see why a different way of controlling the same network should not support the same capabilities. Cheers Daniele From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: lunedì 10 ottobre 2016 14:42 To: Zhangxian (Xian) <zhang.xian@huawei.com><mailto:zhang.xian@huawei.com>; ccamp@ietf.org<mailto:ccamp@ietf.org> Cc: teas@ietf.org<mailto:teas@ietf.org> Subject: Re: [Teas] OTN topology YANG model (draft-zhang-ccamp-l1-topo-yang ) Hi Xian, In TE Topology model we define bandwidth on per priority level. TE tunnel model also allows for a tunnel to be configured on a given priority level. All path computations could be constrained to a priority level. Furthermore, I am aware of implementations which use particular priority levels to identify bandwidth available for a particular use ( e.g. for restoration only purposes). I don’t think we should retire the concept of priority now. I believe that in the T-SDN architecture it will be easier to support resource preemption. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Zhangxian (Xian) Sent: Saturday, October 08, 2016 3:12 AM To: ccamp@ietf.org<mailto:ccamp@ietf.org> Cc: teas@ietf.org<mailto:teas@ietf.org> Subject: Re: [Teas] OTN topology YANG model (draft-zhang-ccamp-l1-topo-yang ) Hi, Igor, I changed the recipient to ccamp mailing list since this discussion should be of interest to the CCAMPers. To answer your question: No; not at the moment. I am aware that GMPLS OSPF-TE extensions usually follow the 8-level priority info., but they are not used that much. Do you and others see the need when reporting ODU resource information via controller northbound interface as well? I am open to suggestions. Regards, Xian 发件人: Igor Bryskin 发送时间: 2016年9月19日 20:18 收件人: Zhangxian (Xian); 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; xufeng.liu.ietf@gmail.com<mailto:xufeng.liu.ietf@gmail.com>; Belotti, Sergio (Nokia - IT); Anurag Sharma 抄送: teas@ietf.org<mailto:teas@ietf.org> 主题: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-09-12 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<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-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<mailto:xufeng.liu.ietf@gmail.com>; Belotti, Sergio (Nokia - IT); Anurag Sharma 抄送: teas@ietf.org<mailto: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 mailing list Teas@ietf.org<mailto:Teas@ietf.org> https://www.ietf.org/mailman/listinfo/teas -- Dieter Beller ASON/GMPLS Project Manager IP/Optical Networks, Optics, Nokia t: +49 711 821 43125 | m : +49 175 7266874 | OnNet: 259 43125 Dieter.Beller@nokia.com<mailto:Dieter.Beller@nokia.com> Alcatel-Lucent Deutschland AG | Lorenzstr. 10 | 70435 Stuttgart Sitz der Gesellschaft | Domicile of the Company: Stuttgart · Amtsgericht Stuttgart HRB 4026 Vorsitzender des Aufsichtsrates | Chairman of the Supervisory Board: Prof. J. Menno Harms Vorstand | Board of Management: Wilhelm Dresselhaus (Vorsitzender | Chairman) · Hans-Jörg Daub · Ralf Niederberger This e-mail and its attachments, if any, may contain confidential information. If you have received this e-mail in error, please notify us and delete or destroy the e-mail and its attachments, if any, immediately. If you have received this e-mail in error, you must not forward or make use of the e-mail and its attachments, if any.
- [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)