Technical Summary
This document defines a mechanism for the reoptimization of loosely
routed MPLS and GMPLS (Generalized Multiprotocol Label Switching)
Traffic Engineering (TE) LSPs signaled with RSVP-TE.
Working Group Summary
As far as I know there was no dissent. I am concerned that the
document might not have had as many people seriously interested in
it as might be optimal to make sure that all options are considered
in detail.
Protocol Quality
This has been approved as "informational".
There are very minor editorial sub-optimal use of English words.
For example, at the beginning of section 3: "The aim of this section
is purely to remind the mechanisms involved in...". Here the word
"remind" should be "summarize". There are only a small number of these,
and thus they can be corrected by the RFC editor prior to publication.
Note to RFC Editor
There are a few minor nits to be corrected prior to publication:
nit1>> The first paragraph of section 3 current says:
The aim of this section is purely to remind the mechanisms
involved in the establishment of a loosely routed TE LSP (in
line with [RFC3209]) and does not introduce any new protocol
extensions or mechanisms.
This should be corrected to say:
The aim of this section is purely to summarize the mechanisms
involved in the establishment of a loosely routed TE LSP, as
specified in [RFC3209]. The reader should see RFC3209 for a
more detailed description of these mechanisms.
nit2>>In the first paragraph of section 4, there is a sentence that says:
Since a preferable (e.g. shorter) path might not be visible from the
head-end LSR by means of the IGP if the head-end LSR does not belong
to the head-end IGP area...".
This should say:
Since a preferable (e.g. shorter) path might not be visible from the
head-end LSR by means of the IGP if the head-end LSR does not belong
to the same IGP area where the associated topology change occurred...".
nit3>> in section 7 there is the sentence:
Such a procedure would not be in conflict with any mechanisms
not already documented in [RFC3209] and [RFC3473].
this should say:
Such a procedure would not be in conflict with any mechanisms
already documented in [RFC3209] and [RFC3473].
In addition, the following changes should be made to the IANA
Considerations section:
REMOVE:
IANA will assign a new flag named "Path re-evaluation request" in the
SESSION-ATTRIBUTE object (C-Type 1 and 7) specified in [RFC3209].
Suggested value is (to be confirmed by IANA) 0x20.
Change:
OLD:
IANA will also assign three new error sub-code values for the RSVP
NEW:
IANA will assign three new error sub-code values for the RSVP
And in Section 5.1 change:
OLD:
The following new flag of the SESSION_ATTRIBUTE object (C-Type 1 and
7) is defined (suggested value to be confirmed by IANA):
NEW:
The following new flag of the SESSION_ATTRIBUTE object (C-Type 1 and
7) is defined:
IANA Note
The SESSION ATTRIBUTE flag request has been removed via RFC Editor
note, as that registry has not yet been created. The assignments for
the RSVP PErr error subcodes are still requested. A document will
follow to create the SESSION ATTRIBUTE flag registry.