RFC Errata
Found 1 record.
Status: Held for Document Update (1)
RFC 5063, "Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart", October 2007
Source of RFC: ccamp (rtg)
Errata ID: 1000
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-10-23
Held for Document Update by: Adrian Farrel
Date Held: 2009-08-24
Section 4 says:
(1) Document title and Abstract
Over the years, there have been arising different of flavors of RSVP.
In particular, RSVP-TE, based on the seminal RFC 3209, addresses
quite distinct requirements than the original, QoS oriented, basic
RSVP, and it follows a distinguished service model.
It has been good practice to clearly distinguish between RSVP-TE
and the basic RSVP in the titles of RFCs published in the last
years. Unfortunately, this has not been done for RFC 5063.
BTW:
Some of the extensions to RSVP-TE published in RFC 3473, in
particular those reused and amended per RFC 5063, apparently
are not only applicable to GMPLS, but also to 'classical' MPLS /
MPLS Traffic Engineering. The mentioning of 'GMPLS' in the
title of RFC 5063 therefore seems to unnecessarily narrow the
scope of the RFC. The body of RFC 5063, e.g. the text in the
Introduction, seems to strongly support this point of view.
Therefore, it might perhaps have been preferable to make the title
of RFC 5063 (omitting the expansion of acronyms, anecdotally anyway
only performed partially in the published title):
Extensions to RSVP-TE Graceful Restart
Accordingly, the Abstract of the document should better talk about
RSVP-TE than (pure) RSVP, in its first paragraph.
(2) Section 1 -- word omission
Within Section 1 of RFC 5063, in the 4th paragraph on page 4,
the RFC says:
[...]. The downstream RSVP neighbor
can indicate its ability to send RecoveryPath messages by including
| the Capability object with the RecoveryPath Transmit Enabled set in
its Hello messages to the restarting node. [...]
It should say:
[...]. The downstream RSVP neighbor
can indicate its ability to send RecoveryPath messages by including
| the Capability object with the RecoveryPath Transmit Enabled bit set
in its Hello messages to the restarting node. [...]
^^^^
Note: This correction is in accordance with the language used
in other places in the RFC, in particular the immediate
preceding sentence in the same paragraph.
(3) Section 4.2 -- incomplete specification
Within Section 4.2, the artwork on page 6 depicting the Capability
object includes the RSVP object header and specifies the constant
values applicable for the Class-Num and C-Type field.
Contrary to that, it does not specify the value of the Length field
(that is equally constant for the new object) -- neither in the
diagram, nor does it supply explanatory text for that field (that
could have pointed to the fundamental specification and/or directly
specified the value).
For simplicity, I propose to correct the diagram.
The RFC says:
The format of a Capability object is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Length | Class-Num(134)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |T|R|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For the sake of completeness of the specification, the RFC should say:
The format of a Capability object is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Length (8) | Class-Num(134)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |T|R|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(4) Section 4.4.2 -- potentially misleading omission of article
In the 2nd-to-last paragraph of Section 4.4.2, on top of page 9
RFC 5063 says:
[...]. If the restarting
node expects to recover RSVP state by the receipt and processing of
| RecoveryPath messages, it MUST follow procedures defined in Section
4.5.2, with the downstream RSVP neighbor.
It should say:
[...]. If the restarting
node expects to recover RSVP state by the receipt and processing of
RecoveryPath messages, it MUST follow the procedures defined in
Section 4.5.2, with the downstream RSVP neighbor.
Rationale:
Without the omitted 'the', the reference is to an unspecified set
of procedures there, which might be misleading. For the sake of
clarity and precision, the article should be supplied.
This issue recurs in subsequent parts of the text.
Similar corrections will be listed below in shorthand notation,
referring to this item.
(5) Section 4.5.2.1 -- grammar / terminology
On page 11, at the end of the first paragraph of Section 4.5.2.1,
the RFC says:
[...]. If there is
resynchronized state and there is no MESSAGE_ID object or reliable
message delivery [RFC2961] is not supported, the node SHOULD send a
| trigger Path message, and, consider the message as processed.
^
It should say:
[...]. If there is
resynchronized state and there is no MESSAGE_ID object or reliable
message delivery [RFC2961] is not supported, the node SHOULD send a
| triggered Path message, and, consider the message as processed.
^^^
Rationale: "a trigger Path message" might well be misunderstood
to be a quite different concept than "a triggered Path message".
The latter is the proper term.
This issue recurs in subsequent parts of the text.
Similar corrections will be listed below in shorthand notation,
referring to this item.
(6) Section 4.5.2.2 -- grammar / terminology
As a corollary to item (5) above, in Section 4.5.2.2 the second
line of the last paragraph on page 12 should be corrected:
"a trigger Path message" --> "a triggered Path message"
(7) Section 5 -- word omission, and spurious word
The second paragraph of Section 5, on mid-page 14, says:
Selective transmission of RecoveryPath messages is controlled much
| the same way transmission of Path or Resv messages is controlled with
standard Summary Refresh, see [RFC2961]. In standard Summary
Refresh, an Srefresh message is sent by a node to identify to its
| neighbor about Path and Resv state that is locally installed and
available. [...]
It should say:
Selective transmission of RecoveryPath messages is controlled much
| the same way as transmission of Path or Resv messages is controlled
with standard Summary Refresh, see [RFC2961]. In standard Summary
Refresh, an Srefresh message is sent by a node to identify to its
| neighbor Path and Resv state that is locally installed and available.
[...]
(8) Section 5.2.1 -- potentially misleading omission of article
As a corollary to item (4) above, the text in the 3rd paragraph of
Section 5.2.1, at the bottom of page 16 should be corrected:
"revert to normal procedures defined in Section 4.5.1"
---
"revert to the normal procedures defined in Section 4.5.1"
(9) Section 5.3.2 -- grammar / terminology
As a corollary to item (5) above, in the second paragraph of
Section 5.3.2 (on mid-page 19), apply the corrections:
"a trigger Path message" --> "a triggered Path message"
and
"such trigger Path message" --> "such triggered Path message"
(10) Section 5.3.3 -- potentially misleading omission of article
As another corollary to item (4) above, the text in the first
paragraph of Section 5.3.3, near the bottom of page 19 should be
corrected:
[...]. Processing of MESSAGE_ID NACKs with the
| RecoveryPath Flag set (1) also follows procedures defined in
[RFC2961] unless explicitly modified in this section.
---
[...]. Processing of MESSAGE_ID NACKs with the
| RecoveryPath Flag set (1) also follows the procedures defined in
[RFC2961] unless explicitly modified in this section.
Notes:
[Adrian Farrel]
(1) No change needed. Inclusion of "GMPLS" in the title indicates that this is the GMPLS extensions to the TE extensions to RSVP.
(5), (6) and (9) "trigger Path message" is correct. The name of the Path message is a trigger Path message.
(7) Insertion of "as" is not required in US English.