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

Jonas Mårtensson <> Wed, 17 October 2018 14:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB8A612F1AB for <>; Wed, 17 Oct 2018 07:04:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Pe-yQboNlbkC for <>; Wed, 17 Oct 2018 07:04:19 -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 5DF941277C8 for <>; Wed, 17 Oct 2018 07:04:18 -0700 (PDT)
Received: from 1gCmQo-000Iii-V7 by with emc1-ok (Exim 4.90_1) (envelope-from <>) id 1gCmQp-000Ilq-Tk; Wed, 17 Oct 2018 07:04:15 -0700
Received: by emcmailer; Wed, 17 Oct 2018 07:04:15 -0700
Received: from [] ( by with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from <>) id 1gCmQo-000Iii-V7; Wed, 17 Oct 2018 07:04:14 -0700
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 17 Oct 2018 16:04:14 +0200
Received: from ([fe80::fdbc:7a64:9028:cb77]) by ([fe80::fdbc:7a64:9028:cb77%21]) with mapi id 15.01.1466.008; Wed, 17 Oct 2018 16:04:14 +0200
From: =?utf-8?B?Sm9uYXMgTcOlcnRlbnNzb24=?= <>
To: Leeyoung <>, Dieter Beller <>, "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <>
CC: "" <>
Thread-Topic: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt
Date: Wed, 17 Oct 2018 14:04:14 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US, sv-SE
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_a5e9aa4ec49b4cca86f2a62b8dd6efd0rise_"
MIME-Version: 1.0
X-Proto: esmtps
X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128
X-Virus-Status: Scanned by VirusSMART (c)
X-Virus-Status: Scanned by VirusSMART (s)
X-PolicySMART: 14510320
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, 17 Oct 2018 14:04:24 -0000

Thanks Young,

See inline for some further comments.


From: Leeyoung <>
Sent: den 16 oktober 2018 22:27
To: Jonas Mårtensson <>se>; Dieter Beller <>om>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <>
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi Jonas,

Thanks for providing good comments. Please see inline for my response.

Best regards,

From: Jonas Mårtensson []
Sent: Tuesday, October 16, 2018 2:36 AM
To: Leeyoung <<>>; Dieter Beller <<>>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <<>>
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi Young,

I had a look at the model in the github and I have some questions:

About modulation: You have DP_ (Dual Polarization) variants for QPSK and QAM16 but not for QAM8. Is that just an oversight? Also you have DC_ (Dual Carrier?) only for DP_QAM16. Why not for the others?

YL>> Yes, it was an oversight. We just added 8QAM, but did not add variants of that. Can you point out any missing ones in a more exhaustive fashion, that will be good. Why don’t you add issues in the github as well.

JM>> Coming up with an exhaustive list of modulation types is rather challenging. Especially with new techniques like probabilistic shaping, fractional QAM, hybrid modulation etc., coming up. Similar to the case with FEC types, I think there are two separate issues. One is matching of signaling compatibility as you mention below. This issue seems difficult to solve without standardized interfaces since e.g. QAM8 from one vendor may not be compatible with QAM8 from a different vendor. The other issue is having information about spectral efficiency (in terms of useful bits/symbol) and required OSNR for available modulation types. This would allow the path computation to select the proper modulation depending on required capacity and actual OSNR. An attribute for representing that seems feasible.

About link (fiber) attributes: since you added a number of attributes in the latest version (e.g. cd and pmd) why not also add loss and distance?

YL>> We can certainly add a few more relevant parameters. Distance is fine. As for loss, do you mean fiber attenuation loss, or that + connector loss and splice loss included? Isn’t fiber loss pretty much deterministic given the fiber type and distance and wavelength? Or you want this to be measured by the system and report just as any other parameter?

JM>> I meant total loss per amplifier span including connector and splice loss. Ideally measured and reported by the system. This of course requires that each amplifier span (and each in-line amplifier) is represented in the WSON topology.

Specifically about link attribute “power”: The description now says “Total Input Power Level at the line port of the link”. In the previous version it said "Input Power Level of the receiver side of the link". So which side of the link does the attribute refer to? Why not include power level both at the transmit and receive sides? On the other hand, how is this attribute supposed to be used for path computation since the power level anyway does not represent the new connection (not yet setup) for which path computation is performed.

YL>> I think power attribute of the link would give path computation certain links to avoid if the power level is too low. We can add a power level at the transmitter side if it is useful.

JM>> Are we talking about power level at each amplifier or at the transponder? Power level at each amplifier (both input and output) would be useful both for computing OSNR and nonlinear effects. Ideally per channel.

How are the “path” attributes (BER, etc.) meant to be used for path computation?

YL>> I think these values give the “health” of the existing paths. Based on some indicators of these data, the controller may create a new path to avoid degradation of the existing path.

About transponder attributes: Why is the exact FEC-type needed for path computation? Would it not be sufficient to know the FEC-threshold? Another transponder attribute that could be useful to have is required OSNR (per modulation-type).

YL>> Perhaps not for path computation. I was thinking that FEC-type at both ends have to match from a perspective of signaling compatibility. For OSNR for modulation-type can be added.


From: Leeyoung <<>>
Sent: den 15 oktober 2018 19:03
To: Dieter Beller <<>>; Jonas Mårtensson <<>>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <<>>
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi Dieter,

What I meant a new scope of this draft is to combine flexi-grid with WSON (fixed-grid) as we discussed in the last week’s meeting. In regards to your point on separating the topology and the tunnel model, I agree. We haven’t got to the tunnel model yet. Please check the latest model in the github:

Please find the latest model per our meeting:

and its tree:


From: Dieter Beller []
Sent: Monday, October 15, 2018 10:46 AM
To: Leeyoung <<>>; Jonas Mårtensson <<>>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <<>>
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi Young, all,

it would be great if you could share the new scope on the list before you submit the new version. This will allow folks to send comments to the list.

One of my comments was that the current 00-draft is defining augmentations, which are TE-topology related, and other augmentations that are tunnel-related
not aligned with the current scope.

I would clearly prefer separate drafts for these 2 different categories.

On 12.10.2018 16:14, Leeyoung wrote:
Hi Jonas,

Thanks for your comment. We are updating the draft including the change of the names and the scope. As Haomiana and Gabriele shared their view, we are trying to harmonize with other impairment-related work for GMPLS/WSON.


From: Jonas Mårtensson []
Sent: Friday, October 12, 2018 2:34 AM
To: Leeyoung <><>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <><>
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi Young and Haomian,

Interesting draft. What is the relation to other WSON impairment drafts (wson-iv-info and wson-iv-encode)? Are you proposing a completely different approach here since you do not refer to those drafts?


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:



CCAMP mailing list<>