RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 9 records.

Status: Verified (4)

RFC 4873, "GMPLS Segment Recovery", May 2007

Source of RFC: ccamp (rtg)

Errata ID: 1797

Status: Verified
Type: Technical

Reported By: David McWalter
Date Reported: 2009-06-23
Verifier Name: Adrian Farrel
Date Verified: 2010-08-20

Section 5.2 says:

The collection of SRROs is controlled via the
segment-recording-desired flag in the SESSION_ATTRIBUTE object.  This
flag MAY be set even when SEROs are not used.

It should say:

   The collection of SRROs is controlled via the
   presence of an RRO in the message being processed.

Notes:

No request was made to IANA to assign a value for the segment-recording-desired flag.

As reported in the Errata, the segment-recording-desired flag is
unassigned. The flag is unassigned and therefore cannot be used.
As agreed to on the CCAMP mail list and the Stockholm (IETF 75)
working group meeting the the collection of SRROs should be
controlled based on the presence of an RRO in the message being
processed. That is, the segment-recording-desired flag should be
considered to be set when an RRO is present in the message being
processed.

Errata ID: 937

Status: Verified
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Verifier Name: Adrian Farrel
Date Verified: 2010-10-30

Section 4.2.4 says:

   Recovery LSP removal follows standard procedures defined in [RFC3209]
   and [RFC3473].  This includes with and without setting the
   administrative status.

It should say:

   Recovery LSP removal follows standard procedures defined in [RFC3209]
   and [RFC3473].  These procedures include LSP removal with and without
   setting the administrative status flags described in Section 7 of
   [RFC3473].

Errata ID: 939

Status: Verified
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Verifier Name: Adrian Farrel
Date Verified: 2010-10-30

Section 4.3.1 says:

   o new text:
      If a message contains multiple NOTIFY_REQUEST objects, only the
      first object used is in notification.  Subsequent NOTIFY_REQUEST
      objects MUST be propagated in the order received.

It should say:

   o new text:
      If a message contains multiple NOTIFY_REQUEST objects, only the
      first object is used to supply the information used to build and
      send a notification. Subsequent NOTIFY_REQUEST objects MUST be
      propagated in the order received.

Notes:

The original proposed text (below) is rejected because the presence of the NOTIFY_REQUEST object is not a trigger.
o new text:
If a message contains multiple NOTIFY_REQUEST objects, only the
first object is used to potentially trigger a notification.
Subsequent NOTIFY_REQUEST objects MUST be propagated in the order
received.

Errata ID: 943

Status: Verified
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Verifier Name: Adrian Farrel
Date Verified: 2010-10-30

Section 6.1 says:

   LSP Segment Recovery Flags are carried in the PROTECTION object of
   the same C-Type defined in [RFC4872].  The format of the flags are:

It should say:

   LSP Segment Recovery Flags are carried in the PROTECTION object of
   C-Type 2 defined in [RFC4872].  The format of the modifed PROTECTION
   object carrying these flags is:

Notes:

The subsequent diagram depicts the full object, not only the (new) flags.

Status: Held for Document Update (2)

RFC 4873, "GMPLS Segment Recovery", May 2007

Source of RFC: ccamp (rtg)

Errata ID: 935

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Held for Document Update by: Adrian Farrel

 

Section 2

Near the end of the second-to-last paragraph on page 5, RFC 4873 says:

                                                        [...].  The
   branch node of a recovery LSP creates an SRRO by copying the RRO from
|  the Resv message of associated recovery LSP into a new SRRO object.
   Any SRROs present in the recovery LSP's Resv message are also copied.

It should say:
                                                        [...].  The
   branch node of a recovery LSP creates an SRRO by copying the RRO from
|  the Resv message of the associated recovery LSP into a new SRRO
   object.  Any SRROs present in the recovery LSP's Resv message are
   also copied.

Rationale:  missing article.


Section 3.2

On page 7, the last sentence of Section 3.2 says:

|              [...].  This object MUST NOT be used when association is
   made according to the methods defined in [RFC4090].

It should say:

|              [...].  This object MUST NOT be used when an association
   is made according to the methods defined in [RFC4090].

Rationale:  missing article.


Section 4.1

On page 8, Section 4.1 says:

                   [...].  This includes the definition of subobjects
|  defined for EXPLICIT_ROUTE object.  The class of the
   SECONDARY_EXPLICIT_ROUTE object is 200 (of the form 11bbbbbb).

It should say:

                   [...].  This includes the definition of subobjects
|  defined for the EXPLICIT_ROUTE object.  The class of the
   SECONDARY_EXPLICIT_ROUTE object is 200 (of the form 11bbbbbb).

Rationale:  missing article.


Section 4.2

In the second paragraph on page 10, Section 4.2 says:

|  At a branch node, the SERO, together with the Path message of LSP
   being recovered, provides the information to create the recovery LSP.
   [...]

It should say:

|  At a branch node, the SERO, together with the Path message of the LSP
   being recovered, provides the information to create the recovery LSP.
   [...]

Rationale:  missing article.


Section 4.2.1

Near the bottom of page 10, the first paragraph of Section 4.2.1 says:

                                                          [...].  The
|  processing of these events depend on a number of factors.

It should say:
                                                          [...].  The
|  processing of these events depends on a number of factors.
                                    ^
Rationale:  grammar.


Section 4.3.2

The second sentence of Section 4.3.2 says:

|                      [...].  When a branch or merge node receives
   notification of an LSP failure and it is unable to recover from that
   failure, [...]

It should say:
|                      [...].  When a branch or merge node receives a
   notification of an LSP failure and it is unable to recover from that
   failure, [...]

Rationale:  missing article.


Section 6.2

The last sentence of the third paragraph of Section 6.2,
on mid-page 17, says:

                                                             [...].  The
   dynamically identified information, together with the Path message of
|  LSP being recovered, is used to create the recovery LSP.

It should say:
                                                             [...].  The
   dynamically identified information, together with the Path message of
|  the LSP being recovered, is used to create the recovery LSP.

Rationale:  missing article.


It should say:

[see above]

Notes:

editorial nits.

from pending

Errata ID: 941

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Held for Document Update by: Adrian Farrel
Date Held: 2010-10-30

Section 5.1 says:

   The format of a SECONDARY_RECORD_ROUTE object is the same as a
   RECORD_ROUTE object, Class number 21.  This includes the definition
   of subobjects defined for RECORD_ROUTE object.  The class of the
   SECONDARY_RECORD_ROUTE object is 201 (of the form 11bbbbbb).

It should say:

   The format of a SECONDARY_RECORD_ROUTE object is the same as that of
   a RECORD_ROUTE object, Class number 21.  This includes the definition
   of subobjects defined for the RECORD_ROUTE object.  The class of the
   SECONDARY_RECORD_ROUTE object is 201 (of the form 11bbbbbb).

Notes:

The proposed text change (below) is rejected in favor of more correct English.
The format of a SECONDARY_RECORD_ROUTE object is the same as for a
RECORD_ROUTE object, Class number 21. This includes the definition
of subobjects defined for the RECORD_ROUTE object. The class of the
SECONDARY_RECORD_ROUTE object is 201 (of the form 11bbbbbb).

Status: Rejected (3)

RFC 4873, "GMPLS Segment Recovery", May 2007

Source of RFC: ccamp (rtg)

Errata ID: 936

Status: Rejected
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Rejected by: Adrian Farrel
Date Rejected: 2010-10-30

Section 4.2.3 says:

  In general, objects in a recovery LSP are created based on the
  corresponding objects in the LSP being protected.  [...]

It should say:

[not submitted]

Notes:

IMHO makes use of too sluggish language; talking about
"objects in a recovery LSP" or "objects in the LSP being protected"
should be avoided because it messes up the essentials of [G]MPLS,
the separation of the data plane carrying arbitrary labeled data
packets and the control plane (with RSVP-TE carrying the TE objects).
Unfortunately, similar language recurs at other places in the RFC;
for the sake of brevity, I refrain from listing all those instances
below.

I would appreciate very much future derived and/or related work to
return to a more precise language.

from pending
--VERIFIER NOTES--
There has long been a conflation of "LSP" to mean the data plane entity (connection) and the also the control plane state necessary to maintain the data plane entity. The body of people working in the MPLS and CCAMP working groups are used to this and can readily deduce which meaning is intended. Additional text is added when the author believes it is important to make an explicity distinction.

Since this Erratum is not specifically actionable on this RFC, it is rejected.

Errata ID: 944

Status: Rejected
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Rejected by: Adrian Farrel
Date Rejected: 2010-10-30

 

The rules given in the two paragraphs on top of page 18,

   The resulting Path message is used to create the recovery LSP.  While
   the recovery LSP exists, the PROTECTION object in the original Path
   message  (unless overridden by local policy) MUST also be updated
   with the In-Place bit set (1).  From this point on, Standard Path
   message processing is used in processing the resulting and original
   Path messages.

   The merge node of a dynamically controlled recovery LSP SHOULD reset
   (0) the In-Place bit in the PROTECTION object of the outgoing Path
   message associated with the terminated recovery LSP.

apparently make dynamic 'overlapping' segment protection impossible.

One scenario that came to my mind was node failure protection
envisioned to be implemented by recovery LSPs for the primary LSP
A-B-C-D-E-F-G, depicted as follows:

                  H ----- I   J ----- K
                 /         \ /         \
          A --- B --- C --- D --- E --- F --- G
           \         / \         / \         /
            L ----- M   N ----- O   P ----- Q

The specified rules apparently inhibit the setup of such overlapping
segment protection LSPs.  Has this been intended ?

It should say:

[see above]

Notes:

from pending
--VERIFIER NOTES--
This is not an Erratum. If there is technical discussion to be had about the function enabled or prohibited by the specification, and the requirements for the provision of services in a network, these need to be taken to the CCAMP mailing list and might result in a revision to the RFC or a new draft.

Errata ID: 945

Status: Rejected
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Rejected by: Adrian Farrel
Date Rejected: 2010-10-30

Section 7 says:

   This section presents the RSVP message related formats as modified by
   this document.  Where they differ, formats for unidirectional LSPs
   are presented separately from bidirectional LSPs.

It should say:

   This section presents the RSVP-TE message related formats as modified
   by this document.  Where they differ, formats for unidirectional LSPs
   are presented separately from bidirectional LSPs.

Notes:

Does not confine the scope of the specification as it
would be appropriate.

'Classic' RSVP (RFC 2205) is neither covered nor affected by the
subsequently specified (extended) message formats.

from pending
--VERIFIER NOTES--
Although it is true that there is some common distinction between "classic" RSVP and RSVP-TE, the IP protocol number is the same, and the message numbers (and registry) are the same. In essence, there is just one protocol with two uses.

Report New Errata



Search RFCs
Advanced Search
×