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

From: The IESG <[email-masked]>
Date: Thu, 02 May 2019 13:47:03 -0700

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.

---

From: tom petch <[email-masked]>
Date: Wed, 15 May 2019 11:15:59 +0000

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.

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

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.

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.

.Tom Petch

---

From: Tarek Saad <[email-masked]>
Date: Wed, 15 May 2019 21:13:32 +0000

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:

    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.

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

    
    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.

    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
    
    > No IPR declarations have been submitted directly on this I-D.
    
    _______________________________________________
    Teas mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/teas

---

From: tom petch <[email-masked]>
Date: Wed, 29 May 2019 11:03:55 +0000

One of the identities defined herein is
ODUCn
with a reference of RFC7139.

I see no mention of ODUCn in RFC 7139 nor can I find it in the IANA
registries for GMPLS

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Thursday, May 02, 2019 9:47 PM
Subject: Last Call: <draft-ietf-teas-yang-te-types-09.txt> (Traffic
Engineering Common YANG Types) to Proposed Standard

---

From: Tarek Saad <[email-masked]>
Date: Wed, 29 May 2019 15:48:37 +0000

Hi Tom,

You are right. ODUCn is introduced in ITU-T G709-2016 - RFC7139 only covered G709-2012.
I noticed some expired IETF I-D(s) tried to bring in support for ODUCn but aborted: draft-merge-ccamp-otn-b100g-fwk and draft-ali-ccamp-oducn-signal-type.
I will discuss with authors to remove this identity from those defined in this document.

Regards,
Tarek

On 5/29/19, 7:04 AM, "Teas on behalf of tom petch" <[email-masked] on behalf of [email-masked]> wrote:

    
    Tom Petch

---

From: tom petch <[email-masked]>
Date: Wed, 29 May 2019 16:06:07 +0000

<at the end>

Tom Petch

----- Original Message -----
From: "Tarek Saad" <[email-masked]>
Sent: Wednesday, May 15, 2019 10:13 PM

> On 5/15/19, 7:16 AM, "Teas on behalf of tom petch" wrote:
>
> [TS]: As mentioned in abstract, the module is not strictly identities.
It is a collection of re-usable YANG groupings, types and identities.
> [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.
> [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.
> [TS]: In this effort, we've followed similar approach to RFC8294,
RFC6021. Etc.. Do you see the same concerns there too?

I think that the difference is the sheer size of this I-D and the likely
future evolution of it.  The IANA SMI registries each form a logical set
each of which can proceed independently and I think that that is spot
on; RFC8294 is much smaller and so less of a concern, and is also more a
loose aggregation of related objects  with no natural subdivisions.

Here you have replicated the objects in.
  identity lsp-encoding-types {
exactly AFAICT and so that is an obvious candidate to turn the SMI into
SMI and YANG.

With
  identity switching-capabilities {
the SMI is more up-to-date than the YANG and I would see  the SMI as the
starting point

With
 identity wdm-spectrum-type
you have replicated the objects but seem to have got the reference
wrong; you have
  identity flexible-grid { base wdm-spectrum-type; description "Flexible
grid.";
    reference "RFC6205";
whereas SMI has
3, ITU-T Flex, [RFC7699]
which I think correct (now if you had used the SMI as a basis, .....:-)

Tom Petch

>     > The IESG plans to make a decision in the next few weeks, and
solicits
>     final
>     > [email-masked] mailing lists by 2019-05-16. Exceptionally,
comments may
>     be

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Wed, 29 May 2019 16:16:10 +0000

Hi Tarek, Tom,
For ODUCn and all so said OTN part "beyond 100G" the most updated reference in IETF is 
https://www.ietf.org/id/draft-merge-ccamp-gmpls-otn-b100g-applicability-01.txt

There are no further signaling extension document since in this document is stated that for the applicability scenarios addressed no further extension is needed. 

Thanks
Sergio

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of Tarek Saad
Sent: Wednesday, May 29, 2019 5:49 PM
To: tom petch <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Teas] Last Call: <draft-ietf-teas-yang-te-types-09.txt> (Traffic Engineering Common YANG Types) to Proposed Standard

Hi Tom,

Regards,
Tarek

    
    
    Tom Petch

---

From: "Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)" <[email-masked]>
Date: Thu, 30 May 2019 01:29:34 +0000

Hi, Tarek, Tom, Sergio, 

This draft has been adopted in CCAMP a few months ago, the latest can be found at https://tools.ietf.org/html/draft-ietf-ccamp-gmpls-otn-b100g-applicability. Technically it's not different with the I-D -01. 

Regarding the identity oducn, the best reference should be ITU-T G.709-2016 if we want to keep it, or we can also use ccamp draft as an alternative reference. It would be even simpler if we remove the identity. 

Thanks. 

Best wishes,
Haomian

-----邮件原件-----
发件人: Teas [mailto:[email-masked]] 代表 Belotti, Sergio (Nokia - IT/Vimercate)
发送时间: 2019年5月30日 0:16
收件人: Tarek Saad <[email-masked]>; tom petch <[email-masked]>; [email-masked]
抄送: [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: Re: [Teas] Last Call: <draft-ietf-teas-yang-te-types-09.txt> (Traffic Engineering Common YANG Types) to Proposed Standard

Hi Tarek, Tom,
For ODUCn and all so said OTN part "beyond 100G" the most updated reference in IETF is https://www.ietf.org/id/draft-merge-ccamp-gmpls-otn-b100g-applicability-01.txt

Thanks
Sergio

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of Tarek Saad
Sent: Wednesday, May 29, 2019 5:49 PM
To: tom petch <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Teas] Last Call: <draft-ietf-teas-yang-te-types-09.txt> (Traffic Engineering Common YANG Types) to Proposed Standard

Hi Tom,

Regards,
Tarek

    
    
    Tom Petch