errata logo graphic

Found 1 record.

Status: Held for Document Update (1)

RFC5063, "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

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.


Report New Errata