Re: [CCAMP] Still have issues in WSON Processing HOP Attribute Encoding in draft-ietf-ccamp-wson-signaling-08

Lou Berger <lberger@labn.net> Fri, 12 September 2014 18:00 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 8EC711A7D80 for <ccamp@ietfa.amsl.com>; Fri, 12 Sep 2014 11:00:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level:
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
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 GJZCYGtY120b for <ccamp@ietfa.amsl.com>; Fri, 12 Sep 2014 11:00:45 -0700 (PDT)
Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) by ietfa.amsl.com (Postfix) with SMTP id 8FF511A0BEB for <ccamp@ietf.org>; Fri, 12 Sep 2014 11:00:39 -0700 (PDT)
Received: (qmail 2311 invoked by uid 0); 12 Sep 2014 18:00:37 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy3.mail.unifiedlayer.com with SMTP; 12 Sep 2014 18:00:37 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id qQ0J1o0132SSUrH01Q0MZr; Fri, 12 Sep 2014 18:00:32 -0600
X-Authority-Analysis: v=2.1 cv=F6LEKMRN c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=KAMjFvWR21EA:10 a=kC4BAXwS1W4A:10 a=HFCU6gKsb0MA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=48vgC7mUAAAA:8 a=I0CVDw5ZAAAA:8 a=i0EeH86SAAAA:8 a=yH3NcRW5XCgGdwMzdboA:9 a=ezunSmUAoCsD0yET:21 a=miFGVuneShdn7_r7:21 a=Pihak6nJ3QBQmajC:21 a=QEXdDO2ut3YA:10 a=33rK67OTR_gA:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10
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=NLUt+oGlH+onJuV7lvRkNMLG97wPTGey2+U7z2nKXEU=; b=YTdj2Ntgr+dMhN4i5hPNiFhIzj0aCAyK6P/x6gmqruMyR/tA4iPF8Xfhx/GwmWxIekMmPgOSGhcjp/IPlOVCJsW93EUnqfavJWruxewMUhEBl8Z0PmbP27HcKmmbjNMJ;
Received: from box313.bluehost.com ([69.89.31.113]:44864 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from <lberger@labn.net>) id 1XSV8t-0003Sj-A3; Fri, 12 Sep 2014 12:00:19 -0600
Message-ID: <541334B6.20908@labn.net>
Date: Fri, 12 Sep 2014 14:00:22 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Leeyoung <leeyoung@huawei.com>
References: <53DD040A.6000809@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729C08671@dfweml706-chm.china.huawei.com> <53DFF088.70506@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729C086A9@dfweml706-chm.china.huawei.com> <53E0094F.60200@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729C08831@dfweml706-chm.china.huawei.com> <53E0330B.9000706@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729C0920C@dfweml706-chm.china.huawei.com> <147b54e0130.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <540FA873.2040102@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729C2ED10@dfweml706-chm> <5411D7D8.3000403@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729C2ED98@dfweml706-chm> <541202E2.8090709@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729C2F1EC@dfweml706-chm>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C2F1EC@dfweml706-chm>
Content-Type: text/plain; charset=UTF-8
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}
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/MzRpG-z5EGYyZSL5i-Hrfhbj8NM
Cc: CCAMP <ccamp@ietf.org>, "draft-ietf-ccamp-wson-signaling@tools.ietf.org" <draft-ietf-ccamp-wson-signaling@tools.ietf.org>
Subject: Re: [CCAMP] Still have issues in WSON Processing HOP Attribute Encoding in draft-ietf-ccamp-wson-signaling-08
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, 12 Sep 2014 18:00:50 -0000

Young,

In the IANA section , you don't need to say "suggested" for new
registries.  This document does those assignments.  In other cases, you
should avoid suggestions, unless the values are important for some reason.

Please submit once you are ready.

Lou

PS It's probably best to avoid sending attachments to the list.


On 9/12/2014 12:59 PM, Leeyoung wrote:
> Hi Lou,
>
> Here's the working version (09) that incorporated all the changes so far. Let me know if this is ready to publish. 
>
> Thanks,
> Young
>
> -----Original Message-----
> From: Leeyoung 
> Sent: Thursday, September 11, 2014 3:21 PM
> To: 'Lou Berger'
> Cc: CCAMP; draft-ietf-ccamp-wson-signaling@tools.ietf.org
> Subject: RE: [CCAMP] Still have issues in WSON Processing HOP Attribute Encoding in draft-ietf-ccamp-wson-signaling-08
>
> Lou,
>
> OK. Will do. Is there any other issue left? I guess not. 
>
> I will update the draft shortly with all the corrections so far discussed. 
>
> Thanks,
> Young
>
>
>
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Thursday, September 11, 2014 3:16 PM
> To: Leeyoung
> Cc: CCAMP; draft-ietf-ccamp-wson-signaling@tools.ietf.org
> Subject: Re: [CCAMP] Still have issues in WSON Processing HOP Attribute Encoding in draft-ietf-ccamp-wson-signaling-08
>
> Young,
>     Good point! The length column should be removed from the IANA section.
>
> Lou
>
> On 9/11/2014 1:54 PM, Leeyoung wrote:
>> Hi Lou,
>>
>> OK. Then how about Section 6 (IANA) for the Length of WavelengthSelection? Should that also then 1 (Octet) in Length? 
>>
>> Thanks,
>> Young
>>
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net]
>> Sent: Thursday, September 11, 2014 12:12 PM
>> To: Leeyoung; CCAMP; draft-ietf-ccamp-wson-signaling@tools.ietf.org
>> Subject: Re: [CCAMP] Still have issues in WSON Processing HOP 
>> Attribute Encoding in draft-ietf-ccamp-wson-signaling-08
>>
>> Young,
>>
>> On 9/11/2014 12:12 PM, Leeyoung wrote:
>>> Hi Lou,
>>>
>>> Thanks for taking on this revision. I think all your changes are acceptable. I have a few items that need to be discussed/clarified:
>>>
>>> 1. On the reference [RFC540] in Section 4.2 (the second paragraph), did you mean [RFC5420]?
>> yes!
>>
>>> 2. Section 4.2: The length of WavelengthSelection should be 4 (instead of 1)? 
>> No.  I reused the (sub-)TLV format from 5420 which says:
>>
>>          The entire TLV MUST be padded with between zero and three
>>          trailing zeros to make it four-octet aligned.  The Length field
>>          does not count any padding.
>>
>> This seemed to me to be the most consistent approach.
>>
>>
>>> 3. In 4.2.1, the second sentence in the first paragraph, the verb "is" missing. 
>>>
>>> OLD
>>>
>>> It a list of available Optical Interface Classes and processing capabilities.
>>>
>>> NEW
>>>
>>> It is a list of available Optical Interface Classes and processing capabilities.
>> great.
>>> 4. In 4.2.1, the third bullet item (under the third paragraph):
>>>
>>> OLD
>>>
>>> In the case of a bidirectional LSP, there MUST either be either:
>>>
>>> NEW
>>>
>>> In the case of a bidirectional LSP, there MUST be either:
>> okay.
>>> 5. Section 5: 
>>>
>>> OLD
>>>
>>> This document is builds on the...
>>>
>>> NEW
>>>
>>> This document is built on the...
>>>
>>>
>>> I think that is. 
>> great.
>>
>> Thanks,
>> Lou
>>
>>> Best Regards,
>>> Young
>>>
>>> -----Original Message-----
>>> From: Lou Berger [mailto:lberger@labn.net]
>>> Sent: Tuesday, September 09, 2014 8:25 PM
>>> To: Leeyoung; CCAMP; draft-ietf-ccamp-wson-signaling@tools.ietf.org
>>> Subject: Re: [CCAMP] Still have issues in WSON Processing HOP 
>>> Attribute Encoding in draft-ietf-ccamp-wson-signaling-08
>>>
>>> Young/Authors/WG
>>>
>>> I've done a fairly significant revision of section 4.2-4.4 to align the text with my understanding of the discussion. No additional technical changes are intended. The text should now use [RSVP-RO] to carry the information from those sections. I did the change by editing the most recently published rev (-08). I'll send the authors document versions.
>>> Here's what wdiff says the changes are. Given their scope, I'd be amazed if I didn't miss something.
>>>
>>> Drop me a note if you want a copy of what I send the Authors. 
>>> (Authors, please send comments in response to *this* message and not 
>>> the off-list
>>> message.)
>>>
>>> Lou
>>>
>>> Section 5., paragraph 3:
>>> OLD:
>>>
>>>     In addition to configuring a node along an LSP to input or output a
>>>     signal with specific attributes, we may need to signal the node to
>>>     perform specific processing, such as 3R regeneration, on the signal
>>>     at a particular NE.  [RFC6163] discussed three types of processing:
>>>
>>> NEW:
>>>
>>>     In addition to configuring a node along an LSP to input or output a
>>>     signal with specific attributes, we may need to signal the node to
>>>     perform specific processing, such as 3R regeneration, on the signal
>>>     at a particular node.  [RFC6163] discussed three types of processing:
>>>
>>>
>>> Section 5., paragraph 8:
>>> OLD:
>>>
>>>      3.3. Bidirectional WSON LSPs
>>>
>>> NEW:
>>>
>>>   
>>>      3.3. Bidirectional WSON LSPs
>>>
>>>
>>> Section 4., paragraph 2:
>>> OLD:
>>>
>>>     LSPs signaled through extensions provided in this document MUST
>>>     apply the following signaling parameters:
>>>
>>> NEW:
>>>
>>>   
>>>     LSPs signaled through extensions provided in this document MUST
>>>     apply the following signaling parameters:
>>>
>>>
>>> Section 4., paragraph 7:
>>> OLD:
>>>
>>>      4.2. WSON Processing HOP Attribute TLV Encoding
>>>
>>> NEW:
>>>
>>>      4.2. WSON Processing HOP Attribute TLV
>>>
>>>
>>> Section 4., paragraph 9:
>>> OLD:
>>>
>>>     To target a specific node, this section defines a WSON Processing
>>>     HOP Attribute TLV, which is carried in the subobjects defined in
>>>     [RSVP-RO]. The Type value of the WSON Processing HOP Attribute TLV
>>>     is TBD by IANA.
>>>
>>> NEW:
>>>
>>>     To target a specific node, this section defines a WSON Processing
>>>     HOP Attribute TLV. This TLV is encoded as an attributes TLV, see
>>>     [RFC520]. The TLV is carried in the ERO and RRO LSP Attribute
>>>     Subobjects, and processed according to the procedures, defined in
>>>     [RSVP-RO]. The type value of the WSON Processing HOP Attribute TLV
>>>     is TBD by IANA.
>>>
>>>
>>> Section 4., paragraph 10:
>>> OLD:
>>>
>>>     The contents of this TLV is defined in the subsequent sections.
>>>     Section 4.3 for ResourceBlockInfo sub-TLV and Section 4.4 for
>>>     WavelengthSelection sub-TLV, respectively. The TLV can be
>>>     represented in Reduced Backus-Naur Form (RBNF) [RFC5511] syntax as:
>>>
>>> NEW:
>>>
>>>     The WSON Processing HOP Attribute TLV carries one or more sub-TLVs
>>>     with the following format:
>>>
>>>
>>> Section 4., paragraph 11:
>>> OLD:
>>>
>>>     <WSON Processing HOP Attribute> ::= < ResourceBlockInfo>
>>>     [<ResourceBlockInfo>] <WavelengthSelection>
>>>
>>> NEW:
>>>
>>>      0                   1                   2                   3
>>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>     |     Type      |   Length      |                               |
>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
>>>     //                            Value                            //
>>>     |                                                               |
>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>
>>>
>>> Section 4., paragraph 12:
>>> OLD:
>>>
>>>     The WSON Processing HOP Attribute TLV is a type of a HOP Attributes
>>>     TLV, as defined in [RSVP-RO]. If a receiving node does not recognize
>>>     a sub-TLV, it will follow the procedure defined in [RFC5420], i.e.,
>>>     it MUST generate a PathErr with a new error value of the existing
>>>     Error Code "Unknown Attributes TLV (Sub-codes - 29)".
>>>
>>> NEW:
>>>
>>>        Type
>>>
>>>
>>> Section 4., paragraph 13:
>>> OLD:
>>>
>>>      4.3. Resource Block Information Sub-TLV
>>>
>>> NEW:
>>>
>>>           The identifier of the sub-TLV.
>>>
>>>
>>> Section 4., paragraph 14:
>>> OLD:
>>>
>>>     The Resource block information , or ResourceBlockInfo, sub-TLV
>>>     contains a list of available Optical Interface Classes and
>>>     processing capabilities.
>>>
>>> NEW:
>>>
>>>        Length
>>>
>>>
>>> Section 4., paragraph 15:
>>> OLD:
>>>
>>>     The format of the ResourceBlockInfo sub-TLV value field is defined
>>>     in Section 4 of [WSON-Encode].
>>>
>>> NEW:
>>>
>>>           Indicates the total length of the sub-TLV in octets.  That is, the
>>>           combined length of the Type, Length, and Value fields, i.e.,
>>>           four plus the length of the Value field in octets.
>>>
>>>
>>> Section 4., paragraph 16:
>>> OLD:
>>>
>>>       Type        Sub-TLV Name
>>>
>>> NEW:
>>>
>>>           The entire sub-TLV MUST be padded with zeros to ensure four-octet
>>>           alignment of the sub-TLV.  The Length field does not include any
>>>           padding.
>>>
>>>
>>> Section 4., paragraph 17:
>>> OLD:
>>>
>>>     1 (TBA)      ResourceBlockInfo
>>>
>>> NEW:
>>>
>>>        Value
>>>  
>>>           Zero or more octets of data carried in the sub-TLV.
>>>  
>>>     Sub-TLV ordering is significant and MUST be preserved. Error
>>>     processing follows [RSVP-RO].
>>>  
>>>      The following sub-TLV types are defined in this document:
>>>  
>>>     Sub-TLV Name        Type    Length
>>>     --------------------------------------------------------------
>>>     ResourceBlockInfo    1      variable
>>>     WavelengthSelection  2        1 (3 octets padding )
>>>  
>>>     The TLV can be represented in Reduced Backus-Naur Form (RBNF)
>>>     [RFC5511] syntax as:
>>>  
>>>     <WSON Processing HOP Attribute> ::= < ResourceBlockInfo>
>>>     [<ResourceBlockInfo>] [<WavelengthSelection>]
>>>  
>>>   
>>>      4.2.1. ResourceBlockInfo Sub-TLV
>>>  
>>>     The format of the ResourceBlockInfo sub-TLV value field is defined
>>>     in Section 4 of [WSON-Encode]. It a list of available Optical Interface Classes and
>>>     processing capabilities.
>>>
>>>
>>> Section 4., paragraph 18:
>>> OLD:
>>>
>>>     At least one ResourceBlockInfo sub-TLV MUST be present in the
>>>     WSON_Processing HOP Attribute TLV. At most two ResourceBlockInfo
>>>     sub-TLVs MAY be present in the WSON_Processing HOP Attribute TLV. If
>>>     more than two sub-TLVs are encountered, the first two MUST be
>>>     processed and the rest SHOULD be ignored.
>>>
>>> NEW:
>>>
>>>     At least one ResourceBlockInfo sub-TLV MUST be present in the
>>>     WSON_Processing HOP Attribute TLV. No more than two
>>>     ResourceBlockInfo sub-TLVs SHOULD be present. Any present
>>>     ResourceBlockInfo sub-TLVs MUST be processed in the order received,
>>>     and extra (unprocessed) SHOULD be ignored.
>>>
>>>
>>> Section 4., paragraph 19:
>>> OLD:
>>>
>>>     The <ResourceBlockInfo> contains several information as defined by
>>>     [WSON-Encode]. The following processing rules apply to the sub-TLV:
>>>
>>> NEW:
>>>
>>>     The ResourceBlockInfo field contains several information elements as defined by
>>>     [WSON-Encode]. The following rules apply to the sub-TLV:
>>>
>>>
>>> Section 4., paragraph 20:
>>> OLD:
>>>
>>>     RB Set Field MAY contain more than one RB Identifier. Only the first
>>>     of which MUST be processed, the others SHOULD be ignored.
>>>
>>> NEW:
>>>
>>>     o  RB Set Field can carry one or more RB Identifier. Only the first
>>>        of RB Identifier listed in the RB Set Field SHALL be processed,
>>>        any others SHOULD be ignored.
>>>
>>>
>>> Section 4., paragraph 21:
>>> OLD:
>>>
>>>     In case of signalin a unidirectional LSP, only one ResourceBlockInfo
>>>     sub-TLV MUST be processed and I/O bits can be safely ignored.
>>>
>>> NEW:
>>>
>>>     o  In the case of unidirectional LSPs, only one ResourceBlockInfo
>>>        sub-TLV SHALL be processed and the I and O bits can be safely ignored.
>>>
>>>
>>> Section 4., paragraph 22:
>>> OLD:
>>>
>>>     In case of signaling a bidirectional LSP: if only one
>>>     ResourceBlockInfo is included, bits I and O MUST be both set to 1,
>>>     if two ResourceBlockInfo sub-TLVs are included, bits I and O MUST
>>>     have different values, i.e., only one bit can be set in each
>>>     ResourceBlockInfo sub-TLV. Any violation of these detected by a
>>>     transit or egress node will incur a processing error and SHOULD NOT
>>>     trigger any RSVP message but can be logged locally, and perhaps
>>>     reported through network management mechanisms.
>>>
>>> NEW:
>>>
>>>     o  In the case of a bidirectional LSP, there MUST either be either:
>>>       (a) only one
>>>   ResourceBlockInfo sub-TLV present in a WSON_Processing
>>>           HOP Attribute TLV, and the bits I and O both set to 1, or
>>>       (b) two ResourceBlockInfo sub-TLVs present, one of which has only the I
>>>           bit set and the other of which has only the O bit set.
>>>
>>>
>>> Section 4., paragraph 23:
>>> OLD:
>>>
>>>     The rest of information available within ResourceBlockInfo sub-TLV
>>>     is Optical Interface Class List, Input Bit Rate List and Processing
>>>     Capability List. These lists MAY contain one or more elements. The
>>>     usage of WSON Processing HOP Attribute TLV for the bidirectional
>>>     case is the same as per unidirectional. When an intermediate node
>>>     uses information from this TLV to instruct a node about wavelength
>>>     regeneration, the same information applies to both downstream and
>>>     upstream directions.
>>>
>>> NEW:
>>>
>>>     o  The rest of information carried within the ResourceBlockInfo sub-TLV
>>>        includes Optical Interface Class List, Input Bit Rate List and
>>>        Processing Capability List. These lists MAY contain one or more
>>>        elements. These elements apply equally to both bidirectional
>>>        and unidirectional LSPs.
>>>
>>>
>>> Section 4., paragraph 24:
>>> OLD:
>>>
>>>     This sub-TLV is constructed by an ingress node and the processing is
>>>     applied to all nodes (transit and egress) whose R bit is set in the
>>>     ERO HOP ATTRIBUTE subobject according to [RSVP-RO]. When the R bit
>>>     is set, a node MUST examine the ResourceBlockInfo sub-TLV present in
>>>     the subobject following the rule described in [RFC5420].
>>>
>>> NEW:
>>>
>>>   
>>>
>>>
>>> Section 4., paragraph 25:
>>> OLD:
>>>
>>>     If a node processing an ERO HOP ATTRIBUTE subobject with WSON
>>>     Processing HOP Attributes TLV (which may include the
>>>     ResourceBlockInfo sub-TLVs) longer than the ERO subobject SHOULD
>>>     return a PathErr with an error code "Routing Error" and error value
>>>     "Bad EXPLICT_ROUTE object" with the EXPLICIT_ROUTE object included
>>>     as defined in [RSVP-RO] Section 3.3.
>>>
>>> NEW:
>>>
>>>     Any violation of these rules detected by a transit or egress node
>>>     SHALL be treated as an error and be processed per [RSVP-RO].
>>>
>>>
>>> Section 4., paragraph 26:
>>> OLD:
>>>
>>>     Once a node properly parsed the Sub-TLV, the node applies the
>>>     selected regeneration pool (at that hop) for the LSP. In addition,
>>>     the node SHOULD report compliance by adding a RRO_HOP_ATTRIBUTE
>>>     subobject with the WSON Processing HOP Attribute TLV (and its sub-
>>>     TLVs) which describes the attributes to be reported.
>>>
>>> NEW:
>>>
>>>     A ResourceBlockInfo sub-TLV can be constructed by a node and added
>>>     to a ERO_HOP_ATTRIBUTE subobject in order to be processed by
>>>     downstream nodes (transit and egress). As defined in [RSVP-RO], the
>>>     R bit reflects the LSP_REQUIRED_ATTRIBUTE and LSP_ATTRIBUTE semantic
>>>     defined in [RFC5420] and SHOULD be set accordingly.
>>>
>>>
>>> Section 4., paragraph 27:
>>> OLD:
>>>
>>>      4.4. Wavelength Selection Sub-TLV
>>>
>>> NEW:
>>>
>>>     Once a node properly parses a ResourceBlockInfo Sub-TLV received in
>>>     an ERO_HOP_ATTRIBUTE subobject (according to the rules stated above
>>>     and in [RSVP-RO]), the node allocates the indicated resources, e.g.,
>>>     the selected regeneration pool, for the LSP. In addition, the node
>>>     SHOULD report compliance by adding a RRO_HOP_ATTRIBUTE subobject
>>>     with the WSON Processing HOP Attribute TLV (and its sub-
>>>     TLVs)indicating the utilized resources. ResourceBlockInfo Sub-TLVs
>>>     carried in a RRO_HOP_ATTRIBUTE subobject are subject to [RSVP-RO]
>>>     and standard RRO processing, see [RFC3209].
>>>  
>>>      4.2.2. WavelengthSelection Sub-TLV
>>>
>>>
>>> Section 4., paragraph 29:
>>> OLD:
>>>
>>>     Under this hypothesis, the node initiating the signaling process
>>>     needs to declare its own wavelength availability (through a
>>>     label_set object). Each intermediate node may delete some labels due
>>>     to connectivity constraints or its own assignment policy. At the
>>>     end, the destination node has to make the final decision on the
>>>     wavelength assignment among the ones received through the signaling
>>>     process.
>>>  
>>>     As discussed in [HZang00], a number of different wavelength
>>>     assignment algorithms may be employed. In addition as discussed in
>>>     [RFC6163] the wavelength assignment can be either for a
>>>     unidirectional lightpath or for a bidirectional lightpath
>>>     constrained to use the same lambda in both directions.
>>>
>>> NEW:
>>>
>>>     As discussed in [HZang00], a number of different wavelength
>>>     assignment algorithms may be employed. In addition as discussed in
>>>     [RFC6163] the wavelength assignment can be either for a
>>>     unidirectional lightpath or for a bidirectional lightpath
>>>     constrained to use the same lambda in both directions.
>>>
>>>
>>> Section 4., paragraph 30:
>>> OLD:
>>>
>>>     In order to indicate wavelength assignment directionality and
>>>     wavelength assignment method, a new Wavelength Selection, or
>>>     WavelengthSelection, sub-TLV is defined to be carried in the WSON
>>>     Processing HOP Attribute TLV defined in Section 4.2 of this draft.
>>>     The type value of the Sub-TLV is:
>>>  
>>>        Type               Sub-TLV Name
>>>
>>> NEW:
>>>
>>>     In order to indicate wavelength assignment directionality and
>>>     wavelength assignment method, the Wavelength Selection, or
>>>     WavelengthSelection, sub-TLV is defined to be carried in the WSON
>>>
>>>
>>> Section 4., paragraph 31:
>>> OLD:
>>>
>>>        2(TDA)          <WavelengthSelection>
>>>
>>> NEW:
>>>
>>>   
>>>     Processing HOP Attribute TLV defined above.
>>>
>>>
>>> Section 0, paragraph 0:
>>> OLD:
>>>
>>>     0 - unspecified (any); This does not constrain the WA method used by
>>>     a specific node.
>>>
>>> NEW:
>>>
>>>     0 - unspecified (any); This does not constrain the WA method used by
>>>     a specific node. This value is implied when the WavelengthSelection
>>>     Sub-TLV is absent.
>>>
>>>
>>> Section 3, paragraph 4:
>>> OLD:
>>>
>>>     - W bit not supported: a PathErr MUST be generated with the Error
>>>       Code "Routing Problem" (24) with error sub-code "Unsupported
>>>       WavelengthSelection Symmetry value" (value to be assigned by IANA,
>>>       suggested value: 107).
>>>
>>> NEW:
>>>
>>>   
>>>     - W bit not supported: a PathErr MUST be generated with the Error
>>>       Code "Routing Problem" (24) with error sub-code "Unsupported
>>>       WavelengthSelection Symmetry value" (value to be assigned by IANA,
>>>       suggested value: 107).
>>>
>>>
>>> Section 3, paragraph 5:
>>> OLD:
>>>
>>>     - WA method not supported: a PathErr MUST be generated with the
>>>       Error Code "Routing Problem" (24) with error sub-code "unsupported
>>>       Wavelength Assignment value" (value to be assigned by IANA,
>>>       suggested value: 108).
>>>
>>> NEW:
>>>
>>>     - WA method not supported: a PathErr MUST be generated with the
>>>       Error Code "Routing Problem" (24) with error sub-code "Unsupported
>>>       Wavelength Assignment value" (value to be assigned by IANA,
>>>       suggested value: 108).
>>>
>>>
>>> Section 3, paragraph 6:
>>> OLD:
>>>
>>>     This sub-TLV is constructed by an ingress node and the processing is
>>>     applied to all nodes (transit and egress) whose R bit is set in the
>>>     ERO HOP ATTRIBUTE subobject according to [RSVP-RO]. When the R bit
>>>     is set, a node MUST examine the WavelengthSelection sub-TLV present
>>>     in the subobject following the rule described in [RFC5420].
>>>  
>>>     If a node processing an ERO HOP ATTRIBUTE subobject with WSON
>>>     Processing HOP Attributes TLV (which may include the
>>>     WavelengthSelection sub-TLVs) longer than the ERO subobject SHOULD
>>>     return a PathErr with an error code "Routing Error" and error value
>>>     "Bad EXPLICT_ROUTE object" with the EXPLICIT_ROUTE object included
>>>     as defined in [RSVP-RO] Section 3.3.
>>>
>>> NEW:
>>>
>>>     A WavelengthSelection sub-TLV can be constructed by a node and added
>>>     to a ERO_HOP_ATTRIBUTE subobject in order to be processed by downstream
>>>     nodes (transit and egress). As defined in [RSVP-RO], the R bit reflects
>>>     the LSP_REQUIRED_ATTRIBUTE and LSP_ATTRIBUTE semantic defined in
>>>     [RFC5420] and SHOULD be set accordingly.
>>>
>>>
>>> Section 3, paragraph 7:
>>> OLD:
>>>
>>>     Once a node properly parsed the Sub-TLV, the node applies wavelength
>>>     assignment method (at that hop) for the LSP. In addition, the node
>>>     SHOULD report compliance by adding a RRO_HOP_ATTRIBUTE subobject
>>>     with the WSON Processing HOP Attribute TLV (and its sub-TLVs) which
>>>     describes the attributes to be reported.
>>>
>>> NEW:
>>>
>>>     Once a node properly parses the WavelengthSelection Sub-TLV received
>>>     in an ERO_HOP_ATTRIBUTE subobject, the node use the indicated
>>>     wavelength assignment method (at that hop) for the LSP. In addition,
>>>     the node SHOULD report compliance by adding a RRO_HOP_ATTRIBUTE
>>>     subobject with the WSON Processing HOP Attribute TLV (and its
>>>     sub-TLVs) indicated the utilized method. WavelengthSelection
>>>     Sub-TLVs carried in a RRO_HOP_ATTRIBUTE subobject are subject to
>>>     [RSVP-RO] and standard RRO processing, see [RFC3209].
>>>
>>>
>>> Section 6., paragraph 0:
>>> OLD:
>>>
>>>  6. IANA Considerations
>>>
>>> NEW:
>>>
>>>   
>>>  
>>>  6. IANA Considerations
>>>
>>>
>>> Section 6., paragraph 1:
>>> OLD:
>>>
>>>     Upon approval of this document, IANA is requested to make the
>>>     assignment of a new value for the existing "Attributes TLV Space"
>>>     registry located at http://www.iana.org/assignments/rsvp-te-
>>>     parameters/rsvp-te-parameters.xhtml:
>>>
>>> NEW:
>>>
>>>     Upon approval of this document, IANA is requested to make the
>>>     assignment of a new value for the existing "Attributes TLV Space"
>>>     registry located at http://www.iana.org/assignments/rsvp-te-
>>>     parameters/rsvp-te-parameters.xhtml, as updated by [RSVP-RO]:
>>>
>>>
>>> Section 6., paragraph 2:
>>> OLD:
>>>
>>>     Type           Name        Allowed on        Allowed on  Reference
>>>                                LSP ATTRIBUTES    LSP REQUIRED_
>>>                                                  ATTRIBUTES
>>>
>>> NEW:
>>>
>>>     Type  Name      Allowed on  Allowed on   Allowed on   Reference
>>>                     LSP         LSP REQUIRED RO LSP
>>>                     ATTRIBUTES  ATTRIBUTES   Attribute
>>>                                              Subobject
>>>
>>>
>>> Section 6., paragraph 3:
>>> OLD:
>>>
>>>     4 (Suggested)  WSON        No                No         [This.I-D]
>>>                    Processing
>>>                    HOP Attribute
>>>                    TLV
>>>
>>> NEW:
>>>
>>>     TBA  WSON       No          No           Yes          [This.I-D]
>>>                    Processing
>>>          HOP
>>>          Attribute
>>>                    TLV
>>>
>>>
>>> Section 2, paragraph 1:
>>> OLD:
>>>
>>>     All assignments are to be performed via Standards Action as defined
>>>     in [RFC5226 <http://tools.ietf.org/html/rfc5226>].
>>>
>>> NEW:
>>>
>>>     All assignments are to be performed via Standards Action and
>>>     Specification Required policies as defined in [RFC5226
>>>     <http://tools.ietf.org/html/rfc5226>].
>>>
>>>
>>> Section 0, paragraph 0:
>>> OLD:
>>>
>>>     Value          Meaning                    Reference
>>>     0             unspecified                [This.I-D]
>>>
>>> NEW:
>>>
>>>     Value          Meaning                    Reference
>>>  
>>>   
>>>     0             unspecified                [This.I-D]
>>>
>>>
>>> Section 3, paragraph 2:
>>> OLD:
>>>
>>>     All assignments are to be performed via Standards Action as defined
>>>     in [RFC5226 <http://tools.ietf.org/html/rfc5226>].
>>>  
>>>     Upon approval of this document, IANA is requested to make the
>>>     assignment of a new value for the existing "Error Codes and
>>>     Globally-Defined Error Value Sub-Codes - 29 Unknown Attribute TLV"
>>>     registry located at http://www.iana.org/assignments/rsvp-
>>>     parameters/rsvp-parameters.xml:
>>>  
>>>     Value                Meaning                       Reference
>>>  
>>>      41 (suggested)     Unknown WSON Processing
>>>                          HOP Attribute sub-TLV type    [This.I-D]
>>>
>>> NEW:
>>>
>>>     All assignments are to be performed via Standards Action and
>>>     Specification Required policies as defined in [RFC5226
>>>     <http://tools.ietf.org/html/rfc5226>].
>>>
>>>
>>> On 8/8/2014 7:08 AM, Lou Berger wrote:
>>>> Young,
>>>>
>>>> Stating with the unintended change documented in v 08 is fine with me. 
>>>> I am a bit disappointed that we haven't heard from more wg 
>>>> participants. Perhaps we're suffering from August vacations...
>>>>
>>>> I'll send some purposed changes to -08.
>>>>
>>>> Lou
>>>>
>>>>
>>>> On August 7, 2014 4:08:51 PM Leeyoung <leeyoung@huawei.com> wrote:
>>>>
>>>>> Hi Lou,
>>>>>
>>>>> Based on Cyril's comment on RBI TLV, it is reasonable to think of 
>>>>> its encoding using HOP Attribute TLV/ERO subobject per [RVSP-RO] 
>>>>> which is the current text.
>>>>>
>>>>> If, however, we were to separate RBI TLV from WA method TLV (i.e, 
>>>>> putting this under LSP_REQUIRED_ATTRIBUTES Object), this adds more 
>>>>> changes on current implementation. For a distributed WA perspective 
>>>>> (which is the case this draft is dealing with), WA method need not 
>>>>> be an LSP-level attribute, especially around Resource Blocks 
>>>>> (Wavelength Conversion). If we can accept this, I think we can 
>>>>> encode WA method TLV as HOP Attribute TLV encoded as ERO subobject.
>>>>> This implies the current 08 text is fine with some consistency check.
>>>>>
>>>>> Young
>>>>>
>>>>> -----Original Message-----
>>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>>> Sent: Monday, August 04, 2014 8:28 PM
>>>>> To: Leeyoung; CCAMP; draft-ietf-ccamp-wson-signaling@tools.ietf.org
>>>>> Subject: Re: [CCAMP] Still have issues in WSON Processing HOP 
>>>>> Attribute Encoding in draft-ietf-ccamp-wson-signaling-08
>>>>>
>>>>> Young,
>>>>>     I think the text is inconsistent (looking back on -07 and the emails).  My 
>>>>>     primary focus / desire at this time is clarifying the existing text without 
>>>>>     making any substantive technical changes.
>>>>>
>>>>> The narrative implies [RSVP-RO], but the editors' intent was 
>>>>> LSP_REQUIRED_ATRIBUTES object.  I personally (all hats off) think 
>>>>> LSP_REQUIRED_ATTRIBUTES object is right for WA method and [RSVP-RO] 
>>>>> is right for RBI.  With hats on, I'd like the text to reflect 
>>>>> implementations and the LC.
>>>>>
>>>>> At this point it might be useful to hear from others in the WG.
>>>>>
>>>>> WG/All/Authors/Contributors,
>>>>>     Does anyone else care to weigh in?
>>>>>
>>>>> Thanks,
>>>>> Lou
>>>>>
>>>>> On 8/4/2014 7:00 PM, Leeyoung wrote:
>>>>>> Hi Lou,
>>>>>>
>>>>>> Good point on RBI info! I can think of the RB Identifier (32 bit
>>>>>> field)
>>>>> to imply the node/interface to which wavelength conversion would 
>>>>> take place if we were to use LSP_REQUIRED_ATRIBUTES object. In 
>>>>> other words, making the RB Identifier globally significant in a 
>>>>> domain, per hop treatment of the RBs is possible.
>>>>>> On the other hand, a better way to treat Resource Block 
>>>>>> Information seems
>>>>> to be using an alternative way (i.e., using HOP Attributes/ERO 
>>>>> subobject per [RSVP-RO]).
>>>>>> If making the RB ID globally significant creates a problem, we 
>>>>>> need to
>>>>> make some technical changes to the draft. Let me know what you think.
>>>>>> Regards,
>>>>>> Young
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>>>> Sent: Monday, August 04, 2014 5:30 PM
>>>>>> To: Leeyoung
>>>>>> Cc: CCAMP; draft-ietf-ccamp-wson-signaling@tools.ietf.org
>>>>>> Subject: Re: [CCAMP] Still have issues in WSON Processing HOP 
>>>>>> Attribute Encoding in draft-ietf-ccamp-wson-signaling-08
>>>>>>
>>>>>> Young,
>>>>>>     Thanks for the quick response.  I "get" how WA method works, 
>>>>>> but am
>>>>> less clear how Resource Block Information (e.g., Regeneration 
>>>>> control and Attribute Conversion control) works per node. For 
>>>>> example, how would control of wavelength conversion at a particular node work?
>>>>>> Perhaps just running through this one simple case will help...
>>>>>>
>>>>>> Again, as a reminder, the desire is to document existing intent 
>>>>>> rather
>>>>> than redefining the solution.
>>>>>> Much thanks,
>>>>>> Lou
>>>>>>
>>>>>> On 8/4/2014 5:08 PM, Leeyoung wrote:
>>>>>>> Hi Lou,
>>>>>>>
>>>>>>> Since the LSP_REQUIRED_ATTRIBUTES object is meant to allow each 
>>>>>>> transit node to inspect the TLV's under it, each transit node 
>>>>>>> will inspect RBI or WA method and apply if it has relevance for 
>>>>>>> the node; otherwise just pass to the next hop. (Section 5 of RFC 
>>>>>>> 5420 has this
>>>>>>> clause: "This means that this object SHOULD only be used for 
>>>>>>> attributes that require support at some transit LSRs and so 
>>>>>>> require examination at all transit LSRs.")
>>>>>>>
>>>>>>> This may not be optimal but a way to get around technical changes 
>>>>>>> as you
>>>>> pointed out not to do so at this moment.
>>>>>>> If we want this to be optimal and require technical changes to 
>>>>>>> the
>>>>> draft, we can go with an alternative, utilizing [RSVP-RO] draft 
>>>>> with ERO subobject/HOP Attributes to encode RBI or WA method as its TLVs.
>>>>>>> Whichever the WG wants, we can go either way.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Young
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>>>>> Sent: Monday, August 04, 2014 3:44 PM
>>>>>>> To: Leeyoung; CCAMP;
>>>>>>> draft-ietf-ccamp-wson-signaling@tools.ietf.org
>>>>>>> Subject: Re: [CCAMP] Still have issues in WSON Processing HOP 
>>>>>>> Attribute Encoding in draft-ietf-ccamp-wson-signaling-08
>>>>>>>
>>>>>>> Young,
>>>>>>>
>>>>>>> On 8/4/2014 4:29 PM, Leeyoung wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Lou, here's my comment on your comment. In a nutshell replacing
>>>>> [RSVP-RO] with [RFC5420] will solve the confusion.
>>>>>>>> Please see in-line for details.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Young
>>>>>>> So you are saying that Resource Block Information and Wavelength
>>>>> Assignment Method are encoded end-to-end and *never* have 
>>>>> hop/node/interface specific meaning (as they are each encoded as an 
>>>>> Attribute TLV in an LSP_REQUIRED_ATTRIBUTE object), is this correct?
>>>>>>> ARE YOU SURE?
>>>>>>>
>>>>>>> How do you envision the LSP_REQUIRED_ATTRIBUTE object conveying 
>>>>>>> per-hop information? (As discussed in section 3.2 and the first 
>>>>>>> paragraph on section 4.2.)
>>>>>>>
>>>>>>> Lou
>>>>>>> ....
>>>>>>>
>>>>>>>
>>>>>>>
>>>> _______________________________________________
>>>> CCAMP mailing list
>>>> CCAMP@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>