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

[Leeyoung <[e-mail]>]

Lou,

OK. I am fine with this. 

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[e-mail]] 
Sent: Thursday, September 11, 2014 3:12 PM
To: Matt Hartley (mhartley); Leeyoung; CCAMP; [e-mail]
Cc: Giovanni Martinelli (giomarti)
Subject: Re: [CCAMP] Still have issues in WSON Processing HOP Attribute Encoding in draft-ietf-ccamp-wson-signaling-08

Matt, Young,
    I suggest that we address this the same way as discussed in the more general context last month, i.e., avoid experimental code points and use "Standards Action and Specification Required policies" as the default policy for IANA registries established by the WG.

Lou

PS this was in the text I proposed as well.

OLD:

    All assignments are to be performed via Standards Action as defined
    in [RFC5226].

NEW:

    All assignments are to be performed via Standards Action and
    Specification Required policies as defined in [RFC5226]


On 9/11/2014 3:08 PM, Matt Hartley (mhartley) wrote:
> Young,
>
> The chairs/ADs will probably be able to give you better guidance than me, but my inclination would be to leave a small range at the top end of the complete range for experimental use. Maybe 120-127? I wouldn't be inclined to put it at the bottom because that will get in the way next time someone wants to assign a new value for a standard...
>
> Cheers
>
> Matt
>
>> Hi Lou,
>>
>> There was one more issue Matt and Giovanni raised on the experimental 
>> code points for Wavelength Selection Method 
>> (http://www.ietf.org/mail- archive/web/ccamp/current/msg16340.html ). 
>> If we allow that, we need to add some value(s) for an experimental 
>> purpose. The current text in Section
>> 6:
>>
>>
>>    Value          Meaning                    Reference
>>
>>    0             unspecified                [This.I-D]
>>
>>    1             First-Fit                  [This.I-D]
>>
>>    2             Random                     [This.I-D]
>>
>>    3             Least-Loaded (multi-fiber) [This.I-D]
>>
>>    4-127          unassigned
>>
>>
>> Perhaps we can add Value 4 to be experimental while 5-127 as 
>> unassigned (if one value is good enough for an experimental purpose).
>>
>> Perhaps, Giovanni or Matt can answer this.
>>
>> Thanks,
>> Young
>> -----Original Message-----
>> From: Leeyoung [mailto:[e-mail]]
>> Sent: Thursday, September 11, 2014 12:54 PM
>> To: Lou Berger; CCAMP; [e-mail]
>> Subject: RE: [CCAMP] Still have issues in WSON Processing HOP 
>> Attribute Encoding in draft-ietf-ccamp-wson-signaling-08
>>
>> 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
>>>>