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

[Cyril Margaria <[e-mail]>]

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