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@xxxxxxxx>
On Behalf Of Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)
Sent: Wednesday, June 26, 2019 7:46 AM
To: Xufeng Liu <xufeng.liu.ietf@xxxxxxxxx>; tom petch <ietfa@xxxxxxxxxxxxx>
Cc: Igor Bryskin <Igor.Bryskin@xxxxxxxxxx>; ietf <ietf@xxxxxxxx>; db3546@xxxxxxx; teas-chairs@xxxxxxxx; teas@xxxxxxxx; draft-ietf-teas-yang-te-types@xxxxxxxx; Tarek Saad <tsaad.net@xxxxxxxxx>
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@xxxxxxxx]
代表 Xufeng Liu
发送时间: 2019年6月21日 19:18
收件人: tom petch <ietfa@xxxxxxxxxxxxx>
抄送: Igor Bryskin <Igor.Bryskin@xxxxxxxxxx>; ietf <ietf@xxxxxxxx>;
db3546@xxxxxxx;
teas-chairs@xxxxxxxx; teas@xxxxxxxx;
draft-ietf-teas-yang-te-types@xxxxxxxx; Tarek Saad <tsaad.net@xxxxxxxxx>
主题: Re: [Teas] Last Call: <draft-ietf-teas-yang-te-types-09.txt> (Traffic Engineering Common YANG Types) to Proposed Standard
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;
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@xxxxxxxxxxxxx>
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@xxxxxxxxx>
> To: "tom petch" <daedulus@xxxxxxxxxxxxx>; <ietf@xxxxxxxx>; "Igor
> Bryskin" <Igor.Bryskin@xxxxxxxxxx>
> Cc: <draft-ietf-teas-yang-te-types@xxxxxxxx>; <teas-chairs@xxxxxxxx>;
> <teas@xxxxxxxx>; <db3546@xxxxxxx>
> 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@xxxxxxxx on behalf of
daedulus@xxxxxxxxxxxxx> 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@xxxxxxxx>
> > 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@xxxxxxxx mailing lists by 2019-05-16. Exceptionally,
> comments may
> > be
> > > sent to iesg@xxxxxxxx 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@xxxxxxxx
> > https://www.ietf.org/mailman/listinfo/teas
> >
> >
>
>
> ----------------------------------------------------------------------
--
> --------
>
>
> > _______________________________________________
> > Teas mailing list
> > Teas@xxxxxxxx
> > https://www.ietf.org/mailman/listinfo/teas
> >
>
|
