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

From: Leeyoung <[email-masked]>
Date: Mon, 8 Sep 2014 22:04:33 +0000

Hi Lou,

Are you intending to the proposed changes for this draft before your new assignment for TEAS WG? It will be great to move on with the draft with the current leadership. 

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Friday, August 08, 2014 6:08 AM
To: Leeyoung; CCAMP; [email-masked]
Subject: RE: [CCAMP] Still have issues in WSON Processing HOP Attribute Encoding in draft-ietf-ccamp-wson-signaling-08

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 <[email-masked]> 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:[email-masked]]
> Sent: Monday, August 04, 2014 8:28 PM
> To: Leeyoung; CCAMP; [email-masked]
> 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:[email-masked]]
> > Sent: Monday, August 04, 2014 5:30 PM
> > To: Leeyoung
> > Cc: CCAMP; [email-masked]
> > 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:[email-masked]]
> >> Sent: Monday, August 04, 2014 3:44 PM
> >> To: Leeyoung; CCAMP; [email-masked]
> >> 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
> >> ....
> >>
> >>
> >>
> >
>
>

---

From: Lou Berger <[email-masked]>
Date: Tue, 09 Sep 2014 12:32:47 -0400

Young,
    The changes have taken me longer to do (and get to) than I'd hoped
-- I'm expecting to have them out  today.

WRT work in the WG, as Adrian said in his mail, all changes are future
looking and WGs/chairs are currently unchanged (and ongoing work is to
continue as such).

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 09 Sep 2014 14:54:35 -0400

Young/Authors/...,

How big is a typical and maximum-sized ResourceBlockInfo?

Thanks,
Lou

On 8/7/2014 4:08 PM, Leeyoung 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
>
> 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.
>
>> 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
>>
>>     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?
>>
>> Again, as a reminder, the desire is to document existing intent rather than redefining the solution.
>>
>> Much thanks,
>> Lou
>>
>>> 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
>>> 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. 
>>>
>>>> Lou, here's my comment on your comment. In a nutshell replacing [RSVP-RO] with [RFC5420] will solve the confusion. 
>>>>
>>> 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?  
>>>

---

From: Leeyoung <[email-masked]>
Date: Tue, 9 Sep 2014 20:15:44 +0000

Hi Lou,

A quick analysis on RBI was done: 

RBI consists of:
1. RB Set Field (96 bits) (for 2 RBs, one for active, other for backup)
2. Header (32 bits)
3. Optional Subfield that consists of
	a. OIC (96 bits)  
      b. Acceptable Client Signal 64 bits (assuming two G-PIDs are supported: G.709 ODUj and G.709 OTUk(v))
      c. Input Bit Rate (64 bits) (assuming two G-PIDs supported as above)
      d. Processing Capability (64 bits) (assuming Regeneration) 

This gives a total of 416 bits (=52 bytes). In a typical optical path (8-10 hops), there may be one Regenerator or two at maximum (due to cost of Regenerators). 

The total size of RBI does not change as more RB's are added (as RB Set Field has a way to put the range of RB Identifiers). 

Is that what you are looking for? 

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, September 09, 2014 1:55 PM
To: Leeyoung; [email-masked]
Cc: CCAMP
Subject: Re: [CCAMP] Still have issues in WSON Processing HOP Attribute Encoding in draft-ietf-ccamp-wson-signaling-08

Young/Authors/...,

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 09 Sep 2014 18:28:25 -0400

Yes.  The approach that was last discussed has a max of about ~100+
bytes/RBI.  Looks like we're okay.

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 09 Sep 2014 21:25:07 -0400

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...
>
>> 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
>>
>> Subject: Re: [CCAMP] Still have issues in WSON Processing HOP Attribute 
>> Encoding in draft-ietf-ccamp-wson-signaling-08
>>
>> Young,
>> right for RBI.  With hats on, I'd like the text to reflect implementations 
>> and the LC.
>>
>>> 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 
>>>     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?
>> 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.
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>

---

From: Lou Berger <[email-masked]>
Date: Wed, 10 Sep 2014 11:51:06 -0400

All,

I'm sending the  revised section to increase the likelihood that the
text will be reviewed.  Please take a look and comment.  Again, the
objective is to document the resolution of the issue discussed/resolved
in http://www.ietf.org/mail-archive/web/ccamp/current/msg16366.html and
I'd be surprised if I didn't miss something.

Lou

On 9/9/2014 9:25 PM, Lou Berger wrote:
> ...

   Section 3.2. provided the requirements for signaling to indicate to
   a particular node along an LSP what type of processing to perform on
   an optical signal or how to configure that node to accept or
   transmit an optical signal with particular attributes.

    0                   1                   2                   3

      Type

      Length

      Value

   Sub-TLV Name        Type    Length

   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.

   The ResourceBlockInfo field contains several information elements as
defined by
   [WSON-Encode]. The following rules apply to the sub-TLV:

   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.

   Routing + Distributed Wavelength Assignment (R+DWA) is one of the
   options defined by the [RFC6163]. The output from the routing
   function will be a path but the wavelength will be selected on a
   hop-by-hop basis.

  
   The WavlengthSelection sub-TLV value field is defined as:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |W|  WA Method  |                    Reserved                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where:

   W (1 bit): 0 denotes requiring the same wavelength in both
   directions, 1 denotes that different wavelengths on both directions
   are allowed.

   Wavelength Assignment (WA) Method (7 bits):

   1 - First-Fit. All the wavelengths are numbered and this WA method
   chooses the available wavelength with the lowest index.

   2 - Random. This WA method chooses an available wavelength randomly.

   3 - Least-Loaded (multi-fiber). This WA method selects the
   wavelength that has the largest residual capacity on the most loaded
   link along the route. This method is used in multi-fiber networks.
   If used in single-fiber networks, it is equivalent to the FF WA
   method.

   4- 127: Unassigned.

   The processing rules of this TLV are as follows:

   If a receiving node does not support the attribute(s), its behaviors
   are specified below:

---

From: Leeyoung <[email-masked]>
Date: Thu, 11 Sep 2014 16:12:14 +0000

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:[email-masked]] 
Sent: Tuesday, September 09, 2014 8:25 PM
To: Leeyoung; CCAMP; [email-masked]
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:

NEW:

Section 5., paragraph 8:
OLD:

NEW:

  

Section 4., paragraph 2:
OLD:

NEW:

  

Section 4., paragraph 7:
OLD:

NEW:

Section 4., paragraph 9:
OLD:

NEW:

NEW:

NEW:

     0                   1                   2                   3

NEW:

       Type

NEW:

NEW:

       Length

NEW:

      Type        Sub-TLV Name

NEW:

NEW:

       Value

 
 
    Sub-TLV Name        Type    Length

 
  

NEW:

NEW:

NEW:

NEW:

NEW:

NEW:

NEW:

  

NEW:

NEW:

NEW:

 

NEW:

 
       Type               Sub-TLV Name

NEW:

NEW:

  

Section 0, paragraph 0:
OLD:

NEW:

Section 3, paragraph 4:
OLD:

NEW:

  

Section 3, paragraph 5:
OLD:

NEW:

Section 3, paragraph 6:
OLD:

NEW:

Section 3, paragraph 7:
OLD:

NEW:

Section 6., paragraph 0:
OLD:

 6. IANA Considerations

NEW:

  
 
 6. IANA Considerations

Section 6., paragraph 1:
OLD:

NEW:

Section 6., paragraph 2:
OLD:

NEW:

Section 6., paragraph 3:
OLD:

NEW:

Section 2, paragraph 1:
OLD:

NEW:

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:

 
    Value                Meaning                       Reference

NEW:

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

---

From: Lou Berger <[email-masked]>
Date: Thu, 11 Sep 2014 13:11:52 -0400

Young,

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

> It is a list of available Optical Interface Classes and processing capabilities.

great.
> In the case of a bidirectional LSP, there MUST be either:

okay.
> This document is built on the...

great.

Thanks,
Lou

---

From: Leeyoung <[email-masked]>
Date: Thu, 11 Sep 2014 17:54:17 +0000

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:[email-masked]] 
Sent: Thursday, September 11, 2014 12:12 PM
To: Leeyoung; CCAMP; [email-masked]
Subject: Re: [CCAMP] Still have issues in WSON Processing HOP Attribute Encoding in draft-ietf-ccamp-wson-signaling-08

Young,

yes!

great.

okay.

great.

Thanks,
Lou

> 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:
>
>>> 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.
>>>
>>> (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
>>>
>>> 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.
>>> 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?
>>>>> attributes that require support at some transit LSRs and so 
>>>>> require examination at all transit LSRs.")
>>>>>
>>>>> To: Leeyoung; CCAMP; 
>>>>> [email-masked]

---

From: Leeyoung <[email-masked]>
Date: Thu, 11 Sep 2014 19:03:09 +0000

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:[email-masked]] 
Sent: Thursday, September 11, 2014 12:54 PM
To: Lou Berger; CCAMP; [email-masked]
Subject: RE: [CCAMP] Still have issues in WSON Processing HOP Attribute Encoding in draft-ietf-ccamp-wson-signaling-08

Hi Lou,

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Thursday, September 11, 2014 12:12 PM
To: Leeyoung; CCAMP; [email-masked]
Subject: Re: [CCAMP] Still have issues in WSON Processing HOP Attribute Encoding in draft-ietf-ccamp-wson-signaling-08

Young,

yes!

great.

okay.

great.

Thanks,
Lou

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Thu, 11 Sep 2014 19:08:03 +0000

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]
> 
> Perhaps we can add Value 4 to be experimental while 5-127 as unassigned
> (if one value is good enough for an experimental purpose).
> 
> Subject: RE: [CCAMP] Still have issues in WSON Processing HOP Attribute
> OK. Then how about Section 6 (IANA) for the Length of WavelengthSelection?
> Should that also then 1 (Octet) in Length?
> 
> Thanks,
> Young
> 
> > Thanks for taking on this revision. I think all your changes are
> acceptable. I have a few items that need to be discussed/clarified:
> >
> downstream

---

From: Leeyoung <[email-masked]>
Date: Thu, 11 Sep 2014 19:35:17 +0000

Matt,

That sounds good to me. 

Thanks,
Young

-----Original Message-----
From: Matt Hartley (mhartley) [mailto:[email-masked]] 
Sent: Thursday, September 11, 2014 2:08 PM
To: Leeyoung; Lou Berger; CCAMP; [email-masked]
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,

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]
> 
> Perhaps we can add Value 4 to be experimental while 5-127 as 
> unassigned (if one value is good enough for an experimental purpose).
> 
> Subject: RE: [CCAMP] Still have issues in WSON Processing HOP 
> > 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)?
> >           Indicates the total length of the sub-TLV in octets.  That 
> > is,
> the
> >           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.
> >
> >
> >     o  The rest of information carried within the ResourceBlockInfo 
> > sub-
> TLV
> >>> 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.
> >>> 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.
> >>>
> >>> 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.
> >>> example, how would control of wavelength conversion at a 
> >>> particular
> node work?
> >>>>> 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
> >>>>> This may not be optimal but a way to get around technical 
> >>>>> changes as you
> >>> 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.
> >>> 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?
> >>>>>

---

From: Lou Berger <[email-masked]>
Date: Thu, 11 Sep 2014 16:11:47 -0400

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:

    in [RFC5226].

NEW:

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

---

From: Lou Berger <[email-masked]>
Date: Thu, 11 Sep 2014 16:15:30 -0400

Young,
    Good point! The length column should be removed from the IANA section.

Lou

---

From: Leeyoung <[email-masked]>
Date: Thu, 11 Sep 2014 20:18:14 +0000

Lou,

OK. I am fine with this. 

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Thursday, September 11, 2014 3:12 PM
To: Matt Hartley (mhartley); Leeyoung; CCAMP; [email-masked]
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

OLD:

NEW:

On 9/11/2014 3:08 PM, Matt Hartley (mhartley) wrote:
>> 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]
>>

---

From: Leeyoung <[email-masked]>
Date: Thu, 11 Sep 2014 20:20:48 +0000

Lou,

OK. Will do. Is there any other issue left? I guess not. 

I will update the draft shortly with all the corrections so far discussed. 

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Thursday, September 11, 2014 3:16 PM
To: Leeyoung
Cc: CCAMP; [email-masked]
Subject: Re: [CCAMP] Still have issues in WSON Processing HOP Attribute Encoding in draft-ietf-ccamp-wson-signaling-08

Young,

Lou

---

From: Leeyoung <[email-masked]>
Date: Fri, 12 Sep 2014 16:59:57 +0000

Hi Lou,

Here's the working version (09) that incorporated all the changes so far. Let me know if this is ready to publish. 

Thanks,
Young

-----Original Message-----
From: Leeyoung 
Sent: Thursday, September 11, 2014 3:21 PM
To: 'Lou Berger'
Cc: CCAMP; [email-masked]
Subject: RE: [CCAMP] Still have issues in WSON Processing HOP Attribute Encoding in draft-ietf-ccamp-wson-signaling-08

Lou,

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Thursday, September 11, 2014 3:16 PM
To: Leeyoung
Cc: CCAMP; [email-masked]
Subject: Re: [CCAMP] Still have issues in WSON Processing HOP Attribute Encoding in draft-ietf-ccamp-wson-signaling-08

Young,

Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 12 Sep 2014 14:00:22 -0400

Young,

In the IANA section , you don't need to say "suggested" for new
registries.  This document does those assignments.  In other cases, you
should avoid suggestions, unless the values are important for some reason.

Please submit once you are ready.

Lou

PS It's probably best to avoid sending attachments to the list.

---

From: Leeyoung <[email-masked]>
Date: Fri, 12 Sep 2014 18:02:26 +0000

Lou,

OK. Will correct and submit the draft shortly. 

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Friday, September 12, 2014 1:00 PM
To: Leeyoung
Cc: CCAMP; [email-masked]
Subject: Re: [CCAMP] Still have issues in WSON Processing HOP Attribute Encoding in draft-ietf-ccamp-wson-signaling-08

Young,

In the IANA section , you don't need to say "suggested" for new registries.  This document does those assignments.  In other cases, you should avoid suggestions, unless the values are important for some reason.

Lou