Re: [CCAMP] WG Last Call Comments on "GMPLS Enhancement for Signal and Network Element Compatibility of Wavelength Switched Optical Networks"
Leeyoung <leeyoung@huawei.com> Wed, 12 February 2014 21:07 UTC
Return-Path: <leeyoung@huawei.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAEB1A06CE for <ccamp@ietfa.amsl.com>; Wed, 12 Feb 2014 13:07:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.747
X-Spam-Level:
X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9M-p0DFbgKa for <ccamp@ietfa.amsl.com>; Wed, 12 Feb 2014 13:07:49 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 530F41A0620 for <ccamp@ietf.org>; Wed, 12 Feb 2014 13:07:48 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBB19743; Wed, 12 Feb 2014 21:07:45 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Feb 2014 21:07:28 +0000
Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Feb 2014 21:07:43 +0000
Received: from DFWEML706-CHM.china.huawei.com ([169.254.8.193]) by dfweml703-chm.china.huawei.com ([169.254.5.188]) with mapi id 14.03.0158.001; Wed, 12 Feb 2014 13:07:35 -0800
From: Leeyoung <leeyoung@huawei.com>
To: Acee Lindem <acee.lindem@ericsson.com>, Lou Berger <lberger@labn.net>
Thread-Topic: [CCAMP] WG Last Call Comments on "GMPLS Enhancement for Signal and Network Element Compatibility of Wavelength Switched Optical Networks"
Thread-Index: AQHO1PR6OxsJkAR0EUmBv2bkfRkIWpqkwG2wgAOaAACAAL9NMIAA3iOAgAjK4SA=
Date: Wed, 12 Feb 2014 21:07:34 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729BB8986@dfweml706-chm.china.huawei.com>
References: <7AEB3D6833318045B4AE71C2C87E8E1729BB6E79@dfweml706-chm.china.huawei.com> <CF19511E.26A70%acee.lindem@ericsson.com>
In-Reply-To: <CF19511E.26A70%acee.lindem@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.192.11.238]
Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729BB8986dfweml706chmchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: CCAMP <ccamp@ietf.org>
Subject: Re: [CCAMP] WG Last Call Comments on "GMPLS Enhancement for Signal and Network Element Compatibility of Wavelength Switched Optical Networks"
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Feb 2014 21:07:55 -0000
Hi Acee, Thanks. I think this closes all pending issues related to this draft. I will publish an updated version shortly. Regards, Young From: Acee Lindem [mailto:acee.lindem@ericsson.com] Sent: Thursday, February 06, 2014 4:50 PM To: Leeyoung; Lou Berger Cc: CCAMP Subject: Re: [CCAMP] WG Last Call Comments on "GMPLS Enhancement for Signal and Network Element Compatibility of Wavelength Switched Optical Networks" Hi Young, From: Leeyoung <leeyoung@huawei.com<mailto:leeyoung@huawei.com>> Date: Thursday, February 6, 2014 11:40 AM To: Ericsson <acee.lindem@ericsson.com<mailto:acee.lindem@ericsson.com>>, Lou Berger <lberger@labn.net<mailto:lberger@labn.net>> Cc: CCAMP <ccamp@ietf.org<mailto:ccamp@ietf.org>> Subject: RE: [CCAMP] WG Last Call Comments on "GMPLS Enhancement for Signal and Network Element Compatibility of Wavelength Switched Optical Networks" Hi Acee and Lou, Here's the working document and the idnits results. Acee, Please see inline for my comments to your comments. I have incorporated all your comments except one - I need your clarification. Thanks. Young From: Acee Lindem [mailto:acee.lindem@ericsson.com] Sent: Wednesday, February 05, 2014 4:11 PM To: Leeyoung Cc: CCAMP Subject: Re: [CCAMP] WG Last Call Comments on "GMPLS Enhancement for Signal and Network Element Compatibility of Wavelength Switched Optical Networks" Hi Young, On Feb 3, 2014, at 7:21 PM, Leeyoung <leeyoung@huawei.com<mailto:leeyoung@huawei.com>> wrote: Hi Acee, Here's my comments inline on your comments. Thanks. Young From: ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org> [mailto:ccamp-bounces@ietf.org] On Behalf Of Acee Lindem Sent: Tuesday, October 29, 2013 5:16 PM To: CCAMP Subject: [CCAMP] WG Last Call Comments on "GMPLS Enhancement for Signal and Network Element Compatibility of Wavelength Switched Optical Networks" I have the following comments on the subject draft: 1. State the action to take if the new TLV and sub-TLVs or their attendant encodings are malformed. You should log the problem and ignore the entire LSA, subsuming TLV, or just the sub-TLV in GMPLS path computations. YOUNG>> In Section 5.2, added: "In case where the new sub-TLVs or their attendant encodings are malformed, the proper action would be to log the problem and ignore just the sub-TLVs in GMPLS path computations rather than ignoring the entire LSA." See inline. YOUNG>> Which inline are you referring to? I meant this to be at the top. 2. Section 2 - Your definition of "At most once" is semantically wrong. "At most once" means the TLV or sub-TLV can be include one time or not at all. It has nothing to with whether or not it should be specified. I hope we are not going to attempt to change the English language with this draft. YOUNG>> Corrected. Is a new text OK with you? "All sub-TLVs defined here may occur at most once in any given Optical Node TLV. If more than one copy of a sub-TLV is received, only the first one of the same type is accommodated and the rest are ignored upon receipt." Yes - although I'd replace "accommodated" with "processed". YOUNG>> OK. Corrected. 3. Section 3 - Figure 1 should not span multiple pages and the scale is off by one - it should be shifted right 1 column. YOUNG>> Done Ok. 4. Section 6 - Explicitly state which are IANA registries are being extended. Since you are adding a new TLV, you will also need a new registry for the sub-TLVs. Seehttp://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xhtml#top-level for examples. YOUNG>> Done. Please check if the corrections are good. It would be easier for IANA if you explicitly state that you are creating two new registries. A new IANA registry will be created for sub-TLVs of the Optical Node Property TLV. The following sub-TLVs are allocated in this specification. o o o Additionally, a new IANA registry will be created for nested sub-TLVs of the Resource Block Information sub-TLV. The following sub-TLVs are allocated in this specification. o o o YOUNG>> I reshuffled the order starting from the Optical Node Property TLV, and its sub-TLVs and nested-TLVs; then WSON-LSC Switching Type TLV and its sub-TLVs. Please see the enclosed working version. Ok - Looks good. Thanks, Acee Thanks, Acee Editorial Comments: I would suggest the following corrections: 125c125 < to allow both multiple WSON signal types and common hybrid electro --- > to support both multiple WSON signal types and common hybrid electro 197c197 < node. It is constructed of a set of sub-TLVs. There are no ordering --- > node. It is comprised of a set of sub-TLVs. There are no ordering 203c203 < encodings of these properties are defined in [WSON-Encode]. --- > encodings for these properties are defined in [WSON-Encode]. 253,254c253 < router, as described in [RFC3630] and [RFC5250]. Resource Block < Information --- > router, as described in [RFC3630] and [RFC5250]. 279,280c278,279 < The detail encodings of these sub-TLVs are found in [WSON-Encode] as < indicated in the table below. --- > The detailed encodings of these sub-TLVs are found in [WSON-Encode] > as indicated in the table below. 293c292 < relation to the switching device. In particular it indicates the --- > relation to the switching device. In particular, it indicates the 302,303c301,302 < reach or leave all the resources. Resource Block Wavelength < Constraints sub-TLV describe these properties. --- > reach or leave all the resources. The Resource Block Wavelength > Constraints sub-TLV describes these properties. 316c315 < case then wavelength availability on these shared fibers is needed --- > case, then wavelength availability on these shared fibers is needed 353c352 < Bandwidth TLV are defined (TBA by IANA): --- > Bandwidth sub-TLVs are defined (TBA by IANA): 402c401 < produce LSAs that exceed the IP Maximum Transmission Unit (MTU). In --- > produce LSAs that exceeds the IP Maximum Transmission Unit (MTU). In 417,422c416,421 < is received for a system path cannot make use of the other four sub- < TLVs since it does not know the nature of the resources, e.g., are < the resources wavelength converters, regenerators, or something < else. Once this sub-TLV is received path computation can proceed < with whatever of the additional types of sub-TLVs it may have < received (there use is dependent upon the system type). If path --- > is received for a system, path compuation cannot make use of the > other four sub-TLVs since it does not know the nature of the > resources, e.g., are the resources wavelength converters, > regenerators, or something else. Once this sub-TLV is received, > path computation can proceed with whatever sub-TLVs it may have > received (their use is dependent upon the system type). If path 433c432 < these sub-TLVs then there is the possibility of either (a) path --- > these sub-TLVs, then there is the possibility of either (a) path Thanks, Acee <draft-ietf-ccamp-gmpls-general-constraints-ospf-te-07.txt>
- [CCAMP] WG Last Call Comments on "GMPLS Enhanceme… Acee Lindem
- Re: [CCAMP] WG Last Call Comments on "GMPLS Enhan… Leeyoung
- Re: [CCAMP] WG Last Call Comments on "GMPLS Enhan… Acee Lindem
- Re: [CCAMP] WG Last Call Comments on "GMPLS Enhan… Leeyoung
- Re: [CCAMP] WG Last Call Comments on "GMPLS Enhan… Acee Lindem
- Re: [CCAMP] WG Last Call Comments on "GMPLS Enhan… Lou Berger
- Re: [CCAMP] WG Last Call Comments on "GMPLS Enhan… Leeyoung
- Re: [CCAMP] WG Last Call Comments on "GMPLS Enhan… Lou Berger
- Re: [CCAMP] WG Last Call Comments on "GMPLS Enhan… Leeyoung