errata logo graphic

Found 9 records.

Status: Verified (6)

RFC4872, "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", May 2007

Source of RFC: ccamp (rtg)

Errata ID: 928

Status: Verified
Type: Editorial

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

Section 14.1 says:

[[Within the explanations for the PROTECTION Object, on mid-page 32]]

Reserved: 5 bits

It should say:

Reserved: 6 bits

Notes:

See the artwork of the object on page 31 and count the bits.

from pending


Errata ID: 929

Status: Verified
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-05-07
Verifier Name: RFC Editor
Date Verified: 2007-11-02

Section 15.1 says:

   The primary path route is specified via the PRIMARY_PATH_ROUTE object
   (PPRO).  The Primary Path Route Class Number (Class-Num) of form
   0bbbbbbb 38.

It should say:

   The primary path route is specified via the PRIMARY_PATH_ROUTE object
   (PPRO).  The Primary Path Route Class Number (Class-Num) of form
   0bbbbbbb is 38.
       
or even:

   The primary path route is specified via the PRIMARY_PATH_ROUTE object
   (PPRO).  The Primary Path Route Class Number (Class-Num) of form
   0bbbbbbb assigned by IANA is 38.

Notes:

Missing verb.

from pending


Errata ID: 930

Status: Verified
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-05-07
Verifier Name: RFC Editor
Date Verified: 2007-11-02

Section 15.1 says:

   The contents of a PRIMARY_PATH_ROUTE object are a series of
   variable-length data items called subobjects (see Section 15.3).

It should say:

   The contents of a PRIMARY_PATH_ROUTE object are a series of
   variable-length data items called subobjects (see Section 15.2).

Notes:

Referred to wrong section. 15.3 --> 15.2

from pending


Errata ID: 931

Status: Verified
Type: Editorial

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

Section 15.2 says:

   An empty PPRO with no subobjects is considered illegal.  If there is
   no first subobject, the corresponding Path message is also in error,
   and the receiving node SHOULD return a PathErr message with the new
   error code/sub-code "Routing Problem/Bad PRIMARY_PATH_ROUTE object".

It should say:

   An empty PPRO has no subobjects and is considered illegal.  A node
   receiving a Path message containing an empty PPRO SHOULD return a
   PathErr message with the new error code/sub-code "Routing Problem/
   Bad PRIMARY_PATH_ROUTE object".

Notes:

The original problem report said...

According to the text, PPROs are only admitted in Path messages.
PPROs "with no first subobject" carry no subobjects at all.
It is unclear why the text tries to distinguish these 'too cases'
and uses the word, "also", in the second sentence.

Something significant might have been lost in the text,
which cannot be concluded from the context.
In this case, please supply the missing clues.
Otherwise, the RFC should read unambiguously as supplied above.

...and proposed the text...

An empty PPRO with no subobjects is considered illegal. A node
receiving an empty PPRO SHOULD return a PathErr message with the new
error code/sub-code "Routing Problem/Bad PRIMARY_PATH_ROUTE object".

This proposal is rejected in favor of the corrected text because it lost some of the meaning.


Errata ID: 933

Status: Verified
Type: Editorial

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

Section 16.2 says:

   Similarly, terminating nodes receiving a Path message with a
   PROTECTION object requiring association between working and recovery
   LSPs MUST include an ASSOCIATION object.  Otherwise, such nodes MUST
   return a PathErr message with the new error code/sub-code "Routing
   Problem/PROTECTION object not Applicable".

It should say:

   Similarly, a Path message with a PROTECTION object requiring
   association between working and recovery LSPs MUST include an
   ASSOCIATION object.  Terminating nodes receiving such Path message
   without an ASSOCIATION object MUST return a PathErr message with the
   new error code/sub-code "Routing Problem/PROTECTION object not
   Applicable".

Errata ID: 1935

Status: Verified
Type: Editorial

Reported By: Vishwas Manral
Date Reported: 2009-10-29
Verifier Name: Adrian Farrel
Date Verified: 2009-10-30

Section 15.3 says:

   - PRROs SHOULD be present in the Path message for the pre-
     provisioning of the secondary protecting LSP to enable recovery
     resource sharing between one or more secondary protecting LSPs (see
     Section 15.4).

It should say:

   - PPROs SHOULD be present in the Path message for the pre-
     provisioning of the secondary protecting LSP to enable recovery
     resource sharing between one or more secondary protecting LSPs (see
     Section 15.4).

Notes:

Second bullet point in the section.
s/PRRO/PPRO/


Status: Held for Document Update (1)

RFC4872, "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", May 2007

Source of RFC: ccamp (rtg)

Errata ID: 932

Status: Held for Document Update
Type: Editorial

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

Section 16 says:

   The ASSOCIATION object is used to associate LSPs with each other.

It should say:

[not submitted]

Notes:

The second paragraph of Section 16 is a literal restatement of the
first sentence of the same section, on the same page (37).
Therefore, the last text line of Section 16 (above), should be deleted.


Status: Rejected (2)

RFC4872, "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", May 2007

Source of RFC: ccamp (rtg)

Errata ID: 934

Status: Rejected
Type: Technical

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

Section 17 says:

   This section presents the RSVP message-related formats as modified by
   this document.  Unmodified RSVP message formats are not listed.

It should say:

   This section presents the RSVP-TE message-related formats as modified
   by this document.  Unmodified RSVP-TE message formats are not listed.

Notes:

The first paragraph of Section 17 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 message formats.

from pending
--VERIFIER NOTES--
Compare with Erratum 945.

Same reason for rejection...

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.


Errata ID: 3304

Status: Rejected
Type: Technical

Reported By: Lyndon Ong
Date Reported: 2012-07-31
Rejected by: Adrian Farrel
Date Rejected: 2012-08-09

Section 11 & 12 says:

Section 11 says:


   (Full) LSP rerouting will be initiated by the head-end node that has
   either detected the LSP failure or received a Notify message and/or a
   PathErr message with the new error code/sub-code "Notify Error/LSP
   Locally Failed" for this LSP.  The new LSP resources can be
   established using the make-before-break mechanism, where the new LSP
   is set up before the old LSP is torn down.  This is done by using the
   mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit
   (SE) reservation style (see [RFC3209]).  Both the new and old LSPs
   can share resources at common nodes.

Section 12 says:

   [No text on reversion for (full) LSP Rerouting.]

It should say:

Section 11 should say:


   (Full) LSP rerouting will be initiated by the head-end node that has
   either detected the LSP failure or received a Notify message and/or a
   PathErr message with the new error code/sub-code "Notify Error/LSP
   Locally Failed" for this LSP.  The new LSP resources can be
   established using the make-before-break mechanism, where the new LSP
   is set up before the old LSP is torn down.  This is done by using the
   mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit
   (SE) reservation style (see [RFC3209]).  Both the new and old LSPs
   can share resources at common nodes.  The new LSP can be established
   without tearing down the old LSP in case of reversion (see section 12).

Section 12 should say:

   For "(full) LSP Rerouting", reversion implies that the old LSP is not 
   torn down by the head-end node after the new LSP is established. For
   reversion, the head-end node re-activates the old LSP after this has
   recovered.


Notes:

Current text in RFC 4872 describes reversion in the cases of 1+1 bidirectional Protection, 1:N Protection with Extra Traffic and Rerouting Without Extra Traffic, however it has no description of reversion with (Full) LSP Rerouting.
For (full) LSP Rerouting, the description in Section 11 instead implies that the old LSP is torn down. This has led to some confusion as to whether reversion with (full) LSP Rerouting is allowed or not allowed by the RFC. We believe this was not intentional. The additions would make it clear that reversion can be supported with (Full) LSP Rerouting.
--VERIFIER NOTES--
After discussions on the CCAMP mailing list it is the general opinion of the CCAMP WG that there is no technical issue and that if any WG participants wish to document how the current mechanisms can be used to support a particular usage/application that they are free to do so in a new informational draft.


Report New Errata