Re: [Teas] Last Call: <draft-ietf-teas-yang-te-types-09.txt> (Traffic Engineering Common YANG Types) to Proposed Standard

Xufeng Liu <xufeng.liu.ietf@gmail.com> Fri, 21 June 2019 11:18 UTC

Return-Path: <xufeng.liu.ietf@gmail.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 296E1120229; Fri, 21 Jun 2019 04:18:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 PPfXbo1gfXdt; Fri, 21 Jun 2019 04:18:12 -0700 (PDT)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B2D11200F7; Fri, 21 Jun 2019 04:18:12 -0700 (PDT)
Received: by mail-io1-xd29.google.com with SMTP id m24so457493ioo.2; Fri, 21 Jun 2019 04:18:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BZeifEqxuykORoi3bZJywzeEPs0MrBcQBVkQlynpc+Y=; b=mdo9oE5zU0gZo5c/e9l+cpaMhSck/qzn6Q9GnZp8efSW/wF4EvImU8+eoZDLFK4RxK Ot34R1Ke/yjs532vbiZUNPelpkQfLFhEU14ywIi9H4zuuwhnrW91xV6+CH49o6XgjeX9 smDOpwLysAQQoLRFFPyJVRsa2swENcRMNbYurFBwXTtDjVEOhiXAJpIK2G5Gv7doXunw iq790dnHTeAq+Ke+Px52YNVekkTW7BQAOIHAXW1OMYQrwCWmnyg5H8VfdbqIXfsg6kY+ /j38ZjQGVWwWg7fHiuUyLMJNHne8WYxFp5Z/u72kTxxOteMcE1ZFVFfuP/XxSs3Bq1wj WazA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BZeifEqxuykORoi3bZJywzeEPs0MrBcQBVkQlynpc+Y=; b=k7wKcXlLVnP9mA38Ll3P0JZiMkcjTqIi42pqV330rJL8/lctc64pKlnSZuhvEOL0LV 85QChfwZ7ptipbKxX906hBm931aAugYECyj30xbdcWorGeVmEy96mMGH4dB/vN6Z1v/h kde402D8m22/iWoH9BYbjO9uu8KyjZ1SbqaASnhFc21RWX6n/i0deL8aiyZpaXw8Fc3Z GRbpi3hH6WjOt/fdtTvouAgytrzkHxHbnl2cgHDa3OFBz6n7CoRwWGDUVr9y6g2Fng1u FPqkDW6AwJEHzUbsh3FFmzj+Q3kVtX9OA2OxD9jbOix3j+M897at1QUyfRSXscrETrQh 7PzQ==
X-Gm-Message-State: APjAAAWZ/7CE+mMbylxAQ2gIxt6utztf0cfIxRdlAi1ChyoJWhKLpB6F 1sDxBN6TqIVmtHylQMIgL+7/cO+s3sH7scm9lds=
X-Google-Smtp-Source: APXvYqzmxJv02/i1gxmTyDWt7BZZxjOOjgv21oygGKadb0FROZUZRnXU8u9SBUlc+WNAcNXOV1AiakLMcxbXJG74Jqg=
X-Received: by 2002:a6b:bf01:: with SMTP id p1mr2876158iof.181.1561115891748; Fri, 21 Jun 2019 04:18:11 -0700 (PDT)
MIME-Version: 1.0
References: <01c101d52135$6791f660$4001a8c0@gateway.2wire.net>
In-Reply-To: <01c101d52135$6791f660$4001a8c0@gateway.2wire.net>
From: Xufeng Liu <xufeng.liu.ietf@gmail.com>
Date: Fri, 21 Jun 2019 07:17:58 -0400
Message-ID: <CAEz6PPQgH3a1WeK2gfY23KH3Q=WmD196rc6-8TT0_05CKRhMMw@mail.gmail.com>
To: tom petch <ietfa@btconnect.com>
Cc: Tarek Saad <tsaad.net@gmail.com>, ietf <ietf@ietf.org>, Igor Bryskin <Igor.Bryskin@huawei.com>, "draft-ietf-teas-yang-te-types@ietf.org" <draft-ietf-teas-yang-te-types@ietf.org>, "teas-chairs@ietf.org" <teas-chairs@ietf.org>, "teas@ietf.org" <teas@ietf.org>, "db3546@att.com" <db3546@att.com>
Content-Type: multipart/alternative; boundary="0000000000002e5ca9058bd39e56"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/wqKAVPDzKlsy94URh7KIuFTcpAI>
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: Fri, 21 Jun 2019 11:18:17 -0000

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>; 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>;
> 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>;
> > To: "tom petch" <daedulus@btconnect.com>;; <ietf@ietf.org>;; "Igor
> > Bryskin" <Igor.Bryskin@huawei.com>;
> > Cc: <draft-ietf-teas-yang-te-types@ietf.org>;; <teas-chairs@ietf.org>;;
> > <teas@ietf.org>;; <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 on behalf of 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>;
> > >     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 mailing lists by 2019-05-16. Exceptionally,
> > comments may
> > >     be
> > >     > sent to 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
> > >     https://www.ietf.org/mailman/listinfo/teas
> > >
> > >
> >
> >
> > ----------------------------------------------------------------------
> --
> > --------
> >
> >
> > > _______________________________________________
> > > Teas mailing list
> > > Teas@ietf.org
> > > https://www.ietf.org/mailman/listinfo/teas
> > >
> >
>
>