RFC Errata
Found 9 records.
Status: Verified (6)
RFC 4872, "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", May 2007
Note: This RFC has been updated by RFC 4873, RFC 6780, RFC 9270
Source of RFC: ccamp (rtg)
Errata ID: 928
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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)
RFC 4872, "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", May 2007
Note: This RFC has been updated by RFC 4873, RFC 6780, RFC 9270
Source of RFC: ccamp (rtg)
Errata ID: 932
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
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)
RFC 4872, "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", May 2007
Note: This RFC has been updated by RFC 4873, RFC 6780, RFC 9270
Source of RFC: ccamp (rtg)
Errata ID: 934
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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.