Re: [CCAMP] WG Last Call Comments on "GMPLS Enhancement for Signal and Network Element Compatibility of Wavelength Switched Optical Networks"

Lou Berger <lberger@labn.net> Fri, 07 February 2014 16:22 UTC

Return-Path: <lberger@labn.net>
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 AEC251A0594 for <ccamp@ietfa.amsl.com>; Fri, 7 Feb 2014 08:22:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 qFmy00twpral for <ccamp@ietfa.amsl.com>; Fri, 7 Feb 2014 08:22:47 -0800 (PST)
Received: from oproxy12-pub.mail.unifiedlayer.com (oproxy12-pub.mail.unifiedlayer.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id B30A21AC7ED for <ccamp@ietf.org>; Fri, 7 Feb 2014 08:22:46 -0800 (PST)
Received: (qmail 14436 invoked by uid 0); 7 Feb 2014 16:22:43 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.mail.unifiedlayer.com with SMTP; 7 Feb 2014 16:22:43 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=G+zullykFLoM2H5CxD3ZnqMxNB6AWF53n6poddw97L8=; b=S6IotyTrv3oQMz2iRrYCVrhC5Svhwbc79n68qSh+Wj6i9A9SNdymVj90Nm6J+fYfdH7LDnYkQbB09Bifd1uKi2xZphIv/4RP1CGazZBnD5axtWcpNnq/rnpXLHz6y6R0;
Received: from box313.bluehost.com ([69.89.31.113]:36166 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from <lberger@labn.net>) id 1WBoCR-0003TM-F9; Fri, 07 Feb 2014 09:22:43 -0700
Message-ID: <52F5084F.7010506@labn.net>
Date: Fri, 07 Feb 2014 11:22:39 -0500
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Leeyoung <leeyoung@huawei.com>, Acee Lindem <acee.lindem@ericsson.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>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729BB6E79@dfweml706-chm.china.huawei.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
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:22:50 -0000

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