Re: [Teas] Issues with draft-ietf-teas-lsp-attribute-ro (was: AD review draft-ietf-teas-rsvp-te-li-lb)

[Ben Wright <[e-mail]>]

Thanks Lou. I agree with your points.  

On point 2)
- Section 2.2 changes, the text here looks good to me.  I'd add "The set of valid flags are defined in section 4.3" as a forward reference to make life easier for the reader. 

- On the MIP and SRLG collection flags: I don't really see a requirement for allowing them to be included in the LSP Hop Attributes subobject in the ERO.  In both cases I'd expect a network admin would always want to enable the function on all nodes on the path of an LSP.  If someone has a good use case for allowing these to be set differently on different hops, then it would be straightforward to raise a separate draft to describe the use case and change this position.  

On point 3) agree. 

Other folks?  Cyril - if you agree, are you OK to make these changes?

Ben

-----Original Message-----
From: Lou Berger [mailto:[e-mail]] 
Sent: 07 January 2015 17:00
To: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Teas] Issues with draft-ietf-teas-lsp-attribute-ro (was: AD review draft-ietf-teas-rsvp-te-li-lb)

[resend]

All,
    I believe Adrian has identified a few issues with draft-ietf-teas-lsp-attribute-ro in his review of draft-ietf-teas-rsvp-te-li-lb, see below for context.  In particular:

1) In the IANA section, the document states that Attribute Flags cannot be carried in a LSP Hop Attributes subobject. It looks like this was a cut&paste bug introduced in rev 01 when translating the expanded directions into table form.  The old -00 text in section 5.3.1 said:
   o  Allowed on LSP attribute ERO subobject so the following change should be made.
OLD:
           1 Attribute Flags       Yes   Yes    No    [RFC5420]
NEW
           1 Attribute Flags       Yes   Yes    Yes    [RFC5420]

2) Adrian points out that many existing flags really don't make sense in in the LSP attribute ERO subobject and I think this should be documented. To do this fully, I think we can either preclude usage of existing flags or allow for specific flags (I could see allowing it for MIP, SRLG collection, but am okay either way).  Either way there should be an explicit statement on this, as well as a new column in the IANA table (with a new IANA section describing this change).

For the explicit statement, how about adding the following to the end of  section 2.2:

    The Attribute Flags TLV defined in [RFC5420] MAY be carried in an
    ERO Hop Attributes Subobject.  Flags set in the an Attribute Flags
    TLV [RFC5420] carried in a ERO Hop Attributes Subobject SHALL be
    interpreted in the context of the received ERO. Only a subset of
    defined flags are defined as valid for use in Attribute Flags TLV
    carried in a ERO Hop Attributes Subobject. Invalid  flags SHALL be
    silently ignored. Unknown flags SHOULD trigger the generation of
    a PathErr with Error Code "Unknown Attributes Bit" as defined in
    [RFC5420] Section 5.2.

And
4.3. Existing Attribute Flags

   IANA manages the "Attribute Flags" registry  as part of the "RSVP-TE PARAMETERS" registry located at
   http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te-
   parameters.xml.  A new column in the registry is introduced
   by this document.  This column indicates if the flag is permitted to be
   used in a Attribute Flags TLV carried in the ERO Hop Attributes
   Subobject.  The column uses the heading "ERO" and the registery is
   to be updated as follows:

Bit Name                   Attribute Attribute RRO ERO Reference
                           FlagsPath FlagsResv
  0  End-to-end re-routing    Yes        No     No  No [RFC4920]
                                                      [RFC5420]
 1  Boundary re-routing      Yes        No     No  No [RFC4920]
                                                      [RFC5420]
 2  Segment-based re-routing Yes        No     No  No [RFC4920]
                                                      [RFC5420]
 3  LSP Integrity Required   Yes        No     No  No [RFC4875]
 4  Contiguous LSP           Yes        No     Yes No [RFC5151]
 5  LSP stitching desired    Yes        No     Yes No [RFC5150]
 6  Pre-Planned LSP Flag     Yes        No     No  No [RFC6001]
 7  Non-PHP behavior flag    Yes        No     Yes No [RFC6511]
 8  OOB mapping flag         Yes        No     Yes No [RFC6511]
 9  Entropy Label Capability Yes        Yes    No  No [RFC6790]
10  OAM MEP entities desired Yes        Yes    Yes No [RFC7260]
11  OAM MIP entities desired Yes        Yes    Yes No [RFC7260]
12  SRLG collection Flag     Yes        Yes    Yes No [draft-ietf-
   (TEMPORARY - registered                             ccamp-rsvp-
    2014-09-11, expires                                te-srlg-
    2015-09-11)                                        collect]

   New allocation requests to this registry shall indicate the value to be used in the ERO column.

3) the discussion also caught one naming inconsistency:
s/4.1. ERO LSP Attribute Subobject/4.1 ERO Hop Attributes Subobject

I think that's it.  Comments?

Lou

On 1/6/2015 1:02 PM, Lou Berger wrote:
> Adrian (all)
>
> On 1/6/2015 7:43 AM, Adrian Farrel wrote:
> ...
>>> You want to use a bit in the Attribute Flags TLV to indicate 
>>> Loopback and propose including that TLV in the HOP Attributes ERO 
>>> subobject as defined in draft-ietf-ccamp-lsp-attribute-ro.
>>>> However, draft-ietf-teas-lsp-attribute-ro defines that the 
>>>> Attributes Flags
>> TLV is
>>>> not allowed in the HOP Attributes ERO subobject. I think this is 
>>>> for a good reason that many (all?) of bits defined so far have no 
>>>> meaning if targeted
>> at a
>>>> specific transit LSR.
>>> I guess there may be some confusion about this. Section 5.3.1 of
>> draft-ietf-teas-
>>> lsp-attribute-ro-00 gives the rules of using Attributes Flags TLV, 
>>> which says
>> it is
>>> "Allowed on LSP attribute ERO subobject". And in section 5.1, the 
>>> "ERO HOP Attribute Subobject" is also called "ERO LSP Attribute 
>>> Subobject", thus my understanding is that the "Attributes Flags TLV" 
>>> is allowed in the "ERO HOP Attribute subobject".
>> OK, well, draft-ietf-teas-lsp-attribute-ro is now at -01 and seems to 
>> have changed a bit.
>>
>> The WG needs to work this through (no need to involve me :-).
>> If draft-ietf-teas-lsp-attribute-ro-01 is correct, then this I-D 
>> needs to change.
>> If this I-D is correct, then draft-ietf-teas-lsp-attribute-ro needs to change.
> I this document is correct, and think you've identified a few issues 
> with draft-ietf-teas-lsp-attribute-ro (which has also been submitted 
> for
> publication) and I'll start a new thread on these.
>