Re: [CCAMP] WG Last Call Comments on "GMPLS Enhancement for Signal and Network Element Compatibility of Wavelength Switched Optical Networks"
Leeyoung <leeyoung@huawei.com> Fri, 07 February 2014 16:38 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 D92C71A0500 for <ccamp@ietfa.amsl.com>; Fri, 7 Feb 2014 08:38:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.736
X-Spam-Level:
X-Spam-Status: No, score=-3.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 pV9ORYGH1vXU for <ccamp@ietfa.amsl.com>; Fri, 7 Feb 2014 08:37:58 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 229E71AC497 for <ccamp@ietf.org>; Fri, 7 Feb 2014 08:37:56 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDI94673; Fri, 07 Feb 2014 16:37:54 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 7 Feb 2014 16:36:53 +0000
Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 7 Feb 2014 16:37:53 +0000
Received: from DFWEML706-CHM.china.huawei.com ([169.254.8.193]) by dfweml705-chm.china.huawei.com ([169.254.7.245]) with mapi id 14.03.0158.001; Fri, 7 Feb 2014 08:37:50 -0800
From: Leeyoung <leeyoung@huawei.com>
To: Lou Berger <lberger@labn.net>, Acee Lindem <acee.lindem@ericsson.com>
Thread-Topic: [CCAMP] WG Last Call Comments on "GMPLS Enhancement for Signal and Network Element Compatibility of Wavelength Switched Optical Networks"
Thread-Index: AQHO1PR6OxsJkAR0EUmBv2bkfRkIWpqkwG2wgAOaAACAAL9NMIACBByA//99pMA=
Date: Fri, 07 Feb 2014 16:37:49 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729BB72C0@dfweml706-chm.china.huawei.com>
References: <94A203EA12AECE4BA92D42DBFFE0AE47030B0E4A@eusaamb101.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729BB5F34@dfweml706-chm.china.huawei.com> <06D60676-4C54-4D18-AD96-F436E7C39DEC@ericsson.com> <7AEB3D6833318045B4AE71C2C87E8E1729BB6E79@dfweml706-chm.china.huawei.com> <52F5084F.7010506@labn.net>
In-Reply-To: <52F5084F.7010506@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.192.11.238]
Content-Type: multipart/mixed; boundary="_002_7AEB3D6833318045B4AE71C2C87E8E1729BB72C0dfweml706chmchi_"
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: Fri, 07 Feb 2014 16:38:02 -0000
Hi Lou, My bad, here's the working version with correction. Let me know if this is ready to publish with a summary of changes. Thanks, Young -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Friday, February 07, 2014 10:23 AM To: Leeyoung; Acee Lindem Cc: CCAMP Subject: Re: [CCAMP] WG Last Call Comments on "GMPLS Enhancement for Signal and Network Element Compatibility of Wavelength Switched Optical Networks" Young, You missed this comment: CURRENT: The format of Label is required of the use of the label format defined in [RFC6205] for interfaces advertised with WSON-LSC. NEW The label format defined in [RFC6205] MUST be used when advertising interfaces with a WSON-LSC type Switching Capability. Lou On 2/6/2014 2:40 PM, Leeyoung wrote: > 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? * > > > > > > 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. * > > > > 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