Re: [Teas] Last Call: <draft-ietf-teas-yang-te-types-09.txt> (Traffic Engineering Common YANG Types) to Proposed Standard
"Belotti, Sergio (Nokia - IT/Vimercate)" <sergio.belotti@nokia.com> Wed, 26 June 2019 09:29 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 21D39120254; Wed, 26 Jun 2019 02:29:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 deAFOA8d5i4v; Wed, 26 Jun 2019 02:29:17 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00132.outbound.protection.outlook.com [40.107.0.132]) (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 F2373120236; Wed, 26 Jun 2019 02:29:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Wz+if4EwJiCU4Ap+rI5RWswUcRNdzLzQKMarFrNuD/M=; b=ruNx+dzf28rsWecHvRMwiCTuHYXHzkX52UuVLqT/92/S5p1tAwsq8d0nOpk8tByvd5dbTj8YNa1VtvFFu74vynCK+btwQrdHPhxcm3yFYBX1scZ5yX/ppe+xwh2N7twP+icLVY2IF4zcb1ZJ+U9IbmlD5b6KzZKgu5mbWmZKUT4=
Received: from HE1PR07MB3195.eurprd07.prod.outlook.com (10.170.246.10) by HE1PR07MB4331.eurprd07.prod.outlook.com (20.176.167.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.12; Wed, 26 Jun 2019 09:29:14 +0000
Received: from HE1PR07MB3195.eurprd07.prod.outlook.com ([fe80::70d1:b6ab:c022:f920]) by HE1PR07MB3195.eurprd07.prod.outlook.com ([fe80::70d1:b6ab:c022:f920%3]) with mapi id 15.20.2008.018; Wed, 26 Jun 2019 09:29:14 +0000
From: "Belotti, Sergio (Nokia - IT/Vimercate)" <sergio.belotti@nokia.com>
To: "Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)" <zhenghaomian@huawei.com>, Xufeng Liu <xufeng.liu.ietf@gmail.com>, tom petch <ietfa@btconnect.com>
CC: Igor Bryskin <Igor.Bryskin@huawei.com>, ietf <ietf@ietf.org>, "db3546@att.com" <db3546@att.com>, "teas-chairs@ietf.org" <teas-chairs@ietf.org>, "teas@ietf.org" <teas@ietf.org>, "draft-ietf-teas-yang-te-types@ietf.org" <draft-ietf-teas-yang-te-types@ietf.org>, Tarek Saad <tsaad.net@gmail.com>, "Beller, Dieter (Nokia - DE/Stuttgart)" <dieter.beller@nokia.com>
Thread-Topic: [Teas] Last Call: <draft-ietf-teas-yang-te-types-09.txt> (Traffic Engineering Common YANG Types) to Proposed Standard
Thread-Index: AQHVITYDbdIAH+mi2UGL51LY4hpro6amA4kAgAd+yoCAADskkA==
Date: Wed, 26 Jun 2019 09:29:14 +0000
Message-ID: <HE1PR07MB3195D73B7D184DD9A379F5FB91E20@HE1PR07MB3195.eurprd07.prod.outlook.com>
References: <01c101d52135$6791f660$4001a8c0@gateway.2wire.net> <CAEz6PPQgH3a1WeK2gfY23KH3Q=WmD196rc6-8TT0_05CKRhMMw@mail.gmail.com> <E0C26CAA2504C84093A49B2CAC3261A43B7FDEDB@dggeml511-mbx.china.huawei.com>
In-Reply-To: <E0C26CAA2504C84093A49B2CAC3261A43B7FDEDB@dggeml511-mbx.china.huawei.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=sergio.belotti@nokia.com;
x-originating-ip: [131.228.32.183]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c6a5256a-60e9-4fd3-e857-08d6fa18c105
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:HE1PR07MB4331;
x-ms-traffictypediagnostic: HE1PR07MB4331:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <HE1PR07MB4331F3EE42205E0CC790676C91E20@HE1PR07MB4331.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00808B16F3
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(396003)(346002)(39860400002)(366004)(53824002)(189003)(13464003)(199004)(186003)(71190400001)(2906002)(68736007)(9686003)(3846002)(26005)(236005)(6116002)(790700001)(7736002)(64756008)(53546011)(66476007)(66446008)(66556008)(11346002)(606006)(74316002)(25786009)(446003)(486006)(66066001)(33656002)(476003)(71200400001)(73956011)(76116006)(99286004)(66946007)(54906003)(110136005)(229853002)(102836004)(5024004)(14444005)(256004)(6246003)(6436002)(6506007)(316002)(7416002)(7696005)(53936002)(8676002)(81156014)(55016002)(76176011)(52536014)(86362001)(478600001)(54896002)(14454004)(6306002)(966005)(107886003)(81166006)(5660300002)(4326008)(8936002)(111480200001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB4331; H:HE1PR07MB3195.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 1xTpMj1yicWOzllL08D15Qu+v59R7is3Mcp3+8IwRuQv5omVqvk8rDrHka23rgnTB8/KfnwABphjdmEqbG0GXXf/qwxdCW68lkoAIU7Mpc4sDXNL9TmYxcYOejGxufL3cEEvr4KTafIlQE5YOREgY7oHnJfwsCyJyA8Bq5LOVATWev4OLBMHSrpGrKnEk3d4LVVcA17IJNN/lSn9YpGo6lW6FfqdWbU8lFW2YaBP2oTa4TegLRxJNvLND3HBy78fSmX9iM68KZsrQ1K1mZ263F9XNQ/7MwnsLzcgLKyUD/+h6/8M2N3U+b1AHRs3/AGQBcQ5AUvMT/UGvLHENKUPhJdtxGgScO2J7TAAKVCDtMD1xJ1VZlXez/iuu8effi5brlj++pZ8cATvtA37jEoCOXUcASDcRH8iJooW3A/X5nk=
Content-Type: multipart/alternative; boundary="_000_HE1PR07MB3195D73B7D184DD9A379F5FB91E20HE1PR07MB3195eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c6a5256a-60e9-4fd3-e857-08d6fa18c105
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2019 09:29:14.2593 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: sergio.belotti@nokia.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4331
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Ms49PcoeA5Ougue2RdTSyO_hUOg>
Subject: Re: [Teas] Last Call: <draft-ietf-teas-yang-te-types-09.txt> (Traffic Engineering Common YANG Types) to Proposed Standard
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
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, 26 Jun 2019 09:29:23 -0000
Hi Haomian, Xufeng, Sincerely I do not think it would be a good idea to separate ODU definitions. The separation of “basic” ODU types with respect the “extended” ones appears to me not clear at all. The scope to create a technology specific types module is exactly to encompass types definition that is proper to one technology (or layer , if we expand at L1 as name , e.g. OTN + SDH). To take separation in different modules on definitions regarding a technology specific , has no sense for me and it only produces confusion. So, my suggestion is to use the new one L1 draft-ietf-ccamp-layer1-types for all ODU types definitions, and clean up te-types of all ODU reference. Thanks Sergio From: ietf <ietf-bounces@ietf.org> On Behalf Of Zhenghaomian (Zhenghaomian, Optical Technology Research Dept) Sent: Wednesday, June 26, 2019 7:46 AM To: Xufeng Liu <xufeng.liu.ietf@gmail.com>; tom petch <ietfa@btconnect.com> Cc: Igor Bryskin <Igor.Bryskin@huawei.com>; ietf <ietf@ietf.org>; db3546@att.com; teas-chairs@ietf.org; teas@ietf.org; draft-ietf-teas-yang-te-types@ietf.org; Tarek Saad <tsaad.net@gmail.com> Subject: 答复: [Teas] Last Call: <draft-ietf-teas-yang-te-types-09.txt> (Traffic Engineering Common YANG Types) to Proposed Standard Hi, Xufeng, Thank you for sharing the opinion, I like the idea ‘Keep the basic ODU type definitions in draft-ietf-teas-yang-te-types’. The current misunderstanding would be ‘what is the basic ODU types’, and ‘what is the extended ODU types’ as well. I have also reviewed how this was proceeded on Layer 0 types, they were divided into ‘cwdm+dwdm+flexi-grid’ which are high-level categories. And more specifically, ‘dwdm-100ghz’ is considered as technical-specific and put in the module ietf-layer0-types. Therefore, if we follow the similar rule as layer 0, my preference would be ‘ODUk + ODUCn’ as generic (should be in draft-ietf-teas-yang-te-types) while the {ODU0, ODU1, ODU2, …, ODUflex} would be technology-specific and put in the module ietf-layer1-types. Regarding the last two bullets from your email, it’s fine to have te-types in both layer0-types and layer1-types, even if none of them has the importation so far. Best wishes, Haomian 发件人: ietf [mailto:ietf-bounces@ietf.org] 代表 Xufeng Liu 发送时间: 2019年6月21日 19:18 收件人: tom petch <ietfa@btconnect.com<mailto:ietfa@btconnect.com>> 抄送: Igor Bryskin <Igor.Bryskin@huawei.com<mailto:Igor.Bryskin@huawei.com>>; ietf <ietf@ietf.org<mailto:ietf@ietf.org>>; db3546@att.com<mailto:db3546@att.com>; teas-chairs@ietf.org<mailto:teas-chairs@ietf.org>; teas@ietf.org<mailto:teas@ietf.org>; draft-ietf-teas-yang-te-types@ietf.org<mailto:draft-ietf-teas-yang-te-types@ietf.org>; Tarek Saad <tsaad.net@gmail.com<mailto:tsaad.net@gmail.com>> 主题: Re: [Teas] Last Call: <draft-ietf-teas-yang-te-types-09.txt> (Traffic Engineering Common YANG Types) to Proposed Standard Hi Tom, Thanks for pointing out the duplications and conflicts between draft-ietf-ccamp-layer1-types and draft-ietf-teas-yang-te-types. It is planned to solve these duplications and conflicts as follows: - Keep the basic ODU type definitions in draft-ietf-teas-yang-te-types; - Duplications are to be removed from draft-ietf-ccamp-layer1-types; - draft-ietf-ccamp-layer1-types will re-use the types defined in draft-ietf-teas-yang-te-type; - draft-ietf-ccamp-layer1-types will define extended ODU types; Regards, - Xufeng On Wed, Jun 12, 2019 at 11:46 AM tom petch <ietfa@btconnect.com<mailto:ietfa@btconnect.com>> wrote: And now it would appear we have quadruplicate definitions with the advent of draft-ietf-ccamp-layer1-types which has a comprehensive, and different, set of ODU (upper case) types. Tom Petch ----- Original Message ----- From: "t.petch" <ietfa@btconnect.com<mailto:ietfa@btconnect.com>> Sent: Thursday, June 06, 2019 4:43 PM > Tarek > > You asked about my reference to definitions in triplicate which my later > response did not expand on. > > The three I was counting were this I-D, exisiting IANA registries (some > of > which are identical to this I-D, some not) and the LSR I-D > draft-ietf-isis-yang-isis-cfg > which contains definitions of switching capability which I see > overlapping a part of this I-D. I thought I saw an e-mail from > Stephane, > around Christmas, saying he would discuss this with other chairs but > cannot now find it so perhaps the wish was father to the thought. > > The LSR I-D is now in AD review on the LSR list and so may get more > attention. > > Tom Petch > > ----- Original Message ----- > From: "Tarek Saad" <tsaad.net@gmail.com<mailto:tsaad.net@gmail.com>> > To: "tom petch" <daedulus@btconnect.com<mailto:daedulus@btconnect.com>>; <ietf@ietf.org<mailto:ietf@ietf.org>>; "Igor > Bryskin" <Igor.Bryskin@huawei.com<mailto:Igor.Bryskin@huawei.com>> > Cc: <draft-ietf-teas-yang-te-types@ietf.org<mailto:draft-ietf-teas-yang-te-types@ietf.org>>; <teas-chairs@ietf.org<mailto:teas-chairs@ietf.org>>; > <teas@ietf.org<mailto:teas@ietf.org>>; <db3546@att.com<mailto:db3546@att.com>> > Sent: Wednesday, May 15, 2019 10:13 PM > Subject: Re: [Teas] Last Call: <draft-ietf-teas-yang-te-types-09.txt> > (Traffic Engineering Common YANG Types) to Proposed Standard > > > > Hi Tom, > > > > Thanks for sharing your feedback. > > I'm attaching Igor's response on this topic -- which I share his same > opinion. > > Please see more comments inline from me [TS].. > > > > On 5/15/19, 7:16 AM, "Teas on behalf of tom petch" > <teas-bounces@ietf.org<mailto:teas-bounces@ietf.org> on behalf of daedulus@btconnect.com<mailto:daedulus@btconnect.com>> wrote: > > > > The approach taken by this I-D worries me. > > > > It provides YANG identities for a wide range of values used in TE, > such > > as encoding types and switching capabilities; so far, so good. > > [TS]: As mentioned in abstract, the module is not strictly identities. > It is a collection of re-usable YANG groupings, types and identities. > > > > These definitions were needed, and were in a large part created by > > RFC3471, in 2003. When the management of GMPLS was specified, in > MIB > > modules, these definitions were put under IANA control and they > remain > > there to this day. They were updated by e.g.. RFC8330 (February > 2018) > > and RFC8363 (May 2018) so these IANA registries are not some dusty > old > > relic but a current, living specification. > > > > These YANG definitions have much in common with the IANA SMI > registries > > but they are not the same. A comparison of e.g. switching > capabilities > > suggests that this YANG module is out-of-date compared with the > IANA SMI > > registry (as with RFC8330, RFC8363) and omits several values for > no > > stated reason ( the deprecated 2,3,4, 40 PBB-TE, 151 WSON-LSC). > > [TS]: it was not the intention to be exhaustive in covering all IANA > defined entities. However, the objective was to model enough that would > make TE feature (modelled in other modules) usable and to leverage the > power of YANG augmentation for any extensions that may not be covered in > a base model. Specifically, the authors favored the use of YANG > identities over enums to allow for the extensibility of augmentation. > > > > The approach taken by other WG has been to take a IANA registry > and > > provide a parallel YANG module under common IANA control as has > been > > done for e.g. interfaces with both MIB module and YANG module > being > > updated in parallel as appropriate. > > > > Here something seems to have gone wrong. We have a parallel set > of > > definitions not acknowledging the existing ones and being > out-of-date > > compared with the existing ones. > > > > Furthermore, some of these definitions are duplicated in the work > of the > > LSR WG giving us (at least) three definitions. > > [TS]: it would help to point to the duplication or thread that this > was discussed in. However, we believe that this document covers TE data > and hence LSR module(s) would need to eliminate duplication of any TE > data (if any).. LSR module can always import TE types to use the TE > definitions. > > > > I raised this issue before Christmas 2018 and was told that the > chairs > > of TEAS and LSR would get together and get back to me. Nothing > appears > > to have changed. > > > > In passing, IANA has separate SMI registries for e.g.LSP encoding, > > Switching Types and so on, which seems a sound engineering > approach, > > allowing more flexible evolution compared to the 60-page monolith > of > > this single YANG module. > > [TS]: In this effort, we've followed similar approach to RFC8294, > RFC6021. Etc.. Do you see the same concerns there too? > > > > Regards, > > Tarek > > > > ...Tom Petch > > > > ----- Original Message ----- > > From: "The IESG" <iesg-secretary@ietf.org<mailto:iesg-secretary@ietf.org>> > > Sent: Thursday, May 02, 2019 9:47 PM > > > > > The IESG has received a request from the Traffic Engineering > > Architecture and > > > Signaling WG (teas) to consider the following document: - > 'Traffic > > > Engineering Common YANG Types' > > > <draft-ietf-teas-yang-te-types-09.txt> as Proposed Standard > > > > > > The IESG plans to make a decision in the next few weeks, and > solicits > > final > > > comments on this action. Please send substantive comments to the > > > ietf@ietf.org<mailto:ietf@ietf.org> mailing lists by 2019-05-16. Exceptionally, > comments may > > be > > > sent to iesg@ietf.org<mailto:iesg@ietf.org> instead. In either case, please retain the > > beginning of > > > the Subject line to allow automated sorting. > > > > > > Abstract > > > > > > > > > This document defines a collection of common data types and > > groupings > > > in YANG data modeling language. These derived common types > and > > > groupings are intended to be imported by modules that model > Traffic > > > Engineering (TE) configuration and state capabilities. > > > > > > > > > > > > > > > The file can be obtained via > > > https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-types/ > > > > > > IESG discussion can be tracked via > > > > https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-types/ballot/ > > > > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > > > > > > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org<mailto:Teas@ietf.org> > > https://www.ietf.org/mailman/listinfo/teas > > > > > > > ---------------------------------------------------------------------- -- > -------- > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org<mailto:Teas@ietf.org> > > https://www.ietf.org/mailman/listinfo/teas > > >
- [Teas] Last Call: <draft-ietf-teas-yang-te-types-… The IESG
- Re: [Teas] Last Call: <draft-ietf-teas-yang-te-ty… tom petch
- Re: [Teas] Last Call: <draft-ietf-teas-yang-te-ty… Tarek Saad
- Re: [Teas] Last Call: <draft-ietf-teas-yang-te-ty… tom petch
- Re: [Teas] Last Call: <draft-ietf-teas-yang-te-ty… Tarek Saad
- Re: [Teas] Last Call: <draft-ietf-teas-yang-te-ty… tom petch
- Re: [Teas] Last Call: <draft-ietf-teas-yang-te-ty… Belotti, Sergio (Nokia - IT/Vimercate)
- [Teas] 答复: Last Call: <draft-ietf-teas-yang-te-ty… Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)
- Re: [Teas] Last Call: <draft-ietf-teas-yang-te-ty… tom petch
- Re: [Teas] Last Call: <draft-ietf-teas-yang-te-ty… tom petch
- Re: [Teas] Last Call: <draft-ietf-teas-yang-te-ty… Xufeng Liu
- [Teas] 答复: Last Call: <draft-ietf-teas-yang-te-ty… Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)
- Re: [Teas] Last Call: <draft-ietf-teas-yang-te-ty… Belotti, Sergio (Nokia - IT/Vimercate)
- Re: [Teas] Last Call: <draft-ietf-teas-yang-te-ty… tom petch
- Re: [Teas] Last Call: <draft-ietf-teas-yang-te-ty… Tarek Saad