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
