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 <[email protected]> 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 <[email protected]> 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
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/teas
>>>
>>>
>>>
>
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
