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

[Leeyoung <[e-mail]>]

Matt,

That sounds good to me. 

Thanks,
Young

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

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