RFC Errata
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.