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

"Aihuaguo (Aihua Guo, CRC)" <> Fri, 07 December 2018 16:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42629130EB9 for <>; Fri, 7 Dec 2018 08:58:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id muVGpdyNu3lM for <>; Fri, 7 Dec 2018 08:58:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D23E7130EBA for <>; Fri, 7 Dec 2018 08:57:56 -0800 (PST)
Received: from (unknown []) by Forcepoint Email with ESMTP id 793CAFBB9190E for <>; Fri, 7 Dec 2018 16:57:50 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 7 Dec 2018 16:57:51 +0000
Received: from ([]) by ([]) with mapi id 14.03.0415.000; Fri, 7 Dec 2018 08:57:38 -0800
From: "Aihuaguo (Aihua Guo, CRC)" <>
To: "Beller, Dieter (Nokia - DE/Stuttgart)" <>, Leeyoung <>, "" <>
Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-wson-yang-18.txt
Thread-Index: AQHUjL6hm7jkImUftkGLqTd0lA5R5qVw6w2AgALsv4D//6ZiIA==
Date: Fri, 7 Dec 2018 16:57:37 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_AEF103518CA8F84D97E39F644BC803CB28A45BE8SJCEML521MBBchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-yang-18.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Dec 2018 16:58:02 -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.


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

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;
         "Indicates whether bit stuffing is supported by this TTP";


On 05.12.2018 18:23, Leeyoung wrote:


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,


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

From: CCAMP [] On Behalf Of<>

Sent: Wednesday, December 5, 2018 11:18 AM



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

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


   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:

There are also htmlized versions available at:

A diff from the previous version is available at:

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

Internet-Drafts are also available by anonymous FTP at:


CCAMP mailing list<>


CCAMP mailing list<>