Subject: Re: [CCAMP] 转发: New Version Notification for draft-zheng-ccamp-gmpls-g709v5-fwk-00.txt

From: <[email-masked]>
Date: Mon, 6 Mar 2017 22:55:42 +0800 (CST)

Hi Gert, Haomian,

Sorry for chipping in.

I would like to inform you that another g709v5 draft has already been submitted at Feb 7, 2017, almost one month ago. And the link is:  https://tools.ietf.org/html/draft-zih-ccamp-otn-b100g-fwk-00 

In this draft, I think the split of OTUCn signal and the other issue described in this mail are covered already. Please take a look at it.

Thanks

Qilei

原始邮件

发件人： ＜[email-masked]＞
收件人： ＜[email-masked]＞ ＜[email-masked]＞
日 期 ：2017年03月06日 19:55
主 题 ：Re: [CCAMP] 转发: New Version Notification for draft-zheng-ccamp-gmpls-g709v5-fwk-00.txt

Haomian,

Thank you for considering a framework document about ODU4 and ODUCn and beyond 100G structures. This draft is certainly a good starting point.  That said, as G.709v5 includes the digital (ODUk/ODUCn layer) and optical layer considerations and my preference would be to see both tackled in one framework document, but obviously that is a choice of the authors. 
Few quick comments related to the current draft:
- What kind of confused me was the statement "This document focuses on only the control of the ODUk/ODUCn layer." In combination with " The optical layer control will be addressed in a separate document." It appears to me that with this split the digital part of OTUCn is not covered in either document. As the digital structure of an OTUC1 is not the same as an OTU4, it would make sense to either consider it in this framework or spell out that it is considered in a different one.
- In G.709v5 an OTU can be mapped onto OTL3.4 or OTL4.4. those OTL are digital structures but may be considered in the "optical layer framework" (see above). If that was the intention it would be great to spell it out.
- While in the past a client signal mapping followed client-＞OPU-＞ODU-＞OTU mappings, the new scheme suggests a mapping like client-＞OPU-＞ODTU-＞ODTUG-＞OPUCn-＞ODUCn-＞OTUCn (Figure 7-1 – OTN multiplexing and mapping structures). Shouldn't that be captured in Figure-1? 
- G.709v5 defines SOTU (single OTU) and MOTU (multiple OTU) interfaces. SOTU looks like what we know from OTUk interfaces using a single wavelength carrying a single OTU. A MOTU interface looks like e.g. a 400G interface stripped into 4 wavelength@100G, each of them considered an OTU. So here a ODUC4 may end up stripped into 4 OTUC1. As this has impact on routing and signalling decisions for wavelength, it would be great to cover the concept.

Best

Gert

On 2017-03-17, 11:05, "CCAMP on behalf of Zhenghaomian" ＜[email-masked] on behalf of [email-masked]＞ wrote:

    Dear CCAMPers, 
    
    Please find a new draft uploaded as follow. In this work we target on summarize the architecture and requirement comes from latest OTN data plane recommendation, [ITU-T G.709v5]. We summarized some previous discussions in the working group, together with corresponding gmpls implications described in this work. 
    
    You are more than welcomed to review the document and provide comments, thank you. 
    
    Best wishes,
    Haomian
    
    -----邮件原件-----
    发件人: [email-masked] [mailto:[email-masked]] 
    发送时间: 2017年3月6日 18:00
    收件人: Daniele Ceccarelli Zhenghaomian Daniel King Zafar Ali Sergio Belotti Zhenghaomian Italo Busi
    主题: New Version Notification for draft-zheng-ccamp-gmpls-g709v5-fwk-00.txt

    A new version of I-D, draft-zheng-ccamp-gmpls-g709v5-fwk-00.txt
    has been successfully submitted by Haomian Zheng and posted to the IETF repository.
    
    Name:        draft-zheng-ccamp-gmpls-g709v5-fwk
    Revision:    00
    Title:        Framework for GMPLS Control of Optical Transport Networks in G.709 Edition 5
    Document date:    2017-03-06
    Group:        Individual Submission
    Pages:        11
    URL:            https://www.ietf.org/internet-drafts/draft-zheng-ccamp-gmpls-g709v5-fwk-00.txt
    Status:         https://datatracker.ietf.org/doc/draft-zheng-ccamp-gmpls-g709v5-fwk/
    Htmlized:       https://tools.ietf.org/html/draft-zheng-ccamp-gmpls-g709v5-fwk-00

    Abstract:
       The International Telecommunication Union Telecommunication
       Standardization Sector (ITU-T) has extended its Recommendations
       Optical Transport Networks (OTNs, G.709) to edition 5 to support new
       features, including beyond 100 Gbps (B100G) OTN containers.
    
       This document summarizes the architecture and requirements, and
       provides corresponding control plane considerations to guide
       protocol extensions development in support of OTNv5 control
       mechanisms.

    
    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.
    
    The IETF Secretariat
    
    _______________________________________________
    CCAMP mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/ccamp

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

---

From: Gert Grammel <[email-masked]>
Date: Tue, 7 Mar 2017 12:21:52 +0000

Qilei,

Thanks for https://tools.ietf.org/html/draft-zih-ccamp-otn-b100g-fwk-00. This framework looks indeed more complete and accurate from a data-plane perspective than the one earlier discussed. In particular, the OTU structure down to Wavelength/PHY level which was missing from draft-zheng-ccamp-gmpls-g709v5-fwk-00.txt has been captured (Figure-1). You also capture the OTUCn-M signal which has not been discussed on this list so far and needs consideration.

Few minor points:

·         3.3 "The ODUCn is meant to be used as a high-order signal only": "Figure 7-1 – OTN multiplexing and mapping structures" shows the possibility to map a proprietary signal directly into OPUCn/ODUCn.  This basically allows to use a different mapping than the one suggested. I wouldn't mind if no one would use that option, but at least state that there is one.

·         3.6c: What does it mean "Drop support for ODU Virtual Concatenation."? Is this an assumption taken by the authors of the framework or is this found in G.709v5? How is backwards compatibility supposed to work? It would at least warrant a statement in the Requirements section.

·         5.2b: You note this is under discussion. Would be great to let the WG know about the arguments. I.e. I would find it strange not to allocate slot resources for ODU clients, but perhaps the discussion is about other details.

·         There is no mentioning of protection mechanisms in the current Framework. At least backwards compatibility to existing mechanisms should be required.

Best

Gert

From: "[email-masked]" <[email-masked]>
Date: Monday 06 March 2017 at 15:55
To: Gert Grammel <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: CCAMP <[email-masked]>
Subject: Re: [CCAMP] 转发: New Version Notification for draft-zheng-ccamp-gmpls-g709v5-fwk-00.txt

Hi Gert, Haomian,

Sorry for chipping in.

Thanks

Qilei

原始邮件
发件人： ＜[email-masked]＞;
收件人： ＜[email-masked]＞; ＜[email-masked]＞;
日 期 ：2017年03月06日 19:55
主 题 ：Re: [CCAMP] 转发: New Version Notification for draft-zheng-ccamp-gmpls-g709v5-fwk-00.txt

Haomian,

Best

Gert

    Dear CCAMPers,

    Best wishes,
    Haomian

    -----邮件原件-----
    发件人: [email-masked] [mailto:[email-masked]]
    发送时间: 2017年3月6日 18:00
    收件人: Daniele Ceccarelli; Zhenghaomian; Daniel King; Zafar Ali; Sergio Belotti; Zhenghaomian; Italo Busi
    主题: New Version Notification for draft-zheng-ccamp-gmpls-g709v5-fwk-00.txt

    Abstract:

    The IETF Secretariat

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 7 Mar 2017 14:26:11 +0100

Hello Gert,

Thank you for reviewing our draft.

Please see my respinse in-line [Huub]

Thanks
for
https://tools.ietf.org/html/draft-zih-ccamp-otn-b100g-fwk-00.
This framework looks indeed more complete and accurate from a
data-plane perspective than the one earlier discussed. In
particular, the OTU structure down to Wavelength/PHY level
which was missing from
draft-zheng-ccamp-gmpls-g709v5-fwk-00.txt has been captured
(Figure-1). You also capture the OTUCn-M signal which has not
been discussed on this list so far and needs consideration.

Few
minor points:

·
3.3
"The ODUCn is meant to be used as a high-order signal only":
"Figure 7-1 – OTN multiplexing and mapping structures" shows
the possibility to map a proprietary signal directly into
OPUCn/ODUCn.  This basically allows to use a different
mapping than the one suggested. I wouldn't mind if no one
would use that option, but at least state that there is one.

[Huub] Higher-order and lower-order refer to the layering, not to
the functional mapping.

It is possible/allowed to map a non-OTN signal directly into a
higher-order OTN signal.

·
3.6c:
What does it mean "Drop support for ODU Virtual
Concatenation."? Is this an assumption taken by the authors
of the framework or is this found in G.709v5? How is
backwards compatibility supposed to work? It would at least
warrant a statement in the Requirements section.

[Huub] it is in G.709v5, in the summary: "Edition 5.0 furthermore
deleted the OPUk concatenation specifications"

Also clause 18 is intentionally empty.

Backwards compatibility is not an issue because AFAIK VCAT was never
implemented in OTN because it

would need an enormous amount of memory to compensate the
differential delay.

That is why I helped to develop ODUflex.

·
5.2b:
You note this is under discussion. Would be great to let the
WG know about the arguments. I.e. I would find it strange
not to allocate slot resources for ODU clients, but perhaps
the discussion is about other details.

·
There
is no mentioning of protection mechanisms in the current
Framework. At least backwards compatibility to existing
mechanisms should be required.

[Huub] We can work on this.

Cheers, Huub.

From:
"[email-masked]"
<[email-masked]>

To: Gert Grammel <[email-masked]>,
"[email-masked]" <[email-masked]>

Subject: Re: [CCAMP] 转发: New Version
Notification for draft-zheng-ccamp-gmpls-g709v5-fwk-00.txt

Hi Gert, Haomian,

Sorry for chipping in.

I would like to inform you that another g709v5 draft has
already been submitted at Feb 7, 2017, almost one month ago.
And the link is:  https://tools.ietf.org/html/draft-zih-ccamp-otn-b100g-fwk-00

In this draft, I think the split of OTUCn signal and the
other issue described in this mail are covered already.
Please take a look at it.

Thanks

Qilei

原始邮件

发件人：
＜[email-masked]＞;

收件人：
＜[email-masked]＞;
＜[email-masked]＞;

日
期

：2017年03月06日
19:55

主
题

：Re:
[CCAMP]
转发:
New Version Notification for
draft-zheng-ccamp-gmpls-g709v5-fwk-00.txt

Haomian,

Best

Gert

Dear CCAMPers,

Best wishes,

Haomian

-----邮件原件-----

发送时间: 2017年3月6日 18:00

Revision:    00

Pages:        11

Abstract:

mechanisms.

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

---

From: Gert Grammel <[email-masked]>
Date: Tue, 7 Mar 2017 14:24:16 +0000

Huub,

Thank you for the additional details. RFC7139 introduced VCAT based on the 2012 version. Dropping the virtual concatenation is probably something to discuss with the Chairs at the next meeting. This shouldn't impact this framework though.

Thanks

Gert

From: CCAMP <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
Date: Tuesday 07 March 2017 at 14:26
To: CCAMP <[email-masked]>
Subject: Re: [CCAMP] 转发: New Version Notification for draft-zheng-ccamp-gmpls-g709v5-fwk-00.txt

Hello Gert,

Few minor points:

[Huub] Higher-order and lower-order refer to the layering, not to the functional mapping.
It is possible/allowed to map a non-OTN signal directly into a higher-order OTN signal.

[Huub] it is in G.709v5, in the summary: "Edition 5.0 furthermore deleted the OPUk concatenation specifications"
Also clause 18 is intentionally empty.
Backwards compatibility is not an issue because AFAIK VCAT was never implemented in OTN because it
would need an enormous amount of memory to compensate the differential delay.
That is why I helped to develop ODUflex.

Cheers, Huub.

From: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Date: Monday 06 March 2017 at 15:55
To: Gert Grammel <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Cc: CCAMP <[email-masked]><mailto:[email-masked]>
Subject: Re: [CCAMP] 转发: New Version Notification for draft-zheng-ccamp-gmpls-g709v5-fwk-00.txt

Hi Gert, Haomian,

Sorry for chipping in.

Thanks

Qilei
原始邮件
发件人： ＜[email-masked]<mailto:[email-masked]>＞;
收件人： ＜[email-masked]<mailto:[email-masked]>＞; ＜[email-masked]<mailto:[email-masked]>＞;
日 期 ：2017年03月06日 19:55
主 题 ：Re: [CCAMP] 转发: New Version Notification for draft-zheng-ccamp-gmpls-g709v5-fwk-00.txt

Haomian,

Best

Gert

On 2017-03-17, 11:05, "CCAMP on behalf of Zhenghaomian" ＜[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>＞ wrote:

    Dear CCAMPers,

    Best wishes,
    Haomian

    -----邮件原件-----
    发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
    发送时间: 2017年3月6日 18:00
    收件人: Daniele Ceccarelli; Zhenghaomian; Daniel King; Zafar Ali; Sergio Belotti; Zhenghaomian; Italo Busi
    主题: New Version Notification for draft-zheng-ccamp-gmpls-g709v5-fwk-00.txt

    Abstract:

--