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

[tom petch <[e-mail]>]

----- Original Message -----
From: "Belotti, Sergio (Nokia - IT/Vimercate)"
<[e-mail]>
Sent: Wednesday, June 26, 2019 10:29 AM

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

As I have mentioned before, I think that we still have the overlap with
an existing IANA registry, OTN Signal Type, set up as part of a MIB
module so another option (my preferred one) would be to eliminate that
duplication, turn that registry into a YANG module as well, for all
possible values, or for the basic ones.  It does make it easier to
update if that is by Expert Review as opposed to RFC.

Tom Petch

> Thanks
> Sergio
>
> From: ietf <[e-mail]> On Behalf Of Zhenghaomian
(Zhenghaomian, Optical Technology Research Dept)
> Sent: Wednesday, June 26, 2019 7:46 AM
>
> 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:[e-mail]] 代表 Xufeng Liu
> 发送时间: 2019年6月21日 19:18
> 收件人: tom petch <[e-mail]<mailto:[e-mail]>>
> 抄送: Igor Bryskin
<[e-mail]<mailto:[e-mail]>>; ietf
<[e-mail]<mailto:[e-mail]>>;
[e-mail]<mailto:[e-mail]>;
[e-mail]<mailto:[e-mail]>;
[e-mail]<mailto:[e-mail]>;
[e-mail]<mailto:draft-ietf-teas-yang-te-ty
[e-mail]>; Tarek Saad
<[e-mail]<mailto:[e-mail]>>
> 主题: 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
<[e-mail]<mailto:[e-mail]>> 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" <[e-mail]<mailto:[e-mail]>>
> 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" <[e-mail]<mailto:[e-mail]>>
> > To: "tom petch"
<[e-mail]<mailto:[e-mail]>>;
<[e-mail]<mailto:[e-mail]>>; "Igor
> > Bryskin" <[e-mail]<mailto:[e-mail]>>
> > Cc:
<[e-mail]<mailto:draft-ietf-teas-yang-te-t
[e-mail]>>; <[e-mail]<mailto:[e-mail]>>;
> > <[e-mail]<mailto:[e-mail]>>;
<[e-mail]<mailto:[e-mail]>>
> > 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"
> > <[e-mail]<mailto:[e-mail]> on behalf of
[e-mail]<mailto:[e-mail]>> 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"
<[e-mail]<mailto:[e-mail]>>
> > >     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
> > >     > [e-mail]<mailto:[e-mail]> mailing lists by
2019-05-16. Exceptionally,
> > comments may
> > >     be
> > >     > sent to [e-mail]<mailto:[e-mail]> 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
> > >     [e-mail]<mailto:[e-mail]>
> > >     https://www.ietf.org/mailman/listinfo/teas
> > >
> > >
> >
> >
>
> ----------------------------------------------------------------------
> --
> > --------
> >
> >
> > > _______________________________________________
> > > Teas mailing list
> > > [e-mail]<mailto:[e-mail]>
> > > https://www.ietf.org/mailman/listinfo/teas
> > >
> >
>