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

From: Gert Grammel <[email-masked]>
Date: Wed, 10 Oct 2018 08:53:36 +0000

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.

Gert

From: CCAMP <[email-masked]> on behalf of Dieter Beller <[email-masked]>
Organization: Nokia
Date: Thursday, September 27, 2018 at 11:07
To: 'Leeyoung' <[email-masked]>, Zhenghaomian <[email-masked]>
Cc: CCAMP <[email-masked]>
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:

Abstract

   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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7446&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=zk3zS00lx60_LBxIKggxhMkHsPCBJ4biAFdpDYpeTGA&s=t3EVJKIBbfBziQCv67C_SIGqCsL1lLO5QfzEzD1wC0Y&e=>] and the two encoding documents [RFC7581<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7581&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=zk3zS00lx60_LBxIKggxhMkHsPCBJ4biAFdpDYpeTGA&s=S4OUJ2my7xLw9DxcGX9NUyph3GbY44XOtQud1wwYp-A&e=>] and

   [RFC7579<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7579&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=zk3zS00lx60_LBxIKggxhMkHsPCBJ4biAFdpDYpeTGA&s=V6LYiY4JVdT0RvJb6BoDJ0MWyLwIBz-nlotLCl8iNWk&e=>] that developed protocol independent encodings based on

   [RFC7446<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7446&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=zk3zS00lx60_LBxIKggxhMkHsPCBJ4biAFdpDYpeTGA&s=t3EVJKIBbfBziQCv67C_SIGqCsL1lLO5QfzEzD1wC0Y&e=>].

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-

   attributes/tet:underlay/tet:primary-path/tet:path-

   element/tet:type/tet:label/tet:label-hop/tet:te-label/tet:technology:

       +--:(wson-imp-topo)

          +--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
augmentations?

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.

Thanks,
Dieter

On 01.09.2018 05:42, [email-masked]<mailto:[email-masked]> 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

Abstract:

   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:

https://datatracker.ietf.org/doc/draft-lee-ccamp-wson-impairment-yang/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dlee-2Dccamp-2Dwson-2Dimpairment-2Dyang_&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=zk3zS00lx60_LBxIKggxhMkHsPCBJ4biAFdpDYpeTGA&s=uI9XVdKyAYxfJxgBNbJzFb7PcL4ucbR7pQ3vwpUtFww&e=>

There are also htmlized versions available at:

https://tools.ietf.org/html/draft-lee-ccamp-wson-impairment-yang-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dlee-2Dccamp-2Dwson-2Dimpairment-2Dyang-2D00&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=zk3zS00lx60_LBxIKggxhMkHsPCBJ4biAFdpDYpeTGA&s=9LRKj19B6QDmn2a-h5BQmCAtnorDM8ZXdbZeH9OrK3U&e=>

https://datatracker.ietf.org/doc/html/draft-lee-ccamp-wson-impairment-yang-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dlee-2Dccamp-2Dwson-2Dimpairment-2Dyang-2D00&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=zk3zS00lx60_LBxIKggxhMkHsPCBJ4biAFdpDYpeTGA&s=yYQwBhf6k5pjyQs5AzU42jJPSWagS6hRERQh6xmBKpQ&e=>

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/<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=zk3zS00lx60_LBxIKggxhMkHsPCBJ4biAFdpDYpeTGA&s=INR37WxNxA8xTIwaS6H619I9PtANk9yce9uZ5K0JUPo&e=>

_______________________________________________

I-D-Announce mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/i-d-announce<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_i-2Dd-2Dannounce&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=zk3zS00lx60_LBxIKggxhMkHsPCBJ4biAFdpDYpeTGA&s=y7F8N-yRSsfKTyuRhcdGIldonUXJm1JjYAVeCDOpKGA&e=>

Internet-Draft directories: http://www.ietf.org/shadow.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_shadow.html&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=zk3zS00lx60_LBxIKggxhMkHsPCBJ4biAFdpDYpeTGA&s=3I5S3Q84_0hym70TgOlwjPHUfcqCWflXKfQQNwLIdTE&e=>

or ftp://ftp.ietf.org/ietf/1shadow-sites.txt<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_ietf_1shadow-2Dsites.txt&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=zk3zS00lx60_LBxIKggxhMkHsPCBJ4biAFdpDYpeTGA&s=nqyp7tceQcl0YDvaQkoXSngBC3d39UaNlPP564Bjj0A&e=>

---

From: Leeyoung <[email-masked]>
Date: Wed, 10 Oct 2018 14:21:31 +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?

Thanks.
Young

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

Gert

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

Hi Young and Haomian,

Abstract

1. Introduction

   ...

       +--ro power?   int32

       +--:(wson-imp-topo)

          +--rw (grid-type)?

          |  +--:(dwdm)

          |  +--:(cwdm)

          +--ro BER?                  decimal64

          +--ro pmd?                  decimal64

          +--ro cd?                   decimal64

          +--ro osnr?                 decimal64

Thanks,
Dieter

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

---

From: Gert Grammel <[email-masked]>
Date: Wed, 10 Oct 2018 14:41:49 +0000

Yang,

I was referring to

For example:
The modulation is part of the application code (from the actual G.698.2 a bit shortened for readability):
The application code notation is constructed as follows: DScW-ytz(v)
where,
D is the indicator of DWDM applications.
S indicates options of maximum spectral excursion such as:
·         –  N indicating narrow spectral excursion.
·         –  W indicating wide spectral excursion. c is the channel spacing in GHz.
W indicates the black link dispersion compensation regime as follows:
·         –  C indicating that the chromatic dispersion values are appropriate to a black link that is
dispersion compensated.
·         –  U indicating that the chromatic dispersion values are appropriate to a black link that is dispersion uncompensated.
y indicates the highest class of optical tributary signal supported:
o    –  1 indicating NRZ 2.5G.
o    –  2 indicating NRZ 10G.
t is a letter indicating the configuration supported by the application code. In the current version of this Recommendation, the only value used is:
– A indicating that the black link may contain optical amplifiers. z indicates the fibre types, as follows:
·         –  2 indicating ITU-T G.652 fibre.
·         –  3 indicating ITU-T G.653 fibre.
·         –  5 indicating ITU-T G.655 fibre.
v indicates the operating wavelength range in terms of spectral bands (see [b-ITU-T G-Sup.39]):
If more than one spectral band is used, then v becomes the band letters separated by "+", e.g., for an application requiring the use of both of the C and L bands, v would be "C+L".
For some application codes, a suffix is added to the end of the code. The only suffix currently defined is:
– F to indicate that this application requires FEC bytes as specified in [ITU-T G.709] to be transmitted.

So under the assumption the application code is defined for the tunnel termination point:
augment /nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point:
       +--ro available-modulation*   identityref --> Parameter y
       +--ro modulation-enabled?     Boolean --> the code defines only one modulation, not enabled/disabled
       +--ro modulation-type?        Identityref --> parameter y
       +--ro available-FEC*          identityref --> parameter F is a Boolean
       +--ro FEC-enabled?            Boolean  --> enabled/disabled would result in two different application codes (with and without tailing F)
       +--ro FEC-type?               Identityref --> F
       +--ro FEC-code-rate?          decimal64 --> since F is defined, this one is defined too
       +--ro FEC-threshold?          decimal64 --> since F is defined, this one is defined too

Best

Gert

From: 'Leeyoung' <[email-masked]>
Date: Wednesday, October 10, 2018 at 16:21
To: Gert Grammel <[email-masked]>, CCAMP <[email-masked]>
Cc: Dieter Beller <[email-masked]>, "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <[email-masked]>
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi Gert,

Thanks.
Young

Gert

Hi Young and Haomian,

Abstract

1. Introduction

   ...

       +--ro power?   int32

       +--:(wson-imp-topo)

          +--rw (grid-type)?

          |  +--:(dwdm)

          |  +--:(cwdm)

          +--ro BER?                  decimal64

          +--ro pmd?                  decimal64

          +--ro cd?                   decimal64

          +--ro osnr?                 decimal64

Thanks,
Dieter

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

---

From: Leeyoung <[email-masked]>
Date: Wed, 10 Oct 2018 14:51:43 +0000

Hi Gert,

Yes, that is the direction we are taking with the impairment model.

Thanks.
Young

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

Yang,

I was referring to

For example:

Best

Gert

From: 'Leeyoung' <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 10, 2018 at 16:21
To: Gert Grammel <[email-masked]<mailto:[email-masked]>>, CCAMP <[email-masked]<mailto:[email-masked]>>
Cc: Dieter Beller <[email-masked]<mailto:[email-masked]>>, "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi Gert,

Thanks.
Young

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

Gert

Hi Young and Haomian,

Abstract

1. Introduction

   ...

       +--ro power?   int32

       +--:(wson-imp-topo)

          +--rw (grid-type)?

          |  +--:(dwdm)

          |  +--:(cwdm)

          +--ro BER?                  decimal64

          +--ro pmd?                  decimal64

          +--ro cd?                   decimal64

          +--ro osnr?                 decimal64

Thanks,
Dieter

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

---

From: Gert Grammel <[email-masked]>
Date: Wed, 10 Oct 2018 15:06:43 +0000

Young,

Unfortunately I wasn’t able to properly compile your last email. What do you have in mind with “THAT”?
                                <snip> Yes, THAT is the direction we are taking with the impairment model. <snip>

  1.  If “that” means using G.698.2 application codes, the draft would need to be changed substantially
  2.  If “that” means draft-lee-ccamp-wson-impairment-yang-00 as-is, it would question the use of application codes and discussion in the WG.

Thanks

Gert

Date: Wednesday, October 10, 2018 at 16:51

Hi Gert,

Thanks.
Young

Yang,

I was referring to

For example:

Best

Gert

Hi Gert,

Thanks.
Young

Gert

Hi Young and Haomian,

Abstract

1. Introduction

   ...

       +--ro power?   int32

       +--:(wson-imp-topo)

          +--rw (grid-type)?

          |  +--:(dwdm)

          |  +--:(cwdm)

          +--ro BER?                  decimal64

          +--ro pmd?                  decimal64

          +--ro cd?                   decimal64

          +--ro osnr?                 decimal64

Thanks,
Dieter

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

---

From: Leeyoung <[email-masked]>
Date: Wed, 10 Oct 2018 15:20:39 +0000

Hi Gert,

The direction is to keep WSON as is and would add explicit property of Modulation/FEC types, etc. in the augmented impairment model.

For WSON-topology, the format is series of “string”.  We would keep this format in  WSON-model. What do you need to see more for this case?

typedef operational-mode {
    type string;
    description
      "Vendor-specific mode that guarantees interoperability.
       It must be an string with the following format:
       B-DScW-ytz(v) where all these attributes are conformant
       to the ITU-T recomendation";
    reference "ITU-T G.698.2 (11/2009) Section 5.3";
  }

Now, when you want impairment model augmented from WSON, we would like to use the TTP to describe explicitly each component. Let us know what do you want to see more from the following?

Thanks.
Young
Sent: Wednesday, October 10, 2018 10:07 AM

Young,

Thanks

Gert

Hi Gert,

Thanks.
Young

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

Yang,

I was referring to

For example:

Best

Gert

Hi Gert,

Thanks.
Young

Gert

Hi Young and Haomian,

Abstract

1. Introduction

   ...

       +--ro power?   int32

       +--:(wson-imp-topo)

          +--rw (grid-type)?

          |  +--:(dwdm)

          |  +--:(cwdm)

          +--ro BER?                  decimal64

          +--ro pmd?                  decimal64

          +--ro cd?                   decimal64

          +--ro osnr?                 decimal64

Thanks,
Dieter

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

---

From: Gert Grammel <[email-masked]>
Date: Wed, 10 Oct 2018 15:49:53 +0000

Young,

are you suggesting to do 1) and 2)? To me 1) and 2) are mutually exclusive options and I don’t really understand what is proposed.
My aim is to point out that if we keep the WSON-topology as a base, much of the augmentation proposed in your draft would be redundant. If e.g. the Application code already defines the FEC, why adding the FEC again as a separate parameter? Moreover your proposal allows to enable/disable the FEC. Doing so would also change the application code (with and without trailing-F). This doesn’t look like an elegant solution for the problem at hand.
Probably some clarifying words from our chairs could help to provide further guidance on the general approach.

Gert

Date: Wednesday, October 10, 2018 at 17:20

Hi Gert,

Thanks.
Young

Young,

Thanks

Gert

Hi Gert,

Thanks.
Young

Yang,

I was referring to

For example:

Best

Gert

Hi Gert,

Thanks.
Young

Gert

Hi Young and Haomian,

Abstract

1. Introduction

   ...

       +--ro power?   int32

       +--:(wson-imp-topo)

          +--rw (grid-type)?

          |  +--:(dwdm)

          |  +--:(cwdm)

          +--ro BER?                  decimal64

          +--ro pmd?                  decimal64

          +--ro cd?                   decimal64

          +--ro osnr?                 decimal64

Thanks,
Dieter

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

---

From: Leeyoung <[email-masked]>
Date: Wed, 10 Oct 2018 16:33:55 +0000

Hi Gert,

We introduced TTP augmentation to describe transponders. My understanding of G.698.2 application code is that it does not cover all new tributary signal types and new fiber-types. So if the application code in G.698.2 is forward-compatible, we can make use of it with a better YANG style format.

Thanks,
Young

Sent: Wednesday, October 10, 2018 10:50 AM

Young,

Gert

Hi Gert,

Thanks.
Young

Young,

Thanks

Gert

Hi Gert,

Thanks.
Young

Yang,

I was referring to

For example:

Best

Gert

Hi Gert,

Thanks.
Young

Gert

Hi Young and Haomian,

Abstract

1. Introduction

   ...

       +--ro power?   int32

       +--:(wson-imp-topo)

          +--rw (grid-type)?

          |  +--:(dwdm)

          |  +--:(cwdm)

          +--ro BER?                  decimal64

          +--ro pmd?                  decimal64

          +--ro cd?                   decimal64

          +--ro osnr?                 decimal64

Thanks,
Dieter

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

---

From: Gert Grammel <[email-masked]>
Date: Wed, 10 Oct 2018 19:59:40 +0000

Young,

“My understanding of G.698.2 application code is that it does not cover all new tributary signal types and new fiber-types” is an observation we share (see  https://tools.ietf.org/html/draft-many-coherent-dwdm-if-control-01 ). Yet that doesn’t solve the issue. Either ccamp accepts to follow ITU and use application codes, or ccamp needs to change track going for non-standard extensions and drop dependency on application codes. So far ccamp follows the first option.

Gert

Date: Wednesday, October 10, 2018 at 18:34

Hi Gert,

Thanks,
Young

Young,

Gert

Hi Gert,

Thanks.
Young

Young,

Thanks

Gert

Hi Gert,

Thanks.
Young

Yang,

I was referring to

For example:

Best

Gert

Hi Gert,

Thanks.
Young

Gert

Hi Young and Haomian,

Abstract

1. Introduction

   ...

       +--ro power?   int32

       +--:(wson-imp-topo)

          +--rw (grid-type)?

          |  +--:(dwdm)

          |  +--:(cwdm)

          +--ro BER?                  decimal64

          +--ro pmd?                  decimal64

          +--ro cd?                   decimal64

          +--ro osnr?                 decimal64

Thanks,
Dieter

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 11 Oct 2018 07:33:07 +0000

Gert, Young,

thanks for the discussion. That’s quite a dilemma.
As Gert correctly said we’ve always been following ITU and used application codes, and I’d be inclined to continue along that path. However this would put us in a stuck position for those lacking or non future proof application codes.
I’m wondering if an hybrid approach would be possible. Basically using the application codes where well defined ones exist and go for something non standard track and non application code based for the rest.

While taking the action to discuss this with Fatai and Deborah, I would also like to hear 1) the feasibility of an hybrid approach and 2) the opinion of the WG.

Thanks
Daniele

From: CCAMP <[email-masked]> On Behalf Of Gert Grammel
Sent: mercoledì 10 ottobre 2018 22:00
To: Leeyoung <[email-masked]>; [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Young,

Gert

Hi Gert,

Thanks,
Young

Young,

Gert

Hi Gert,

Thanks.
Young

Young,

Thanks

Gert

Hi Gert,

Thanks.
Young

Yang,

I was referring to

For example:

Best

Gert

Hi Gert,

Thanks.
Young

Gert

Hi Young and Haomian,

Abstract

1. Introduction

   ...

       +--ro power?   int32

       +--:(wson-imp-topo)

          +--rw (grid-type)?

          |  +--:(dwdm)

          |  +--:(cwdm)

          +--ro BER?                  decimal64

          +--ro pmd?                  decimal64

          +--ro cd?                   decimal64

          +--ro osnr?                 decimal64

Thanks,
Dieter

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 11 Oct 2018 16:22:00 +0000

Gert, Young,

actually this sort of hybrid approach already exists in RFC 7581 section 4.1.
Where both ITU and non-ITU application codes can be used:

S (Standard bit):

      S=0: identifies non-ITU code points

      S=1: identifies ITU application codes

With S=0, the OI Code Points field can take the following value:

      0: reserved

   Future work may add support for vendor-specific application codes
   once the ITU-T has completed its work in that area.

With S=1, the OI Code Points field can take the following values:

      0: reserved

      1: [G.698.1<https://tools.ietf.org/html/rfc7581#ref-G.698.1>] application code

      2: [G.698.2<https://tools.ietf.org/html/rfc7581#ref-G.698.2>] application code

      3: [G.959.1<https://tools.ietf.org/html/rfc7581#ref-G.959.1>] application code

      4: [G.695<https://tools.ietf.org/html/rfc7581#ref-G.695>] application code

BR
Daniele

From: CCAMP <[email-masked]> On Behalf Of Daniele Ceccarelli
Sent: giovedì 11 ottobre 2018 09:33
To: Gert Grammel <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Gert, Young,

Thanks
Daniele

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Gert Grammel
Sent: mercoledì 10 ottobre 2018 22:00
To: Leeyoung <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Young,

Gert

Hi Gert,

Thanks,
Young

Young,

Gert

Hi Gert,

Thanks.
Young

Young,

Thanks

Gert

Hi Gert,

Thanks.
Young

Yang,

I was referring to

For example:

Best

Gert

Hi Gert,

Thanks.
Young

Gert

Hi Young and Haomian,

Abstract

1. Introduction

   ...

       +--ro power?   int32

       +--:(wson-imp-topo)

          +--rw (grid-type)?

          |  +--:(dwdm)

          |  +--:(cwdm)

          +--ro BER?                  decimal64

          +--ro pmd?                  decimal64

          +--ro cd?                   decimal64

          +--ro osnr?                 decimal64

Thanks,
Dieter

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

---

From: Gert Grammel <[email-masked]>
Date: Thu, 11 Oct 2018 22:58:25 +0000

Daniele,

appreciate your investigation. That RFC simply provides a switch that enables non-standard implementations, but does not define them.
Moreover, the encoding is a 1:1 translation of the application code for standards An does not really provide definition for more or different parameters.
You won’t find things like FEC gain ore even FEC on/off there. IOW it is hard to see the middle ground fir a hybrid approach.What exactly is the proposal to move forward?

Best

Gert

Sent from my Apple ][

On 11. Oct 2018, at 18:22, Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>> wrote:

Gert, Young,

S (Standard bit):

      0: reserved

      0: reserved

      1: [G.698.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7581-23ref-2DG.698.1&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=jsbn4fnuT1-e93x59jI_EoA5TDTg3JmZrmmLl607E5M&s=h6wem3pHFOy661TSlfWdGhUlCpEsqYBolDMZx2JH2Jw&e=>] application code

      2: [G.698.2<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7581-23ref-2DG.698.2&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=jsbn4fnuT1-e93x59jI_EoA5TDTg3JmZrmmLl607E5M&s=9FFDPD_s4D_EOWALj93Fd0432_rIxioObjmDCxNtPw4&e=>] application code

      3: [G.959.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7581-23ref-2DG.959.1&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=jsbn4fnuT1-e93x59jI_EoA5TDTg3JmZrmmLl607E5M&s=_E_evT0wyzWMV0HYdOgSjh_R1F4PzPr7_5YXckU_EMs&e=>] application code

      4: [G.695<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7581-23ref-2DG.695&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=jsbn4fnuT1-e93x59jI_EoA5TDTg3JmZrmmLl607E5M&s=Yo84CZN5aOmNuqcxIXV3tNtUM73BE-Af8qoLPBzfRkQ&e=>] application code

BR
Daniele

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Daniele Ceccarelli
Sent: giovedì 11 ottobre 2018 09:33
To: Gert Grammel <[email-masked]<mailto:[email-masked]>>; Leeyoung <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Gert, Young,

Thanks
Daniele

Young,

“My understanding of G.698.2 application code is that it does not cover all new tributary signal types and new fiber-types” is an observation we share (see  https://tools.ietf.<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmany-2Dcoherent-2Ddwdm-2Dif-2Dcontrol-2D01&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=jsbn4fnuT1-e93x59jI_EoA5TDTg3JmZrmmLl607E5M&s=zsxj-yk_PSi3WrEIU8fcZ2Fgnxb8vlrY5BCidwhC1is&e=>https://tools.ietf.org/html/draft-many-coherent-dwdm-if-control-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmany-2Dcoherent-2Ddwdm-2Dif-2Dcontrol-2D01&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=jsbn4fnuT1-e93x59jI_EoA5TDTg3JmZrmmLl607E5M&s=zsxj-yk_PSi3WrEIU8fcZ2Fgnxb8vlrY5BCidwhC1is&e=>org/html/draft-many-coherent-dwdm-if-control-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmany-2Dcoherent-2Ddwdm-2Dif-2Dcontrol-2D01&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=jsbn4fnuT1-e93x59jI_EoA5TDTg3JmZrmmLl607E5M&s=zsxj-yk_PSi3WrEIU8fcZ2Fgnxb8vlrY5BCidwhC1is&e=> ). Yet that doesn’t solve the issue. Either ccamp accepts to follow ITU and use application codes, or ccamp needs to change track going for non-standard extensions and drop dependency on application codes. So far ccamp follows the first option.

Gert

Hi Gert,

Thanks,
Young

Young,

Gert

Hi Gert,

Thanks.
Young

Young,

Thanks

Gert

Hi Gert,

Thanks.
Young

Yang,

I was referring to

For example:

Best

Gert

Hi Gert,

Thanks.
Young

Gert

Hi Young and Haomian,

Abstract

1. Introduction

   ...

       +--ro power?   int32

       +--:(wson-imp-topo)

          +--rw (grid-type)?

          |  +--:(dwdm)

          |  +--:(cwdm)

          +--ro BER?                  decimal64

          +--ro pmd?                  decimal64

          +--ro cd?                   decimal64

          +--ro osnr?                 decimal64

Thanks,
Dieter

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

---

From: "Gabriele Maria Galimberti (ggalimbe)" <[email-masked]>
Date: Fri, 12 Oct 2018 06:59:20 +0000

Hi All,

I’d take the ITU application code as is and add new parameters in clear outside the A.C.
Of course, I’d keep the vendor specific application code too.

Best Regards,

Gabriele

[ttp://www.cisco.com/swa/i/logo.gif]

Gabriele Galimberti
Principal Engineer
Cisco Photonics Srl

via S.Maria Molgora, 48 C
20871 - Vimercate (MB)
Italy
www.cisco.com/global/IT/<http://www.cisco.com/global/IT/>

[email-masked]<mailto:[email-masked]>
Phone :+39 039 2091462
Mobile :+39 335 7481947
Fax :+39 039 2092049

From: CCAMP <[email-masked]> on behalf of Gert Grammel <[email-masked]>
Date: Friday, 12 October 2018 at 00:58
To: Daniele Ceccarelli <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Daniele,

Best

Gert

Sent from my Apple ][

S (Standard bit):

      0: reserved

      0: reserved

BR
Daniele

Gert, Young,

Thanks
Daniele

Young,

Gert

Hi Gert,

Thanks,
Young

Young,

Gert

Hi Gert,

Thanks.
Young

Young,

Thanks

Gert

Hi Gert,

Thanks.
Young

Yang,

I was referring to

For example:

Best

Gert

Hi Gert,

Thanks.
Young

Gert

Hi Young and Haomian,

Abstract

1. Introduction

   ...

       +--ro power?   int32

       +--:(wson-imp-topo)

          +--rw (grid-type)?

          |  +--:(dwdm)

          |  +--:(cwdm)

          +--ro BER?                  decimal64

          +--ro pmd?                  decimal64

          +--ro cd?                   decimal64

          +--ro osnr?                 decimal64

Thanks,
Dieter

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

---

From: "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <[email-masked]>
Date: Fri, 12 Oct 2018 08:15:44 +0000

Hi Jonas,

Thank you for the question. For this draft we aimed at not create controversial issue with wson-iv-info and wson-iv-encode, although we are reminded that some issue  detected. The impairment scenario and framework was specified in RFC6566, and we target on corresponding YANG model. I assume it is a complementary with existing work, rather than ‘totally different approach’, so we are going to reference to existing work in future version.

At this moment we are working is to coordinate with existing IETF drafts and ITU-T application code, and we expect an update in next version.

Best wishes,
Haomian

发件人: Jonas Mårtensson [mailto:[email-masked]]
发送时间: 2018年10月12日 15:34
收件人: Leeyoung <[email-masked]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]>
抄送: [email-masked]
主题: 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?

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

https://datatracker.ietf.org/doc/draft-lee-ccamp-wson-impairment-yang/

https://tools.ietf.org/html/draft-lee-ccamp-wson-impairment-yang-00

https://datatracker.ietf.org/doc/html/draft-lee-ccamp-wson-impairment-yang-00

ftp://ftp.ietf.org/internet-drafts/

https://www.ietf.org/mailman/listinfo/i-d-announce

Internet-Draft directories: http://www.ietf.org/shadow.html

or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Jonas Mårtensson <[email-masked]>
Date: Fri, 12 Oct 2018 07:34:19 +0000

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

---

From: "Gabriele Maria Galimberti (ggalimbe)" <[email-masked]>
Date: Fri, 12 Oct 2018 08:43:35 +0000

I agree Haomian,

There are many draft on the table we need to co-ordinate, like draft-galimbe-ccamp-iv-yang reflecting wson-iv-info and wson-iv-encode.
Let’s meet in Bangkok to co-ordinate.

Best Regards,

Gabriele

Gabriele Galimberti
Principal Engineer
Cisco Photonics Srl

From: CCAMP <[email-masked]> on behalf of "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <[email-masked]>
Date: Friday, 12 October 2018 at 10:15
To: Jonas Mårtensson <[email-masked]>, Leeyoung <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [CCAMP] 答复: I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi Jonas,

Best wishes,
Haomian

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

---

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

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.

Thanks.
Young

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

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

---

From: Dieter Beller <[email-masked]>
Date: Mon, 15 Oct 2018 17:46:15 +0200

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.

Thanks,

Dieter

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.

Thanks.

Young

From: Jonas Mårtensson
[mailto:[email-masked]]

To: Leeyoung <[email-masked]>;
Zhenghaomian (Zhenghaomian, Optical &Microwave
Technology Research Dept)
<[email-masked]>

Cc: [email-masked]

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?

/Jonas

On 01.09.2018 05:42, [email-masked] wrote:

Authors         : Young Lee

Haomian Zheng

Pages           : 18

Date            : 2018-08-31

Abstract:

[email-masked]

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

---

From: Leeyoung <[email-masked]>
Date: Mon, 15 Oct 2018 17:02:53 +0000

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: https://github.com/younglee-ietf/actn-wson-flexi-grid

Please find the latest model per our meeting:
https://github.com/younglee-ietf/actn-wson-flexi-grid/blob/master/ietf-optical-impairment-topology%402018-10-09.yang

and its tree:
https://github.com/younglee-ietf/actn-wson-flexi-grid/blob/master/ietf-optical-impairment-topology%402018-10-08.tree

Thanks.
Young

From: Dieter Beller [mailto:[email-masked]]
Sent: Monday, October 15, 2018 10:46 AM
To: Leeyoung <[email-masked]>; Jonas Mårtensson <[email-masked]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]>
Cc: [email-masked]
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.

Thanks,
Dieter

Thanks.
Young

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

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

[email-masked]<mailto:[email-masked]>

---

From: Jonas Mårtensson <[email-masked]>
Date: Tue, 16 Oct 2018 07:35:58 +0000

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?

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?

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.

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

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).

/Jonas

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

Hi Dieter,

and its tree:

Thanks.
Young

To: Leeyoung <[email-masked]<mailto:[email-masked]>>; Jonas Mårtensson <[email-masked]<mailto:[email-masked]>>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]<mailto:[email-masked]>>

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

---

From: "Beller, Dieter (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Tue, 16 Oct 2018 11:57:12 +0000

Hi Young, Jonas, all,

I checked again the YANG tree<https://github.com/younglee-ietf/actn-wson-flexi-grid/blob/master/ietf-optical-impairment-topology%402018-10-08.tree#L75> ([email-masked]<mailto:[email-masked]>) and particularly looked at the following augmentation:

  augment /nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point:
    +--rw transponder-id?         uint32
    +--ro available-modulation*   identityref
    +--rw modulation-enabled?     boolean
    +--rw modulation-type?        identityref
    +--ro available-FEC*          identityref
    +--rw FEC-enabled?            boolean
    +--rw FEC-type?               identityref
    +--ro FEC-code-rate?          decimal64
    +--rw FEC-threshold?          decimal64
    +--ro power?                  int32
    +--ro power-min?              int32
    +--ro power-max?              int32

these are clearly optical transponder attributes and I am wondering why the following grouping wson-ttp-attributes<https://github.com/younglee-ietf/actn-wson-flexi-grid/blob/master/ietf-optical-impairment-topology%402018-10-09.yang#L410> is not used:

  grouping wson-ttp-attributes {
     description
       "WSON tunnel termination point (e.g.tranponder) attributes";
        leaf-list available-operational-mode {
          type te-wson-types:operational-mode;
          description "List of all vendor-specific supported
          mode identifiers";
        }
        leaf operational-mode {
          type te-wson-types:operational-mode;
          description "Vendor-specific mode identifier";
        }
  }

This would make the optical transponder configuration attributes related to modulation and FEC obsolete.
A vendor-ID attribute has to be added because the operational modes vcan only be interpreted properly in the scope of a specific vendor.

More discussion is also needed regarding power attributes.

Thanks,
Dieter

On 16.10.2018 09:35, Jonas Mårtensson wrote:
Hi Young,

/Jonas

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

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

---

From: Leeyoung <[email-masked]>
Date: Tue, 16 Oct 2018 20:26:54 +0000

Hi Jonas,

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

Best regards,
Young

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

Hi Young,

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.

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?

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.

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.

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.

/Jonas

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

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

---

From: Leeyoung <[email-masked]>
Date: Tue, 16 Oct 2018 20:33:55 +0000

Hi Dieter,

Best regards,
Young

From: Beller, Dieter (Nokia - DE/Stuttgart) [mailto:[email-masked]]
Sent: Tuesday, October 16, 2018 6:57 AM
To: Jonas Mårtensson <[email-masked]>; Leeyoung <[email-masked]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]>
Cc: [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi Young, Jonas, all,

This would make the optical transponder configuration attributes related to modulation and FEC obsolete.
YL>> Yes, we are discussing if the application codes are going to be used or not. If we are limited to application code usage, then you are correct.

A vendor-ID attribute has to be added because the operational modes vcan only be interpreted properly in the scope of a specific vendor.
YL>> Can you provide some idea as to vendor-ID attribute?

YL>> Agree.

Thanks,
Dieter

/Jonas

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

---

From: Jonas Mårtensson <[email-masked]>
Date: Wed, 17 Oct 2018 14:04:14 +0000

Thanks Young,

See inline for some further comments.

/Jonas

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

Hi Jonas,

Best regards,
Young

To: Leeyoung <[email-masked]<mailto:[email-masked]>>; Dieter Beller <[email-masked]<mailto:[email-masked]>>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]<mailto:[email-masked]>>

Hi Young,

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.

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.

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.

/Jonas

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

---

From: "Beller, Dieter (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Fri, 19 Oct 2018 15:51:05 +0000

Hi Young, all,

I think that we need both, the G.698.2 application codes, which are standardized (standardized operational modes), and vendor-specific operational modes.

Operational modes represent optical transponder settings which have to be the same for the two optical transponders terminating a photonic tunnel or segment
in case the tunnel includes 3R regenerators.

The vendor-ID attribute should be of type string. We can further discuss this in Bangkok.

Thanks,
Dieter

On 16.10.2018 22:33, Leeyoung wrote:
Hi Dieter,

Best regards,
Young

To: Jonas Mårtensson <[email-masked]><mailto:[email-masked]>; Leeyoung <[email-masked]><mailto:[email-masked]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]><mailto:[email-masked]>

Hi Young, Jonas, all,

YL>> Agree.

Thanks,
Dieter

/Jonas

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

--

Dieter Beller
Open Agent & Routing Project Manager
IP/Optical Networks, Optics, Nokia

m : +49 175 7266874 | j: 8831186<ciscotel://8831186>
[email-masked]<mailto:[email-masked]>

Nokia Solutions and Networks GmbH & Co. KG
Lorenzstr. 10, 70435 Stuttgart
Sitz der Gesellschaft: München / Registered office: Munich
Registergericht: München / Commercial registry: Munich, HRA 88537
WEEE-Reg.-Nr.: DE 52984304
Persönlich haftende Gesellschafterin / General Partner: Nokia Solutions and Networks Management GmbH
Geschäftsleitung / Board of Directors: Dr. Wolfgang Hackenberg, Nils-Peter Daetz, Wilhelm Dresselhaus
Vorsitzender des Aufsichtsrats / Chairman of supervisory board: Hans-Jürgen Bill
Sitz der Gesellschaft: München / Registered office: Munich
Registergericht: München / Commercial registry: Munich, HRB 163416

This e-mail and its attachments, if any, may contain confidential information.
If you have received this e-mail in error, please notify us and delete or destroy the e-mail and its attachments, if any, immediately.
If you have received this e-mail in error, you must not forward or make use of the e-mail and its attachments, if any.

---

From: "Gabriele Maria Galimberti (ggalimbe)" <[email-masked]>
Date: Fri, 19 Oct 2018 16:52:22 +0000

Hi Young,

Looking at the schema in your github I saw the description:

    +--:(optical-imp-topo)

       +--rw (grid-type)?

       |  +--:(flexi-grid)

       |  |  +--ro central-channel-freq?   decimal64

       |  |  +--ro slot-width?             decimal64

       |  +--:(dwdm)

       |  +--:(cwdm)

Wouldn’t be better to describe the above parameters according to RFC7699 (e.g. Grid, C.S., N and M )?
This would eliminate any ugly decimal in favor of int.

Best Regards,

Gabriele

Gabriele Galimberti
Principal Engineer
Cisco Photonics Srl

From: CCAMP <[email-masked]> on behalf of Leeyoung <[email-masked]>
Date: Monday, 15 October 2018 at 19:02
To: Dieter Beller <[email-masked]>, Jonas Mårtensson <[email-masked]>, "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

---

From: "Beller, Dieter (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Fri, 19 Oct 2018 17:30:50 +0000

Hi Gabriele, Young, all,

+1

I concur with Gabriele and do also prefer n and m to specify the flex grid central frequency and signal width.

Thanks,
Dieter

From: Gabriele Maria Galimberti (ggalimbe) <[email-masked]>
Sent: Friday, October 19, 2018 4:52:22 PM
To: Leeyoung; Beller, Dieter (Nokia - DE/Stuttgart); Jonas Mårtensson; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)
Cc: [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi Young,

    +--:(optical-imp-topo)

       +--rw (grid-type)?

       |  +--:(flexi-grid)

       |  +--:(dwdm)

       |  +--:(cwdm)

Best Regards,

Gabriele

Gabriele Galimberti

Principal Engineer

Cisco Photonics Srl

20871 - Vimercate (MB)

Italy

<http://www.cisco.com/global/IT/>
www.cisco.com/global/IT/

<mailto:[email-masked]>
[email-masked]

Phone :
+39 039 2091462

Mobile :
+39 335 7481947

Fax :
+39 039 2092049

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

On 01.09.2018 05:42, [email-masked]<mailto:[email-masked]> 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   Abstract:    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: https://datatracker.ietf.org/doc/draft-lee-ccamp-wson-impairment-yang/   There are also htmlized versions available at: https://tools.ietf.org/html/draft-lee-ccamp-wson-impairment-yang-00 https://datatracker.ietf.org/doc/html/draft-lee-ccamp-wson-impairment-yang-00     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/   _______________________________________________ I-D-Announce mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 19 Oct 2018 19:25:21 +0000

That should be the approach and I’m happy to see quite some alignment on that.
As Gert pointed out RFC7581 “provides a switch that enables non-standard implementations, but does not define them”. That is fine, it’s the switch we are talking about. That allows us continue working standard application codes as well as defining new non it code points.

--- end of chair statement and start of contributor mode

I wonder whether here we are speaking about vendor specific code points or rather operator specific code points.
if we speak about vendor specific code points this means that we most likely end up with Vendor 1 supporting code points A,B,C and vendor 2 supporting D,E,F.
IMHO it is pointless to have vendor specific code points if the final scope is having equipment from vendor A interwork with equipment form vendor B. Why a standard way of configuring proprietary parameters is needed at all?

What OTOH would be useful is a set of agreed code points that allow an operator to have two equipments from different vendors interwork in a non ITU-standard way.

BR
Daniele

From: CCAMP <[email-masked]> On Behalf Of Beller, Dieter (Nokia - DE/Stuttgart)
Sent: venerdì 19 ottobre 2018 17:51
To: Leeyoung <[email-masked]>; Jonas Mårtensson <[email-masked]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]>
Cc: [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi Young, all,

Thanks,
Dieter

Best regards,
Young

Hi Young, Jonas, all,

YL>> Agree.

Thanks,
Dieter

/Jonas

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

--

Dieter Beller

---

From: Jonas Mårtensson <[email-masked]>
Date: Sat, 20 Oct 2018 13:32:33 +0000

Hi all,

In addition to G.698.2 and ITU-T, what about referring to transponder interoperability specifications from other organizations, e.g. the Open ROADM MSA (100G DP-QPSK with Staircase FEC) and upcoming OIF 400ZR (400G DP-16QAM with Hamming SD-FEC + Staircase HD-FEC)?

Daniele, the scope defined in the draft under discussion is “to provide a Yang data model, which can be utilized by an MDSC to collect states of WSON impairment data from the Transport PNCs to enable impairment-aware optical path computation”. One use case that I see is computing all-optical paths between two transponders from vendor A over vendor B (+C+D+…) optical domains.

/Jonas

From: Daniele Ceccarelli <[email-masked]>
Sent: den 19 oktober 2018 21:25
To: Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>; Leeyoung <[email-masked]>; Jonas Mårtensson <[email-masked]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]>
Cc: [email-masked]
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

BR
Daniele

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Beller, Dieter (Nokia - DE/Stuttgart)

Hi Young, all,

Thanks,
Dieter

Best regards,
Young

Hi Young, Jonas, all,

YL>> Agree.

Thanks,
Dieter

/Jonas

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

--

Dieter Beller

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 22 Oct 2018 10:29:59 +0000

That’s a good proposal Jonas, we could go for a third branch called “open source” maybe. That’s something that can’t be considered standard, so I’m fine with both the options:
Option 1:

  *   Standard ITU
  *   Non standard
Option 2:

  *   Standard ITU
  *   Vendor specific
  *   Open source specific.

Regarding the use cases that’s the first and I agree with that , but I understood there is also the willingness from operators to open up to scenarios in which transport from vendor A interworks with transponder from vendor B (over vendor A,B,C,D…)

BR
Daniele

From: Jonas Mårtensson <[email-masked]>
Sent: sabato 20 ottobre 2018 15:33
To: Daniele Ceccarelli <[email-masked]>; Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>; Leeyoung <[email-masked]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]>
Cc: [email-masked]
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi all,

/Jonas

From: Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>
Sent: den 19 oktober 2018 21:25
To: Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]<mailto:[email-masked]>>; Leeyoung <[email-masked]<mailto:[email-masked]>>; Jonas Mårtensson <[email-masked]<mailto:[email-masked]>>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

BR
Daniele

Hi Young, all,

Thanks,
Dieter

Best regards,
Young

Hi Young, Jonas, all,

Thanks,
Dieter

/Jonas

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

--

Dieter Beller

---

From: Jonas Mårtensson <[email-masked]>
Date: Mon, 22 Oct 2018 11:26:19 +0000

Out of curiosity, what or who decides what can be considered a “standard”?

/Jonas

From: Daniele Ceccarelli <[email-masked]>
Sent: den 22 oktober 2018 12:30
To: Jonas Mårtensson <[email-masked]>; Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>; Leeyoung <[email-masked]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]>
Cc: [email-masked]
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

  *   Standard ITU
  *   Non standard
Option 2:

  *   Standard ITU
  *   Vendor specific
  *   Open source specific.

BR
Daniele

From: Jonas Mårtensson <[email-masked]<mailto:[email-masked]>>
Sent: sabato 20 ottobre 2018 15:33
To: Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]<mailto:[email-masked]>>; Leeyoung <[email-masked]<mailto:[email-masked]>>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi all,

/Jonas

BR
Daniele

Hi Young, all,

Thanks,
Dieter

Best regards,
Young

Hi Young, Jonas, all,

Thanks,
Dieter

/Jonas

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

--

Dieter Beller

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 22 Oct 2018 12:52:27 +0000

Good question.
So far (luckily) the distinction between open source and standardization bodies it quite clear. Open source is sometimes a de facto standard but not something that goes through an standardization process well defined for an SDO. Let’s say that an open source is basically…rough consensus and running code 😃

Daniele

From: Jonas Mårtensson <[email-masked]>
Sent: lunedì 22 ottobre 2018 13:26
To: Daniele Ceccarelli <[email-masked]>; Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>; Leeyoung <[email-masked]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]>
Cc: [email-masked]
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

/Jonas

To: Jonas Mårtensson <[email-masked]<mailto:[email-masked]>>; Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]<mailto:[email-masked]>>; Leeyoung <[email-masked]<mailto:[email-masked]>>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]<mailto:[email-masked]>>

  *   Standard ITU
  *   Non standard
Option 2:

  *   Standard ITU
  *   Vendor specific
  *   Open source specific.

BR
Daniele

Hi all,

/Jonas

BR
Daniele

Hi Young, all,

Thanks,
Dieter

Best regards,
Young

Hi Young, Jonas, all,

Thanks,
Dieter

/Jonas

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

--

Dieter Beller

---

From: "Gabriele Maria Galimberti (ggalimbe)" <[email-masked]>
Date: Mon, 22 Oct 2018 12:59:04 +0000

That’s a good question Jonas,

I think we should talk also about Multi Source Agreement (MSA)…
These could be considered as standard if the number of MSA members becomes significant.
I my opinion we should try to define flexible models to be easily used and modified
To support multiple solutions and not to be focused only to a single SDO or SSO.

I’d ask Daniele whether it is possible to have a meeting in Bangkok on this subject and
In general on the draft related to optical impairments in order to co-ordinate the
Effort and all go to the same direction.

Best Regards,

Gabriele

Gabriele Galimberti
Principal Engineer
Cisco Photonics Srl

From: CCAMP <[email-masked]> on behalf of Jonas Mårtensson <[email-masked]>
Date: Monday, 22 October 2018 at 13:26
To: Daniele Ceccarelli <[email-masked]>, Dieter Beller <[email-masked]>, Leeyoung <[email-masked]>, "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

/Jonas

-          Standard ITU
-          Non standard
Option 2:
-          Standard ITU
-          Vendor specific
-          Open source specific.

BR
Daniele

Hi all,

/Jonas

BR
Daniele

Hi Young, all,

Thanks,
Dieter

Best regards,
Young

Hi Young, Jonas, all,

Thanks,
Dieter

/Jonas

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

--

Dieter Beller

---

From: Leeyoung <[email-masked]>
Date: Mon, 22 Oct 2018 14:18:00 +0000

Hi Jonas,

I think Daniele gave his view, which I agree.

From my perspective, what differentiates an SDO  from Open source project is sustainability and backward compatibility. Open source projects may come up with speedy running codes that can be implemented, but they could remain a silo while the SDO like IETF concerns about the codes that are sustainable and backward compatible. If an SDO or an open source project does not care about these two attributes, that will most likely cause many issues for operators.

My two cents,
Young

From: CCAMP [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Monday, October 22, 2018 7:52 AM
To: Jonas Mårtensson <[email-masked]>; Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>; Leeyoung <[email-masked]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]>
Cc: [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Good question.

Daniele

/Jonas

BR
Daniele

Hi all,

/Jonas

BR
Daniele

Hi Young, all,

Thanks,
Dieter

Best regards,
Young

Hi Young, Jonas, all,

Thanks,
Dieter

/Jonas

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

--

Dieter Beller

---

From: Leeyoung <[email-masked]>
Date: Mon, 22 Oct 2018 14:38:45 +0000

Hi Daniele,

Option 1 sounds better to me.  Perhaps rename ‘Standard ITU’ with ‘G.698 application code’ and ‘non-standard’ with ‘vendor-specific’. Open-source specific is a part of vendor-specific category. Have you consulted Deborah on this issue? It would be good to know the direction of the WG on this issue.

Thanks,
Young

From: Jonas Mårtensson [mailto:[email-masked]]
Sent: Monday, October 22, 2018 6:26 AM
To: Daniele Ceccarelli <[email-masked]>; Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>; Leeyoung <[email-masked]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]>
Cc: [email-masked]
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

/Jonas

BR
Daniele

Hi all,

/Jonas

BR
Daniele

Hi Young, all,

Thanks,
Dieter

Best regards,
Young

Hi Young, Jonas, all,

Thanks,
Dieter

/Jonas

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

--

Dieter Beller

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Mon, 22 Oct 2018 14:58:27 +0000

+1

Thanks
Sergio

From: CCAMP <[email-masked]> On Behalf Of Leeyoung
Sent: Monday, October 22, 2018 4:39 PM
To: Jonas Mårtensson <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]>
Cc: [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi Daniele,

Thanks,
Young

/Jonas

  *   Standard ITU
  *   Non standard
Option 2:

  *   Standard ITU
  *   Vendor specific
  *   Open source specific.

BR
Daniele

Hi all,

/Jonas

BR
Daniele

Hi Young, all,

Thanks,
Dieter

Best regards,
Young

Hi Young, Jonas, all,

Thanks,
Dieter

/Jonas

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

--

Dieter Beller

---

From: "Beller, Dieter (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Mon, 22 Oct 2018 15:05:33 +0000

+1

Thanks,
Dieter

On 22.10.2018 16:38, Leeyoung wrote:
Hi Daniele,

Thanks,
Young

To: Daniele Ceccarelli <[email-masked]><mailto:[email-masked]>; Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]><mailto:[email-masked]>; Leeyoung <[email-masked]><mailto:[email-masked]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]><mailto:[email-masked]>

/Jonas

BR
Daniele

Hi all,

/Jonas

BR
Daniele

Hi Young, all,

Thanks,
Dieter

Best regards,
Young

Hi Young, Jonas, all,

Thanks,
Dieter

/Jonas

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 22 Oct 2018 17:11:09 +0200

+1

Cheers, Huub.

On 22/10/2018 16:38, Leeyoung wrote:

Hi Daniele,

Option 1 sounds
better to me.  Perhaps rename ‘Standard ITU’ with ‘G.698
application code’ and ‘non-standard’ with ‘vendor-specific’.
Open-source specific is a part of vendor-specific category.
Have you consulted Deborah on this issue? It would be good
to know the direction of the WG on this issue.

Thanks,

Young

From: Jonas Mårtensson

To: Daniele Ceccarelli
<[email-masked]>; Beller, Dieter
(Nokia - DE/Stuttgart) <[email-masked]>;
Leeyoung <[email-masked]>; Zhenghaomian
(Zhenghaomian, Optical &Microwave Technology
Research Dept) <[email-masked]>

Cc: [email-masked]

Out of
curiosity, what or who decides what can be considered a
“standard”?

/Jonas

To: Jonas Mårtensson <[email-masked]>; Beller, Dieter (Nokia -
DE/Stuttgart) <[email-masked]>; Leeyoung <[email-masked]>; Zhenghaomian
(Zhenghaomian, Optical &Microwave Technology
Research Dept) <[email-masked]>

Cc: [email-masked]

That’s a good proposal Jonas, we could go
for a third branch called “open source” maybe. That’s
something that can’t be considered standard, so I’m fine with
both the options:

Option 1:

-
Standard ITU

-
Non standard

Option 2:

-
Standard ITU

-
Vendor specific

-
Open source specific.

Regarding the use cases that’s the first
and I agree with that , but I understood there is also the
willingness from operators to open up to scenarios in which
transport from vendor A interworks with transponder from
vendor B (over vendor A,B,C,D…)

BR

Daniele

--
================================================================
Always remember that you are unique...just like everyone else...

---

From: Gert Grammel <[email-masked]>
Date: Mon, 22 Oct 2018 15:49:29 +0000

Daniele,

My understanding is:
Application code: defined by ITU (standards body)
Application identifier: can be defined by anyone
                Vendor specific: I recall we used to ask to include the OID in the encoding: http://standards-oui.ieee.org/oui.txt
                Other Groups: afaik no special rules.

That said, are there any particular hurdles to move forward on that basis?

Gert

From: CCAMP <[email-masked]> on behalf of Daniele Ceccarelli <[email-masked]>
Date: Monday, October 22, 2018 at 14:52
To: Jonas Mårtensson <[email-masked]>, Dieter Beller <[email-masked]>, 'Leeyoung' <[email-masked]>, "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <[email-masked]>
Cc: CCAMP <[email-masked]>
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Good question.

Daniele

/Jonas

  *   Standard ITU
  *   Non standard
Option 2:

  *   Standard ITU
  *   Vendor specific
  *   Open source specific.

BR
Daniele

Hi all,

/Jonas

BR
Daniele

Hi Young, all,

Thanks,
Dieter

Best regards,
Young

Hi Young, Jonas, all,

I checked again the YANG tree<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_younglee-2Dietf_actn-2Dwson-2Dflexi-2Dgrid_blob_master_ietf-2Doptical-2Dimpairment-2Dtopology-25402018-2D10-2D08.tree-23L75&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=_cePaENE6XxJCgCskW18h5-Qg8yrTavz-IM5UEwO2QE&s=pCXo1-ZrgJ-ckiUt4KEHKPDnauOAuVWGStwBBJvhFlg&e=> ([email-masked]<mailto:[email-masked]>) and particularly looked at the following augmentation:

these are clearly optical transponder attributes and I am wondering why the following grouping wson-ttp-attributes<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_younglee-2Dietf_actn-2Dwson-2Dflexi-2Dgrid_blob_master_ietf-2Doptical-2Dimpairment-2Dtopology-25402018-2D10-2D09.yang-23L410&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=_cePaENE6XxJCgCskW18h5-Qg8yrTavz-IM5UEwO2QE&s=5nfbWsSIDHLK4ffJxICNbr38n9uBIDlnpXn_WV_k1iw&e=> is not used:

Thanks,
Dieter

/Jonas

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: https://github.com/younglee-ietf/actn-wson-flexi-grid<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_younglee-2Dietf_actn-2Dwson-2Dflexi-2Dgrid&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=_cePaENE6XxJCgCskW18h5-Qg8yrTavz-IM5UEwO2QE&s=F9Gw5AMh9OGrxNXbgnHCrE9vwyRcBH__BCHPKaR12ds&e=>

Please find the latest model per our meeting:
https://github.com/younglee-ietf/actn-wson-flexi-grid/blob/master/ietf-optical-impairment-topology%402018-10-09.yang<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_younglee-2Dietf_actn-2Dwson-2Dflexi-2Dgrid_blob_master_ietf-2Doptical-2Dimpairment-2Dtopology-25402018-2D10-2D09.yang&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=_cePaENE6XxJCgCskW18h5-Qg8yrTavz-IM5UEwO2QE&s=IS_tHSVf6dYunzf57gU8Ibqc7MHBJOKH3Nb1TO5KTNA&e=>

and its tree:
https://github.com/younglee-ietf/actn-wson-flexi-grid/blob/master/ietf-optical-impairment-topology%402018-10-08.tree<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_younglee-2Dietf_actn-2Dwson-2Dflexi-2Dgrid_blob_master_ietf-2Doptical-2Dimpairment-2Dtopology-25402018-2D10-2D08.tree&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=_cePaENE6XxJCgCskW18h5-Qg8yrTavz-IM5UEwO2QE&s=D7noODXyQ597pbbRw8bMMsVozw7E8W7jUhMT0asHf7s&e=>

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

https://datatracker.ietf.org/doc/draft-lee-ccamp-wson-impairment-yang/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dlee-2Dccamp-2Dwson-2Dimpairment-2Dyang_&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=_cePaENE6XxJCgCskW18h5-Qg8yrTavz-IM5UEwO2QE&s=PMlD433tWgUztxyTJ01B2h3awMUzB_6d4qOZA3-FsGI&e=>

https://tools.ietf.org/html/draft-lee-ccamp-wson-impairment-yang-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dlee-2Dccamp-2Dwson-2Dimpairment-2Dyang-2D00&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=_cePaENE6XxJCgCskW18h5-Qg8yrTavz-IM5UEwO2QE&s=7D4RLKzPGO_pSLOeSbUKepIlXRx9qNO8LeQV34ZlTbw&e=>

https://datatracker.ietf.org/doc/html/draft-lee-ccamp-wson-impairment-yang-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dlee-2Dccamp-2Dwson-2Dimpairment-2Dyang-2D00&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=_cePaENE6XxJCgCskW18h5-Qg8yrTavz-IM5UEwO2QE&s=Tk87lxb21yjlgNwn6MCNMC_6QhnnNH_x2tMKMl_0Gro&e=>

ftp://ftp.ietf.org/internet-drafts/<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=_cePaENE6XxJCgCskW18h5-Qg8yrTavz-IM5UEwO2QE&s=9xCw76U8SZPryA0w4rfHt6Yy51CRnNouZj5e6CZmCjo&e=>

https://www.ietf.org/mailman/listinfo/i-d-announce<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_i-2Dd-2Dannounce&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=_cePaENE6XxJCgCskW18h5-Qg8yrTavz-IM5UEwO2QE&s=fcayJSwkso_UI-mx8Ptxqa9vqNz0YZp7e1Wjn5POGVk&e=>

Internet-Draft directories: http://www.ietf.org/shadow.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_shadow.html&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=_cePaENE6XxJCgCskW18h5-Qg8yrTavz-IM5UEwO2QE&s=CWozXxgj5Igm8XqupmFKRq0IaS_-0Jm0hBqCiIyW144&e=>

or ftp://ftp.ietf.org/ietf/1shadow-sites.txt<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_ietf_1shadow-2Dsites.txt&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=_cePaENE6XxJCgCskW18h5-Qg8yrTavz-IM5UEwO2QE&s=LuJCup5tlMLf7rfffKfXSP5qX458v3VmDQ75zdf2eHQ&e=>

CCAMP mailing list

https://www.ietf.org/mailman/listinfo/ccamp<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ccamp&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=_cePaENE6XxJCgCskW18h5-Qg8yrTavz-IM5UEwO2QE&s=WVFmRGUsoThChlAqLPtaxHiKql_NLavBkAWyGDHKhtw&e=>

--

Dieter Beller

---

From: Jonas Mårtensson <[email-masked]>
Date: Mon, 22 Oct 2018 18:38:42 +0000

Hi,

I would prefer Option 2 but rename “Open source specific” with “MSA/IA” (multi-source agreement / implementation agreement).

I don’t see why this should be part of “Vendor specific”, also considering that the organizations I referred to earlier have multiple operator members.

/Jonas

From: Leeyoung <[email-masked]>
Sent: den 22 oktober 2018 16:39
To: Jonas Mårtensson <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]>
Cc: [email-masked]
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi Daniele,

Thanks,
Young

/Jonas

  *   Standard ITU
  *   Non standard
Option 2:

  *   Standard ITU
  *   Vendor specific
  *   Open source specific.

BR
Daniele

Hi all,

/Jonas

BR
Daniele

Hi Young, all,

Thanks,
Dieter

Best regards,
Young

Hi Young, Jonas, all,

Thanks,
Dieter

/Jonas

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

--

Dieter Beller

---

From: Leeyoung <[email-masked]>
Date: Mon, 22 Oct 2018 18:48:19 +0000

Hi Jonas,

My understanding is that MSA/IA still uses vendor optics (component vendor). Is this correct? If so, I would create leaf-list of identifiers that apply to any non-G.698.2 application code. Would this work for you?

Thanks.
Young

From: Jonas Mårtensson [mailto:[email-masked]]
Sent: Monday, October 22, 2018 1:39 PM
To: Leeyoung <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]>
Cc: [email-masked]
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi,

/Jonas

To: Jonas Mårtensson <[email-masked]<mailto:[email-masked]>>; Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]<mailto:[email-masked]>>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]<mailto:[email-masked]>>

Hi Daniele,

Thanks,
Young

/Jonas

BR
Daniele

Hi all,

/Jonas

BR
Daniele

Hi Young, all,

Thanks,
Dieter

Best regards,
Young

Hi Young, Jonas, all,

Thanks,
Dieter

/Jonas

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

--

Dieter Beller

---

From: Jonas Mårtensson <[email-masked]>
Date: Tue, 23 Oct 2018 08:12:42 +0000

Hi,

“My understanding is that MSA/IA still uses vendor optics (component vendor). Is this correct?”

I’m not sure I understand this statement/question. What is the alternative? The optics must come from somewhere, whether it’s a standard interface of not.

/Jonas

From: Leeyoung <[email-masked]>
Sent: den 22 oktober 2018 20:48
To: Jonas Mårtensson <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]>
Cc: [email-masked]
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi Jonas,

Thanks.
Young

To: Leeyoung <[email-masked]<mailto:[email-masked]>>; Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]<mailto:[email-masked]>>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]<mailto:[email-masked]>>

Hi,

/Jonas

Hi Daniele,

Thanks,
Young

/Jonas

  *   Standard ITU
  *   Non standard
Option 2:

  *   Standard ITU
  *   Vendor specific
  *   Open source specific.

BR
Daniele

Hi all,

/Jonas

BR
Daniele

Hi Young, all,

Thanks,
Dieter

Best regards,
Young

Hi Young, Jonas, all,

Thanks,
Dieter

/Jonas

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

--

Dieter Beller

---

From: "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <[email-masked]>
Date: Tue, 23 Oct 2018 08:23:50 +0000

Hi,

I think we are converging with categorizing into “standardized” and “non-standardized”, we just need two terms on these.

For “standardized”, I would say “ITU-T G.698.2 Application code” is very explicit and will not have any misleading issue; it seems we don’t have other opinions neither.
For “non-standardized”, we have terms “vendor-specific” VS. “MSA/IA”. Personally I am preferring “vendor-specific”, which is implying it may be agreed by one or multiple vendors but is not standardized. I would not prefer using “MSA/IA”, as the standard (G.698.2 application code) is also a “MSA/IA”, which will be slightly misleading.

My 2 cents,
Haomian

发件人: Jonas Mårtensson [mailto:[email-masked]]
发送时间: 2018年10月23日 16:13
收件人: Leeyoung <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]>
抄送: [email-masked]
主题: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi,

/Jonas

Hi Jonas,

Thanks.
Young

Hi,

/Jonas

Hi Daniele,

Thanks,
Young

/Jonas

BR
Daniele

Hi all,

/Jonas

BR
Daniele

Hi Young, all,

Thanks,
Dieter

Best regards,
Young

Hi Young, Jonas, all,

Thanks,
Dieter

/Jonas

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

--

Dieter Beller

---

From: Gert Grammel <[email-masked]>
Date: Tue, 23 Oct 2018 12:20:42 +0000

Let’s be clear what we like to solve here.
Application identifiers (-codes) are abbreviations of transceiver operations. Transceivers that can be programmed necessarily need to update/switch application identifiers.

Assuming AIs are required, the following need to be considered:

  *   A standard has a particular application code and non-standard codes shall not duplicate those.
  *   Similarly the group may want to define some identifier that is associated to an MSA. If so, vendor proprietary codes shall not overlap
  *   Given that we have several vendors, their AI shall not overlap with each other and not with the MSA.

Put together:

  1.  What should be encoded in MSA identifiers and how?
  2.  How to ensure no overlap between MSA and proprietary AI?
  3.  How to deal with programmable modules which inevitably need a set of application identifiers i.e. for a QPSK modulation and a QAM8 modulation. As per current definition, changing the modulation means changing the application identifier.

Gert

From: CCAMP <[email-masked]> on behalf of Jonas Mårtensson <[email-masked]>
Date: Tuesday, October 23, 2018 at 10:13
To: 'Leeyoung' <[email-masked]>, Daniele Ceccarelli <[email-masked]>, Dieter Beller <[email-masked]>, "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <[email-masked]>
Cc: CCAMP <[email-masked]>
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi,

/Jonas

Hi Jonas,

Thanks.
Young

Hi,

/Jonas

Hi Daniele,

Thanks,
Young

/Jonas

  *   Standard ITU
  *   Non standard
Option 2:

  *   Standard ITU
  *   Vendor specific
  *   Open source specific.

BR
Daniele

Hi all,

/Jonas

BR
Daniele

Hi Young, all,

Thanks,
Dieter

Best regards,
Young

Hi Young, Jonas, all,

I checked again the YANG tree<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_younglee-2Dietf_actn-2Dwson-2Dflexi-2Dgrid_blob_master_ietf-2Doptical-2Dimpairment-2Dtopology-25402018-2D10-2D08.tree-23L75&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=N1-VoqsT2ZVoShtFU95IpLTTSAbCmq33h8DoIYN8u9o&s=3u3t-wJNAHxDXwJIDD_ql94z4pa9HN_Q2ykLGKRWmfY&e=> ([email-masked]<mailto:[email-masked]>) and particularly looked at the following augmentation:

these are clearly optical transponder attributes and I am wondering why the following grouping wson-ttp-attributes<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_younglee-2Dietf_actn-2Dwson-2Dflexi-2Dgrid_blob_master_ietf-2Doptical-2Dimpairment-2Dtopology-25402018-2D10-2D09.yang-23L410&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=N1-VoqsT2ZVoShtFU95IpLTTSAbCmq33h8DoIYN8u9o&s=Cln5nMq5UdYgDsqyr3M7pOKDfrx3LVg7Y1Vsa-PfOHs&e=> is not used:

Thanks,
Dieter

/Jonas

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: https://github.com/younglee-ietf/actn-wson-flexi-grid<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_younglee-2Dietf_actn-2Dwson-2Dflexi-2Dgrid&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=N1-VoqsT2ZVoShtFU95IpLTTSAbCmq33h8DoIYN8u9o&s=YbUbihOolc601cVxnbo3x4GP_QWoziMp9Zt0LNGrCxM&e=>

Please find the latest model per our meeting:
https://github.com/younglee-ietf/actn-wson-flexi-grid/blob/master/ietf-optical-impairment-topology%402018-10-09.yang<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_younglee-2Dietf_actn-2Dwson-2Dflexi-2Dgrid_blob_master_ietf-2Doptical-2Dimpairment-2Dtopology-25402018-2D10-2D09.yang&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=N1-VoqsT2ZVoShtFU95IpLTTSAbCmq33h8DoIYN8u9o&s=5a-4QbS5j8aljLvsQbMIMpBnaeHKwm9c1RtFe7OR7fw&e=>

and its tree:
https://github.com/younglee-ietf/actn-wson-flexi-grid/blob/master/ietf-optical-impairment-topology%402018-10-08.tree<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_younglee-2Dietf_actn-2Dwson-2Dflexi-2Dgrid_blob_master_ietf-2Doptical-2Dimpairment-2Dtopology-25402018-2D10-2D08.tree&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=N1-VoqsT2ZVoShtFU95IpLTTSAbCmq33h8DoIYN8u9o&s=mYI798eiw_ZUtwby2-zNvppuzEbwhUJ_80YO5FdDV_I&e=>

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

https://datatracker.ietf.org/doc/draft-lee-ccamp-wson-impairment-yang/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dlee-2Dccamp-2Dwson-2Dimpairment-2Dyang_&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=N1-VoqsT2ZVoShtFU95IpLTTSAbCmq33h8DoIYN8u9o&s=e4JC8pQEzge8fyEMXbfIVLSeJeQ1kSjCQiichWd-IAc&e=>

https://tools.ietf.org/html/draft-lee-ccamp-wson-impairment-yang-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dlee-2Dccamp-2Dwson-2Dimpairment-2Dyang-2D00&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=N1-VoqsT2ZVoShtFU95IpLTTSAbCmq33h8DoIYN8u9o&s=yJ18-xjPOdcjnEKuT6TTcbBT-VRw_kMDx2sfqV0OWvA&e=>

https://datatracker.ietf.org/doc/html/draft-lee-ccamp-wson-impairment-yang-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dlee-2Dccamp-2Dwson-2Dimpairment-2Dyang-2D00&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=N1-VoqsT2ZVoShtFU95IpLTTSAbCmq33h8DoIYN8u9o&s=lqNWvKtB6NVgY6ZkIS8zO_MAMznyRmzTCC2YqlnP-E0&e=>

ftp://ftp.ietf.org/internet-drafts/<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=N1-VoqsT2ZVoShtFU95IpLTTSAbCmq33h8DoIYN8u9o&s=mzeWTVUrT_OjkgRVDH_gJ3B3L47g6TkBCw-p86KOujw&e=>

https://www.ietf.org/mailman/listinfo/i-d-announce<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_i-2Dd-2Dannounce&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=N1-VoqsT2ZVoShtFU95IpLTTSAbCmq33h8DoIYN8u9o&s=3HPHcR0rG7xgFNqSGO_hGbNr7eG-NvnGEzzF9n22h8M&e=>

Internet-Draft directories: http://www.ietf.org/shadow.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_shadow.html&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=N1-VoqsT2ZVoShtFU95IpLTTSAbCmq33h8DoIYN8u9o&s=1_dYEmA6MxW1LN96lXyzNNG_qY17cc9k4aRofcpyctQ&e=>

or ftp://ftp.ietf.org/ietf/1shadow-sites.txt<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_ietf_1shadow-2Dsites.txt&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=N1-VoqsT2ZVoShtFU95IpLTTSAbCmq33h8DoIYN8u9o&s=q90TxiVhkiXjWO9bu-m83gNovQ-WaEAGcYlZd9xmva4&e=>

CCAMP mailing list

https://www.ietf.org/mailman/listinfo/ccamp<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ccamp&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Sf-T94Aod4TTEURQzTXYYw-Q-H8PyeOsweqqcNyVIcU&m=N1-VoqsT2ZVoShtFU95IpLTTSAbCmq33h8DoIYN8u9o&s=C4gCyKYRR9JjTO7mhXa38vodh-hRPNxIoyv0yDYU7To&e=>

--

Dieter Beller

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 23 Oct 2018 12:28:39 +0000

Hi,

i was basically identifying option 1 in which we keep on using “standard vs non standard” code points (i.e. ITU vs non ITU) and option 2 which allows further defining the non standard “group” into e.g. vendor specific, MSA, IA, open source etc.

If we go on with option 1 I would keep on using the terminology defined in RFC7581 (i.e. ITU application codes vs non ITU code points). If on the other hands you prefer to further specify categories for the non ITU code points, we can discuss about it.

The WG seems to be more or less equally split between the two options. I don’t have a strong opinion, both of them work for me. Probably further splitting the non standard ones allows for a cleaner allocation.

BR
Daniele

From: Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]>
Sent: martedì 23 ottobre 2018 10:24
To: Jonas Mårtensson <[email-masked]>; Leeyoung <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>
Cc: [email-masked]
Subject: 答复: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi,

My 2 cents,
Haomian

发件人: Jonas Mårtensson [mailto:[email-masked]]
发送时间: 2018年10月23日 16:13
收件人: Leeyoung <[email-masked]<mailto:[email-masked]>>; Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]<mailto:[email-masked]>>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]<mailto:[email-masked]>>
抄送: [email-masked]<mailto:[email-masked]>
主题: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi,

/Jonas

Hi Jonas,

Thanks.
Young

Hi,

/Jonas

Hi Daniele,

Thanks,
Young

/Jonas

  *   Standard ITU
  *   Non standard
Option 2:

  *   Standard ITU
  *   Vendor specific
  *   Open source specific.

BR
Daniele

Hi all,

/Jonas

BR
Daniele

Hi Young, all,

Thanks,
Dieter

Best regards,
Young

Hi Young, Jonas, all,

Thanks,
Dieter

/Jonas

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

--

Dieter Beller

---

From: "Beller, Dieter (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Tue, 23 Oct 2018 20:03:16 +0000

Hi Daniele, all,

please find my comments inline below ([DB>] ).

Thanks,
Dieter

On 23.10.2018 14:28, Daniele Ceccarelli wrote:
Hi,

[DB>] absolutely! The supported non-standard code points can be put under a vendor-ID | MSA-ID | IA-ID, Open-Source-ID, etc. If these IDs are scoping the code points, each
[DB>] organization can even assign its code points. We only have to define the type of the code point attribute that is common (e.g. string or uint) in the YANG model. This would
[DB>] be a quite elegant approach solving the issue.

[DB>] see previous comment

[DB>] agree

BR
Daniele

From: Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]><mailto:[email-masked]>
Sent: martedì 23 ottobre 2018 10:24
To: Jonas Mårtensson <[email-masked]><mailto:[email-masked]>; Leeyoung <[email-masked]><mailto:[email-masked]>; Daniele Ceccarelli <[email-masked]><mailto:[email-masked]>; Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: 答复: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi,

My 2 cents,
Haomian

Hi,

/Jonas

Hi Jonas,

Thanks.
Young

Hi,

/Jonas

Hi Daniele,

Thanks,
Young

/Jonas

  *   Standard ITU
  *   Non standard
Option 2:

  *   Standard ITU
  *   Vendor specific
  *   Open source specific.

BR
Daniele

Hi all,

/Jonas

BR
Daniele

Hi Young, all,

Thanks,
Dieter

Best regards,
Young

Hi Young, Jonas, all,

Thanks,
Dieter

/Jonas

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 24 Oct 2018 02:56:35 +0000

Hi Gabriele and all,

Good point.
I agree with Gabriele and prefer the integers.

Thanks

Fatai

发件人: CCAMP [mailto:[email-masked]] 代表 Gabriele Maria Galimberti (ggalimbe)
发送时间: 2018年10月20日 0:52
收件人: Leeyoung <[email-masked]>; Dieter Beller <[email-masked]>; Jonas Mårtensson <[email-masked]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]>
抄送: [email-masked]
主题: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi Young,

    +--:(optical-imp-topo)

       +--rw (grid-type)?

       |  +--:(flexi-grid)

       |  +--:(dwdm)

       |  +--:(cwdm)

Best Regards,

Gabriele

Gabriele Galimberti
Principal Engineer
Cisco Photonics Srl

From: CCAMP <[email-masked]<mailto:[email-masked]>> on behalf of Leeyoung <[email-masked]<mailto:[email-masked]>>
Date: Monday, 15 October 2018 at 19:02
To: Dieter Beller <[email-masked]<mailto:[email-masked]>>, Jonas Mårtensson <[email-masked]<mailto:[email-masked]>>, "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 24 Oct 2018 03:18:28 +0000

Hi Gert,

Very interesting questions and I fully agree on your observation

For the non-standard case, I would tend to treat MSA/IA as a part of vendor-specific category because an MSA (a group of companies) may define some AIs that could be overlapped with the ones defined by other MSAs (and/or other vendors that are not the members of the MSA).

Thanks

Fatai

发件人: CCAMP [mailto:[email-masked]] 代表 Gert Grammel
发送时间: 2018年10月23日 20:21
收件人: Jonas Mårtensson <[email-masked]>; Leeyoung <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]>
抄送: [email-masked]
主题: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Put together:
1)      What should be encoded in MSA identifiers and how?
2)      How to ensure no overlap between MSA and proprietary AI?
3)      How to deal with programmable modules which inevitably need a set of application identifiers i.e. for a QPSK modulation and a QAM8 modulation. As per current definition, changing the modulation means changing the application identifier.

Gert

From: CCAMP <[email-masked]<mailto:[email-masked]>> on behalf of Jonas Mårtensson <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 23, 2018 at 10:13
To: 'Leeyoung' <[email-masked]<mailto:[email-masked]>>, Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>, Dieter Beller <[email-masked]<mailto:[email-masked]>>, "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <[email-masked]<mailto:[email-masked]>>
Cc: CCAMP <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

Hi,

/Jonas

Hi Jonas,

Thanks.
Young

Hi,

/Jonas

Hi Daniele,

Thanks,
Young

/Jonas

BR
Daniele

Hi all,

/Jonas

BR
Daniele

Hi Young, all,

Thanks,
Dieter

Best regards,
Young

Hi Young, Jonas, all,

Thanks,
Dieter

/Jonas

Hi Dieter,

and its tree:

Thanks.
Young

Hi Young, all,

Thanks,
Dieter

Thanks.
Young

Hi Young and Haomian,

/Jonas

        Authors         : Young Lee

                          Haomian Zheng

  Pages           : 18

  Date            : 2018-08-31

Abstract:

CCAMP mailing list

--

Dieter Beller

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 29 Oct 2018 15:38:52 +0100

All,

To me "vendor-specific" is synonymous to "proprietary"

and not agreed between multiple vendors.

IMHO "vendors-specific" or "vendors-specified" would be better

if "non-standard" is not used.

Best regards, Huub.

--------

On 23/10/2018 14:28, Daniele Ceccarelli wrote:

Hi,

i was basically identifying option 1 in which
we keep on using “standard vs non standard” code points
(i.e. ITU vs non ITU) and option 2 which allows further
defining the non standard “group” into e.g. vendor specific,
MSA, IA, open source etc.

If we go on with option 1 I would keep on using
the terminology defined in RFC7581 (i.e. ITU application
codes vs non ITU code points). If on the other hands you
prefer to further specify categories for the non ITU code
points, we can discuss about it.

The WG seems to be more or less equally split
between the two options. I don’t have a strong opinion, both
of them work for me. Probably further splitting the non
standard ones allows for a cleaner allocation.

BR

Daniele

From: Zhenghaomian (Zhenghaomian, Optical
&Microwave Technology Research Dept)
<[email-masked]>

To: Jonas Mårtensson
<[email-masked]>; Leeyoung
<[email-masked]>; Daniele Ceccarelli
<[email-masked]>; Beller,
Dieter (Nokia - DE/Stuttgart)
<[email-masked]>

Cc: [email-masked]

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

Hi,

I think we are converging with categorizing
into “standardized” and “non-standardized”, we just need
two terms on these.

For “standardized”, I would say “ITU-T
G.698.2 Application code” is very explicit and will not
have any misleading issue; it seems we don’t have other
opinions neither.

For “non-standardized”, we have terms
“vendor-specific” VS. “MSA/IA”. Personally I am preferring
“vendor-specific”, which is implying it may be agreed by
one or multiple vendors but is not standardized. I would
not prefer using “MSA/IA”, as the standard (G.698.2
application code) is also a “MSA/IA”, which will be
slightly misleading.

My 2 cents,

Haomian

发送时间: 2018年10月23日 16:13

收件人: Leeyoung <[email-masked]>;
Daniele Ceccarelli <[email-masked]>;
Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>;
Zhenghaomian (Zhenghaomian, Optical &Microwave
Technology Research Dept) <[email-masked]>

抄送:
[email-masked]

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

Hi,

“My understanding is that MSA/IA still uses
vendor optics (component vendor). Is this correct?”

I’m not sure I understand this
statement/question. What is the alternative? The optics
must come from somewhere, whether it’s a standard
interface of not.

/Jonas

From:
Leeyoung <[email-masked]>

To: Jonas Mårtensson <[email-masked]>;
Daniele Ceccarelli <[email-masked]>;
Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>;
Zhenghaomian (Zhenghaomian, Optical &Microwave
Technology Research Dept) <[email-masked]>

Cc: [email-masked]

Hi Jonas,

My understanding is that MSA/IA still uses
vendor optics (component vendor). Is this correct? If so,
I would create leaf-list of identifiers that apply to any
non-G.698.2 application code. Would this work for you?

Thanks.

Young

From: Jonas
Mårtensson [mailto:[email-masked]]

To: Leeyoung <[email-masked]>;
Daniele Ceccarelli <[email-masked]>;
Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>;
Zhenghaomian (Zhenghaomian, Optical &Microwave
Technology Research Dept) <[email-masked]>

Cc: [email-masked]

Hi,

I would prefer Option 2 but rename “Open
source specific” with “MSA/IA” (multi-source agreement /
implementation agreement).

I don’t see why this should be part of
“Vendor specific”, also considering that the organizations
I referred to earlier have multiple operator members.

/Jonas

From:
Leeyoung <[email-masked]>

To: Jonas Mårtensson <[email-masked]>;
Daniele Ceccarelli <[email-masked]>;
Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>;
Zhenghaomian (Zhenghaomian, Optical &Microwave
Technology Research Dept) <[email-masked]>

Cc: [email-masked]

Hi Daniele,

Option 1 sounds better to me.  Perhaps rename
‘Standard ITU’ with ‘G.698 application code’ and
‘non-standard’ with ‘vendor-specific’. Open-source
specific is a part of vendor-specific category. Have you
consulted Deborah on this issue? It would be good to know
the direction of the WG on this issue.

Thanks,

Young

From: Jonas
Mårtensson [mailto:[email-masked]]

To: Daniele Ceccarelli <[email-masked]>;
Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>;
Leeyoung <[email-masked]>;
Zhenghaomian (Zhenghaomian, Optical &Microwave
Technology Research Dept) <[email-masked]>

Cc: [email-masked]

Out of curiosity, what or who decides what
can be considered a “standard”?

/Jonas

From:
Daniele Ceccarelli <[email-masked]>

To: Jonas Mårtensson <[email-masked]>;
Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>;
Leeyoung <[email-masked]>;
Zhenghaomian (Zhenghaomian, Optical &Microwave
Technology Research Dept) <[email-masked]>

Cc: [email-masked]

That’s a good proposal Jonas, we could go for
a third branch called “open source” maybe. That’s
something that can’t be considered standard, so I’m fine
with both the options:

Option 1:

Standard ITU

Non standard

Option 2:

Standard ITU

Vendor specific

Open source specific.

Regarding the use cases that’s the first and
I agree with that , but I understood there is also the
willingness from operators to open up to scenarios in
which transport from vendor A interworks with transponder
from vendor B (over vendor A,B,C,D…)

BR

Daniele

From:
Jonas Mårtensson <[email-masked]>

To: Daniele Ceccarelli <[email-masked]>;
Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>;
Leeyoung <[email-masked]>;
Zhenghaomian (Zhenghaomian, Optical &Microwave
Technology Research Dept) <[email-masked]>

Cc: [email-masked]

Hi all,

In
addition to G.698.2 and ITU-T, what about referring to
transponder interoperability specifications from other
organizations, e.g. the Open ROADM MSA (100G DP-QPSK
with Staircase FEC) and upcoming OIF 400ZR (400G
DP-16QAM with Hamming SD-FEC + Staircase HD-FEC)?

Daniele,
the scope defined in the draft under discussion is “to
provide a Yang data model, which can be utilized by an
MDSC to collect states of WSON impairment data from the
Transport PNCs to enable impairment-aware optical path
computation”. One use case that I see is computing
all-optical paths between two transponders from vendor A
over vendor B (+C+D+…) optical domains.

/Jonas

From:
Daniele Ceccarelli <[email-masked]>

To: Beller, Dieter (Nokia - DE/Stuttgart)
<[email-masked]>;
Leeyoung <[email-masked]>;
Jonas Mårtensson <[email-masked]>;
Zhenghaomian (Zhenghaomian, Optical &Microwave
Technology Research Dept) <[email-masked]>

Cc: [email-masked]

That
should be the approach and I’m happy to see quite some
alignment on that.

As Gert
pointed out RFC7581 “provides a switch that enables
non-standard implementations, but does not define them”.
That is fine, it’s the switch we are talking about. That
allows us continue working standard application codes as
well as defining new non it code points.

--- end
of chair statement and start of contributor mode

I wonder
whether here we are speaking about vendor specific code
points or rather operator specific code points.

if we speak about vendor specific code points this means
that we most likely end up with Vendor 1 supporting code
points A,B,C and vendor 2 supporting D,E,F.

IMHO it
is pointless to have vendor specific code points if the
final scope is having equipment from vendor A interwork
with equipment form vendor B. Why a standard way of
configuring proprietary parameters is needed at all?

What
OTOH would be useful is a set of agreed code points that
allow an operator to have two equipments from different
vendors interwork in a non ITU-standard way.

BR

Daniele

From:
CCAMP <[email-masked]>
On Behalf Of Beller, Dieter (Nokia -
DE/Stuttgart)

To: Leeyoung <[email-masked]>;
Jonas Mårtensson <[email-masked]>;
Zhenghaomian (Zhenghaomian, Optical &Microwave
Technology Research Dept) <[email-masked]>

Cc: [email-masked]

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

Hi
Young, all,

I think that we need both, the G.698.2 application
codes, which are standardized (standardized
operational modes), and vendor-specific operational
modes.

Operational modes represent optical transponder
settings which have to be the same for the two optical
transponders terminating a photonic tunnel or segment

The vendor-ID attribute should be of type string. We
can further discuss this in Bangkok.

Thanks,

Dieter