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

From: tom petch <[email-masked]>
Date: Wed, 12 Jun 2019 15:46:35 +0000

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" <[email-masked]>
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" <[email-masked]>
> To: "tom petch" <[email-masked]>; <[email-masked]>; "Igor
> Bryskin" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>
> 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"
> <[email-masked] on behalf of [email-masked]> 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" <[email-masked]>
> >     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
> >     > [email-masked] mailing lists by 2019-05-16. Exceptionally,
> comments may
> >     be
> >     > sent to [email-masked] 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
> >     [email-masked]
> >     https://www.ietf.org/mailman/listinfo/teas
> >
> >
>
>
> ----------------------------------------------------------------------
--
> --------
>
>
> > _______________________________________________
> > Teas mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/teas
> >
>

---

From: Xufeng Liu <[email-masked]>
Date: Fri, 21 Jun 2019 07:17:58 -0400

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

---

From: "Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)" <[email-masked]>
Date: Wed, 26 Jun 2019 05:45:35 +0000

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:[email-masked]] 代表 Xufeng Liu
发送时间: 2019年6月21日 19:18
收件人: tom petch <[email-masked]>
抄送: Igor Bryskin <[email-masked]>; ietf <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Tarek Saad <[email-masked]>
主题: 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 <[email-masked]<mailto:[email-masked]>> 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" <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, June 06, 2019 4:43 PM

later
(some
> From: "Tarek Saad" <[email-masked]<mailto:[email-masked]>>
> To: "tom petch" <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>; "Igor
> Bryskin" <[email-masked]<mailto:[email-masked]>>
> Cc: <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>;
> <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>
same
> <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
> >
TE,
identities.
by
in
> >     there to this day.  They were updated by e.g.. RFC8330 (February
> 2018)
dusty
would
in
work
data
encoding,
monolith
> >     ...Tom Petch
> >     From: "The IESG" <[email-masked]<mailto:[email-masked]>>
the
> >     > [email-masked]<mailto:[email-masked]> mailing lists by 2019-05-16. Exceptionally,
> comments may
> >     be
> >     > sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain
the
> >     [email-masked]<mailto:[email-masked]>
--
> > [email-masked]<mailto:[email-masked]>

---

From: tom petch <[email-masked]>
Date: Thu, 27 Jun 2019 10:08:37 +0000

----- Original Message -----
From: "Belotti, Sergio (Nokia - IT/Vimercate)"
<[email-masked]>
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 <[email-masked]> 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.
> 收件人: tom petch <[email-masked]<mailto:[email-masked]>>
> 抄送: Igor Bryskin
<[email-masked]<mailto:[email-masked]>>; ietf
<[email-masked]<mailto:[email-masked]>>;
[email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:draft-ietf-teas-yang-te-ty
[email-masked]>; Tarek Saad
<[email-masked]<mailto:[email-masked]>>
> 主题: Re: [Teas] Last Call: <draft-ietf-teas-yang-te-types-09.txt>
> On Wed, Jun 12, 2019 at 11:46 AM tom petch
<[email-masked]<mailto:[email-masked]>> wrote:
> > To: "tom petch"
<[email-masked]<mailto:[email-masked]>>;
<[email-masked]<mailto:[email-masked]>>; "Igor
> > Cc:
<[email-masked]<mailto:draft-ietf-teas-yang-te-t
[email-masked]>>; <[email-masked]<mailto:[email-masked]>>;
> > <[email-masked]<mailto:[email-masked]> on behalf of
[email-masked]<mailto:[email-masked]>> wrote:
> > >     From: "The IESG"
<[email-masked]<mailto:[email-masked]>>

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Wed, 26 Jun 2019 09:29:14 +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 <[email-masked]> On Behalf Of Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)
Sent: Wednesday, June 26, 2019 7:46 AM
To: Xufeng Liu <[email-masked]>; tom petch <[email-masked]>
Cc: Igor Bryskin <[email-masked]>; ietf <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Tarek Saad <[email-masked]>
Subject: 答复: [Teas] Last Call: <draft-ietf-teas-yang-te-types-09.txt> (Traffic Engineering Common YANG Types) to Proposed Standard

Hi, Xufeng,

Best wishes,
Haomian

发件人: ietf [mailto:[email-masked]] 代表 Xufeng Liu
发送时间: 2019年6月21日 19:18
收件人: tom petch <[email-masked]<mailto:[email-masked]>>
抄送: Igor Bryskin <[email-masked]<mailto:[email-masked]>>; ietf <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Tarek Saad <[email-masked]<mailto:[email-masked]>>
主题: Re: [Teas] Last Call: <draft-ietf-teas-yang-te-types-09.txt> (Traffic Engineering Common YANG Types) to Proposed Standard

Hi Tom,

Regards,
- Xufeng

Tom Petch

----- Original Message -----
From: "t.petch" <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, June 06, 2019 4:43 PM

later
(some
same
TE,
identities.
by
in
dusty
would
in
work
data
encoding,
monolith
the
the
--