Re: [Gen-art] [Teas] review of draft-ietf-teas-lsp-attribute-ro-02.txt

[Elwyn Davies <[e-mail]>]

On 04/03/2015 06:04, Cyril Margaria wrote:
> Hi,
>
> Thanks for your review,
> Please not that a new revision addressing IANA , APS-DIR and Gen-ART
> comments  on revision -02 is available.
> https://tools.ietf.org/html/draft-ietf-teas-lsp-attribute-ro-03
>
>   please see inline.
Hi, Cyril.

Yes:  my comments and the new version crossed.

However -03 doesn't significantly alter para 1 of s2.3.

Firstly, I am far from expert in this area, so I have not much clue as 
to whether it would ever be useful or meaningful to associate an 
attribute with a Label rather than with the entity identified by the 
other subobject types.  However, it has just occurred to me that with 
the loopback case, one needs to  decide that if there are two labels, 
does loopback apply to both of them or just one?  Arrrgggh!

Perhaps something like the following, replacing the first two paras of 
s2.3, would cover all the bases and push the decision down to the 
document that defines the TLV(s)/flags used in the Hop attribute subobjects:

OLD:
    As described in [RFC3209] and [RFC3473] the ERO is managed as a list
    where each hop information starts with a subobject identifying an
    abstract node or link.  The ERO Hop Attributes subobject MAY be
    appended after any of the existing subobjects defined in [RFC3209],
    [RFC3473], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553].
    Several ERO Hop Attributes subobject MAY be present, for each hop.

    Document defining specific Hop attribute TLV has to describe after
    which kind of subobject they are valid and if TLV modification rules
    applies.  For instance, subobject presence rules can be defined by
    describing rules similar to [RFC4990] Section 6.1.

NEW:
    As described in [RFC3209] the ERO is managed as a list of subobjects
    each identifying a specific entity, an abstract node or a link that 
defines
    a waypoint in the ERO route.  Identifying subobjects of various 
types are
    defined in [RFC3209], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and
    [RFC5553].

    [RFC3473] modified the ERO list by allowing one or two Label subobjects
    to be interposed in the list after a subobject identifying an entity 
by its
    IP address or interface identifier.   One or more ERO Hop attributes
    subobjects applicable to a particular hop MAY be inserted directly 
after
    any of the existing identifying subobjects defined in [RFC3209], 
[RFC3477],
    [RFC4873], [RFC4874], [RFC5520] and [RFC5553].  If any Label subobjects
    are present for a hop, the ERO Hop attributes subobject(s) MAY also be
    inserted after the Label subobjects.

    The attributes specified in a ERO Hop attributes subobject apply to 
the hop
    that ends at the route waypoint identified by the immediately preceding
    identifying subobject in the ERO subobject list.

    A document defining a specific Hop attribute TLV has to describe
       -  after which kinds of subobject they are valid ,
       -  if ordering of the Hop attributes subobject and other subobjects
          associated with the same hop (e.g., Label subobjects) is 
significant,
       -  if ordering is significant, how the attribute is interpreted in
          association with the preceding subobjects, and
       -  any TLV modification rules that might apply.
    For instance, subobject presence rules can be defined by describing 
rules
    similar to [RFC4990] Section 6.1.

This might require a few words added to s2.2 to specify that the 
ordering decision for individual flags is up to the definition of the 
flag.  In turn that possibly means that the loopback draft needs to 
think about whether the loopback applies to both labels or only the one 
the loopback flag is after as mentioned above.

Regards,
Elwyn

PS
There is discussion about the .all aliases going to WG lists as well as 
relevant individuals.  The long standing position was that they didn't 
but change has recently been mooted.

/E

>
>
>
>
> On 3 March 2015 at 12:58, Elwyn Davies <[e-mail]> wrote:
>
>>   Hi.
>>
>> In the process of doing the gen-art review of
>> draft-ietf-teas-rsvp-te-li-lb for IETF last call, I needed to look at
>> draft-ietf-teas-lsp-attribute-ro-02 in connection with some comments about
>> ordering of subobjects in the loopback draft.
>>
>> I thought that the text in the first paragraph of s2.3:
>>
>>     As described in [RFC3209 <https://tools.ietf.org/html/rfc3209>] and [RFC3473 <https://tools.ietf.org/html/rfc3473>] the ERO is managed as a list
>>     where each hop information starts with a subobject identifying an
>>     abstract node or link.  The ERO Hop Attributes subobject MAY be
>>     appended after any of the existing subobjects defined in [RFC3209 <https://tools.ietf.org/html/rfc3209>],
>>     [RFC3473 <https://tools.ietf.org/html/rfc3473>], [RFC3477 <https://tools.ietf.org/html/rfc3477>], [RFC4873 <https://tools.ietf.org/html/rfc4873>], [RFC4874 <https://tools.ietf.org/html/rfc4874>], [RFC5520 <https://tools.ietf.org/html/rfc5520>] and [RFC5553 <https://tools.ietf.org/html/rfc5553>].
>>     Several ERO Hop Attributes subobject MAY be present, for each hop.
>>
>>   was not very clear: The use of 'appended' was slightly confusing.  I felt
>> it needed something a bit closer to the "Presence Rules" that are given for
>> RRO subobjects in RFC 5420, s7.3.1 to make it quite clear what is going
>> on.
>>
>> I am not totally clear what would happen in the case of (say) an IPv4
>> address subobject followed by two Label subobjects.  The wording seems to
>> indicate that Hop attributes can be inserted anywhere in the sequence of
>> three subobjects - but would they specifically apply to one or other Label
>> if they were inserted after a Label or would they always apply generically
>> to the hop terminated at the IPv4 address entity?
>>
>>
> draft-ietf-teas-lsp-attribute-ro tries to leave that open to the documents
> defining the TLVs. We are not excluding an Attribute that applies to a
> Label or Interface. If the subobject would be inserted after a Label
> Subobject, the Attribute TLVs would apply to the Labels.
>
> This is based on the following review comment:"
> I think *this* I-D needs to make it clear what the expectations are:
>
> 1. The sub-object is allowed at any point in the ERO
> 2. The document that specifies a TLV for the sub-object must make it
>     clear where in an ERO a sub-object containing that TLV is allowed and
>     not allowed."
>
> Do you think this is reasonable or we should exclude TLVs scoped to labels?
> In the latter case, I would add you suggested text.
>
> Best Regards.
> Cyril
>
> PS: It seems there are errors with the tools.ietf.org aliases
>
>
>> My suggestion for rewording, based on the assumption that the hop
>> attributes apply to the hop rather than any of the labels, would be:
>>
>>     As described in [RFC3209] the ERO is managed as a list of subobjects
>>     each identifying a specific entity, an abstract node or a link.
>> Identifying
>>     subobjects of various types are defined in [RFC3209], [RFC3477],
>> [RFC4873],
>>     [RFC4874], [RFC5520] and [RFC5553].  [RFC3473] modified the ERO list by
>>     allowing one or two Label subobjects to be interposed in the list after
>> a
>>     subobject identifying an entity by its IP address or interface
>> identifier.   One
>>     or more ERO Hop attributes subobjects applicable to a particular hop
>> MAY
>>     be inserted after any of the existing identifying subobjects defined in
>>     [RFC3209],  [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553].
>>     If any Label subobjects are present for a hop, the ERO Hop attributes
>>     subobject(s) MUST be inserted after the Label subobjects.
>>
>> The last two sentences would need to be altered if Hop attributes were
>> applicable to Labels rather than just to the hop as a whole.
>>
>> Regards,
>> Elwyn
>>
>>
>>
>> _______________________________________________
>> Teas mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/teas
>>
>>