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

[Leeyoung <[e-mail]>]

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

2. Section 4.2: The length of WavelengthSelection should be 4 (instead of 1)? 

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.

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:

5. Section 5: 

OLD

This document is builds on the...

NEW

This document is built on the...


I think that is. 

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
>