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

[Huub van Helvoort <[e-mail]>]

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" rel="nofollow">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: "[e-mail]" <[e-mail]>
Date: Monday 06 March 2017 at 15:55
To: Gert Grammel <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: CCAMP <[e-mail]>
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" rel="nofollow">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

原始邮件

发件人： ＜[e-mail]＞;

收件人： ＜[e-mail]＞; ＜[e-mail]＞;

日 期 ：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" ＜[e-mail] on behalf of [e-mail]＞ 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
    
    -----邮件原件-----
    发件人: [e-mail] [mailto:[e-mail]] 
    发送时间: 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" rel="nofollow">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/" rel="nofollow">https://datatracker.ietf.org/doc/draft-zheng-ccamp-gmpls-g709v5-fwk/
    Htmlized:       https://tools.ietf.org/html/draft-zheng-ccamp-gmpls-g709v5-fwk-00" rel="nofollow">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.

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