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

[Lou Berger <[e-mail]>]

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:[e-mail]] 
> Sent: Thursday, September 11, 2014 12:12 PM
> To: Leeyoung; CCAMP; [e-mail]
> 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:[e-mail]]
>> Sent: Tuesday, September 09, 2014 8:25 PM
>> To: Leeyoung; CCAMP; [e-mail]
>> 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 <[e-mail]> 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:[e-mail]]
>>>> Sent: Monday, August 04, 2014 8:28 PM
>>>> To: Leeyoung; CCAMP; [e-mail]
>>>> 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:[e-mail]]
>>>>> Sent: Monday, August 04, 2014 5:30 PM
>>>>> To: Leeyoung
>>>>> Cc: CCAMP; [e-mail]
>>>>> 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:[e-mail]]
>>>>>> Sent: Monday, August 04, 2014 3:44 PM
>>>>>> To: Leeyoung; CCAMP; 
>>>>>> [e-mail]
>>>>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>