Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Leeyoung <> Wed, 10 October 2018 14:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 29509130DF4 for <>; Wed, 10 Oct 2018 07:21:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Nm5iZV0VMHad for <>; Wed, 10 Oct 2018 07:21:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 37D0A130F1D for <>; Wed, 10 Oct 2018 07:21:45 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id EEB8473AF2B70 for <>; Wed, 10 Oct 2018 15:21:40 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 10 Oct 2018 15:21:42 +0100
Received: from ([]) by ([]) with mapi id 14.03.0415.000; Wed, 10 Oct 2018 07:21:33 -0700
From: Leeyoung <>
To: Gert Grammel <>, "" <>
Thread-Topic: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt
Thread-Index: AQHUVkGL5mO3Xgo7fUK6a5SlBwHaT6UYtksA///jxiA=
Date: Wed, 10 Oct 2018 14:21:31 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E173D0680EFsjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.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: Wed, 10 Oct 2018 14:21:50 -0000

Hi Gert,

In the current WSON model, we have the following:

augment /nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point:
    +--rw supported-operational-modes*    te-wson-types:operational-mode
    +--rw configured-operational-modes?   te-wson-types:operational-mode
    +--rw supported-fec-types*            identityref
    +--rw supported-termination-types*    identityref
    +--rw supports-bit-stuffing?          boolean

So we are describing application codes in the TTP. Is this what you meant to describe application code in the Termination Point?


From: Gert Grammel []
Sent: Wednesday, October 10, 2018 3:54 AM
Cc: Dieter Beller <>om>; Leeyoung <>om>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <>
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

The draft triggered a question about the approach we are using in ccamp to address WSON going forward. In the past, the group aimed for alignment with ITU-T and using application codes to describe optical capabilities. Is this still the way forward?
If so, my expectation would be to find application codes as description of termination points.
If the view changed, it should be spelled out.


From: CCAMP <<>> on behalf of Dieter Beller <<>>
Organization: Nokia
Date: Thursday, September 27, 2018 at 11:07
To: 'Leeyoung' <<>>, Zhenghaomian <<>>
Cc: CCAMP <<>>
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi Young and Haomian,

I had a look at draft-lee-ccamp-wson-impairment-yang-00, which you submitted a few weeks ago and I have the following concerns:

The abstract and introduction states:


   This document provides a YANG data model for the impairment-aware TE

   topology in wavelength switched optical networks (WSONs).

1. Introduction


   This document provides a YANG data model for the impairment-aware

   Traffic Engineering (TE) topology in wavelength switched optical

   networks (WSONs). The YANG model described in this document is a

   WSON technology-specific Yang model based on the information model

   developed in [RFC7446<>] and the two encoding documents [RFC7581<>] and

   [RFC7579<>] that developed protocol independent encodings based on


Based on this scope, I was expecting that this I-D provides te-link augmentations for WSON networks.
Examples of WSON specific te-link attributes are fiber type, spectrum availability, chromatic dispersion, PMD, PDL, OSNR contribution (if the link includes ILAs) just to list a few.

However, the only te-link augmentation is:

     augment /nw:networks/nw:network/nt:link/tet:te/tet:te-link-attributes:

       +--ro power?   int32

It is also reasonable to define WSON augmentations for termination points representing the line side of optical transponders as they can be considered as topological elements
even if these attributes are not representing optical impairments!:

     augment /nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point:

       +--ro available-modulation*   identityref

       +--ro modulation-enabled?     boolean

       +--ro modulation-type?        identityref

       +--ro available-FEC*          identityref

       +--ro FEC-enabled?            boolean

       +--ro FEC-type?               identityref

       +--ro FEC-code-rate?          decimal64

       +--ro FEC-threshold?          decimal64

I don't understand why all the OT attributes are defined as ro attributes. State of the art OTs typically provide multiple operational modes. Hence, these attributes should
be defined as rw attributes.

All other augmentations are defined for paths (te-tunnels) or termination points, which is a bit strange! Here are two examples:

     augment /nw:networks/nw:network/nt:link/tet:te/tet:te-link-




          +--rw (grid-type)?

          |  +--:(dwdm)

          |  |  +--ro channel-freq?         decimal64

          |  +--:(cwdm)

          |     +--ro channel-wavelength?   uint32

          +--ro bit-rate?             decimal64

          +--ro BER?                  decimal64

          +--ro pmd?                  decimal64

          +--ro cd?                   decimal64

          +--ro osnr?                 decimal64

          +--ro q-factor?             decimal64

channel-freq/channel-wavelength, bit-rate, BER are definitively service (te-tunnel) attributes and do not represent optical impairments for a WSON network topology.
For pmd, cd, and q-factor (definition?), it looks like these are attributes for all the links along the path. Why are these impairments defined for a path and are not te-link

I was expecting that this draft defines optical impairments for the topological entities in a WSON network where optical impairments matter. Could you please clarify.


On 01.09.2018 05:42,<> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : A Yang Data Model for Impairment-Aware WSON Optical Networks

        Authors         : Young Lee

                          Haomian Zheng

  Filename        : draft-lee-ccamp-wson-impairment-yang-00.txt

  Pages           : 18

  Date            : 2018-08-31


   This document provides a YANG data model for the impairment-aware TE

   topology in wavelength switched optical networks (WSONs).

The IETF datatracker status page for this draft is:<>

There are also htmlized versions 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:<>


I-D-Announce mailing list<><>

Internet-Draft directories:<>