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
