Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-yang-18.txt

From: [email-masked]
Date: Wed, 05 Dec 2018 09:18:01 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane WG of the IETF.

        Title           : A YANG Data Model for WSON (Wavelength Switched Optical Networks)
        Authors         : Young Lee
                          Dhruv Dhody
                          Aihua Guo
                          Victor Lopez
                          Daniel King
	Filename        : draft-ietf-ccamp-wson-yang-18.txt
	Pages           : 77
	Date            : 2018-12-05

Abstract:
   This document provides a YANG data model for the routing and
   wavelength assignment (RWA) TE topology in wavelength switched
   optical networks (WSONs). The YANG data model defined in this
   document conforms to the Network Management Datastore Architecture
   defined in RFC 8342.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ccamp-wson-yang-18
https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-wson-yang-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-wson-yang-18

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Leeyoung <[email-masked]>
Date: Wed, 5 Dec 2018 17:23:19 +0000

Hi,

This revision, we hope, incorporated all comments from Tom and others. The co-authors believe that it is ready for WG LC. 

Thanks & best regards,
Young

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, December 5, 2018 11:18 AM
To: [email-masked]
Cc: [email-masked]
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-yang-18.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: tom petch <[email-masked]>
Date: Fri, 7 Dec 2018 12:48:41 +0000

----- Original Message -----
From: "Leeyoung" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, December 05, 2018 5:23 PM
>
> This revision, we hope, incorporated all comments from Tom and others.
The co-authors believe that it is ready for WG LC.

Almost but I fear that there is a step backwards as well.

You still have two
Wavelenghth
which should probably be
Wavelength

More problematically, you have introduced

  description
    " ...
     The YANG model described in this document is a WSON
     technology-specific YANG model augmenting the generic TE
     topology module [TE-TOPO] based on the information model
     developed in [RFC7446] and the two encoding documents
     [RFC7581] and [RFC7579] that developed protocol independent
     encodings based on [RFC7446].

Those [RFC..] look like XML/HTML style references which will not do.  A
YANG module must be plain text so
  RFC6163
is fine in a YANG module but
  [RFC6163]
is not, which is why, in my last comment, I suggested putting a
reference to RFC6163 in section 1.4 lest you get an unused reference for
the I-D; which you have done, so that is fine, but all those [RFC...] in
the YANG module must go.  AFAICS it is only the description clause that
has them.

For TE-TOPO, you need to use the same text as you have correctly done on
the YANG import statement i.e.

 "RFC YYYY: YANG Data Model for Traffic Engineering (TE) Topologies";

/* Note: The RFC Editor will replace YYYY with the number assigned to
the RFC once draft-ietf-teas-yang-te-topo becomes an RFC.*/

Whether this is fixed before or after Last Call is one for the WG
Chairs.

I probably said before that the nature of the module, which you are
forced to use because of the way that tet: is structured, makes the
module very hard to read and that I have not done; I hope to but may
never find the time.

Tom Petch

> Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.

---

From: "Beller, Dieter (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Fri, 7 Dec 2018 14:03:11 +0000

Hi Young,

IMO this augmentation has issues:

     augment /nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point:
       +-rw supported-operational-modes*    layer0-types:operational-mode
       +-rw configured-operational-modes?   layer0-types:operational-mode
       +-rw supported-fec-types*            identityref
       +-rw supported-termination-types*    identityref
       +-rw supports-bit-stuffing?          boolean
       +-rw is-tunable?                     boolean
       +-rw max-subcarrier-channel-num?     uint8

supported-operational-modes should be ro

configured-operational-modes should be configured-operational-mode (without "s", singular)

supported-fec-types is normally included in the supported-operational-modes

max-subcarrier-channel-num:  I thought that in case of inverse multiplexing, a termination-point is needed for each (sub-)carrier. There might be carrier-specific
properties that differ from (sub-)carrier to (sub-)carrier. It needs to be clarified also whether the tunnel-termination-point is encompassing all (sub-)carriers that are
forming an inverse multiplexing group.

supports-bit-stuffing: meaning is unclear and the description below doesn't say anything where and how bit-stuffing is applied. This is a property of the
mapping function that maps a client signal into a server layer frame, I suppose.

    leaf supports-bit-stuffing {
       type boolean;
       description
         "Indicates whether bit stuffing is supported by this TTP";

Thanks,
Dieter

On 05.12.2018 18:23, Leeyoung wrote:

Hi,

Thanks & best regards,
Young

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, December 5, 2018 11:18 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-yang-18.txt

Abstract:

_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp

_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp

---

From: "Aihuaguo (Aihua Guo, CRC)" <[email-masked]>
Date: Fri, 7 Dec 2018 16:57:37 +0000

Hi Dieter,

For “supported-fec-types”, do we have all of the FEC types (standard and vendor-specific) that can be covered by the operational modes? If yes then I think we can remove this parameter.

For inverse multiplexing, or “super channel”, this TTP represent all of the subcarriers of the super channel, and my understanding is usually all subcarrier channels in a super channel go through the same route and has the same optical characteristics except for different wavelength, otherwise it will be too difficult to manage and optically engineer it.

For  bit stuffing, it is used for mapping constant bit-rate tributary signals to ODU frame to accommodate high clock accuracies. We need to understand the capabilities for both ends of the TTPs by using the topology model and create OCH trails by coordinating this setting at both ends of the transponder.

Aihua

From: CCAMP [mailto:[email-masked]] On Behalf Of Beller, Dieter (Nokia - DE/Stuttgart)
Sent: Friday, December 07, 2018 9:03 AM
To: Leeyoung <[email-masked]>; [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-yang-18.txt

Hi Young,

Thanks,
Dieter

Hi,

Thanks & best regards,

Young

-----Original Message-----

        Authors         : Young Lee

                          Dhruv Dhody

                          Aihua Guo

                          Victor Lopez

                          Daniel King

  Pages           : 77

  Date            : 2018-12-05

Abstract:

   defined in RFC 8342.

CCAMP mailing list

CCAMP mailing list

---

From: Leeyoung <[email-masked]>
Date: Fri, 7 Dec 2018 17:01:34 +0000

Hi Aihua and Dieter,

One more thing to add on FEC type:

Actually ITU-T G.698.2 Application Codes DScW-ytz(v) or B-DScW-ytz(v) does not mandate FEC code. It says: “An optional F can be added to indicate a FEC encoding”. Thus, I think we can add supported-fec-types here.

Thanks.
Young

From: Aihuaguo (Aihua Guo, CRC)
Sent: Friday, December 7, 2018 10:58 AM
To: Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-wson-yang-18.txt

Hi Dieter,

Aihua

From: CCAMP [mailto:[email-masked]] On Behalf Of Beller, Dieter (Nokia - DE/Stuttgart)
Sent: Friday, December 07, 2018 9:03 AM
To: Leeyoung <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-yang-18.txt

Hi Young,

Thanks,
Dieter

Hi,

Thanks & best regards,

Young

-----Original Message-----

        Authors         : Young Lee

                          Dhruv Dhody

                          Aihua Guo

                          Victor Lopez

                          Daniel King

  Pages           : 77

  Date            : 2018-12-05

Abstract:

   defined in RFC 8342.

CCAMP mailing list

CCAMP mailing list

---

From: Leeyoung <[email-masked]>
Date: Fri, 7 Dec 2018 17:04:50 +0000

Sorry I forgot to add the following response.

YL>> Agree.

YL>> Agree.

Thanks.
Young

From: Leeyoung
Sent: Friday, December 7, 2018 11:02 AM
To: Aihuaguo (Aihua Guo, CRC) <[email-masked]>; Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>; [email-masked]
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-wson-yang-18.txt

Hi Aihua and Dieter,

Thanks.
Young

From: Aihuaguo (Aihua Guo, CRC)
Sent: Friday, December 7, 2018 10:58 AM
To: Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]<mailto:[email-masked]>>; Leeyoung <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-wson-yang-18.txt

Hi Dieter,

Aihua

Hi Young,

Thanks,
Dieter

Hi,

Thanks & best regards,

Young

-----Original Message-----

        Authors         : Young Lee

                          Dhruv Dhody

                          Aihua Guo

                          Victor Lopez

                          Daniel King

  Pages           : 77

  Date            : 2018-12-05

Abstract:

   defined in RFC 8342.

CCAMP mailing list

CCAMP mailing list

---

From: Leeyoung <[email-masked]>
Date: Fri, 14 Dec 2018 15:22:14 +0000

Hi Tom,

Thanks for your further comment. It is well noted and agreed. Please see inline for additional comment. 

Thanks.
You ng

-----Original Message-----
From: tom petch [mailto:[email-masked]] 
Sent: Friday, December 7, 2018 6:49 AM
To: Leeyoung <[email-masked]>; [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-yang-18.txt

----- Original Message -----
From: "Leeyoung" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, December 05, 2018 5:23 PM

You still have two
Wavelenghth
which should probably be
Wavelength

YL>> Yes, thanks for catching this. 

  description
    " ...

Those [RFC..] look like XML/HTML style references which will not do.  A YANG module must be plain text so
  RFC6163
is fine in a YANG module but
  [RFC6163]
is not, which is why, in my last comment, I suggested putting a reference to RFC6163 in section 1.4 lest you get an unused reference for the I-D; which you have done, so that is fine, but all those [RFC...] in the YANG module must go.  AFAICS it is only the description clause that has them.

YL>> OK. Will remove the reference brackets within the YANG modules. 

For TE-TOPO, you need to use the same text as you have correctly done on the YANG import statement i.e.

/* Note: The RFC Editor will replace YYYY with the number assigned to the RFC once draft-ietf-teas-yang-te-topo becomes an RFC.*/

YL>> OK. 

Whether this is fixed before or after Last Call is one for the WG Chairs.

I probably said before that the nature of the module, which you are forced to use because of the way that tet: is structured, makes the module very hard to read and that I have not done; I hope to but may never find the time.

YL>> Yes, we are augmenting all groupings from TE-topo model which is in the RFC Editor's Queue now and any fix should've been done before this stage. 

Tom Petch

> Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at tools.ietf.org.