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

[Lou Berger <[e-mail]>]

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