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

[Elwyn Davies <[e-mail]>]

Hi, Cyril.

Yes.. That looks good.  Thanks!

Dong Jie will hopefully take this on board for the loopback flag in 
draft-ietf-teas-rsvp-te-li-lb. We have been discussing this earlier today.

Regards,
Elwyn

On 05/03/2015 03:28, Cyril Margaria wrote:
> Hi,
>
> Thanks for the quick feedback,
> Would the following text modification address your comments .
> the wording is a bit different, I tried to simplify the description of the
> TLV scope.
>
>     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 network path.  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
>     a link.  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 immediately preceding subobject(s) in the ERO subobject list.
>
>     A document defining a specific Hop Attribute TLV has to describe:
>
>     o  after which kinds of ERO subobject they are valid ,
>
>     o  if ordering of the Hop Attributes subobject and other ERO
>        subobjects associated with the same hop (e.g., Label subobjects)
>        is significant,
>
>     o  if ordering is significant, how the attribute is interpreted in
>        association with the preceding ERO subobjects, and
>
>     o  any TLV modification rules that might apply.
>
>     For instance, subobject presence rules can be defined by describing
>     rules similar to [RFC4990] Section 6.1.
>
>
> That would allow a TLV to apply to one (or more) preceding subobject, the
> type of subobject being left to the TLV.
>
> Regarding section 2.2, the following text is proposed:
>
>     The presence and ordering rule of the Attribute Flags TLV in an ERO
>     Hop Attributes Subobject is defined by each Flag.  A document
>     defining a Flag to be used in a Attribute Flags TLV carried in the
>     ERO Hop Attributes Subobject has to describe:
>
>     o  after which kinds of ERO subobject the Flag is valid
>
>     o  if ordering of the Flag and other ERO subobjects associated with
>        the same hop (e.g., Label subobjects) is significant,
>
>     o  if ordering is significant, how the Flag is interpreted in
>        association with the preceding subobjects,
>
>     o  any Flag modification rules that might apply.
>
>
> If its Ok, I can post a new revision shortly.
>
> Best Regards
> Cyril
>
>
>
> On 4 March 2015 at 13:29, Elwyn Davies <[e-mail]> wrote:
>
>>
>> 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
>>>>
>>>>
>>>>