RFC Errata
Found 8 records.
Status: Verified (6)
RFC 8231, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", September 2017
Note: This RFC has been updated by RFC 8786, RFC 9353
Source of RFC: pce (rtg)
Errata ID: 5376
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Hari Krushna Kotni
Date Reported: 2018-06-01
Verifier Name: Deborah Brungard
Date Verified: 2018-06-05
Section 7.2 says:
In case of SRP-ID-number wrapping, the last SRP-ID-number before the wrapping MUST be explicitly acknowledged, to avoid a situation where SRP-ID-numbers remain unacknowledged after the wrap. This means that the PCC may need to issue two PCUpd messages on detecting a wrap.
It should say:
In case of SRP-ID-number wrapping, the last SRP-ID-number before the wrapping MUST be explicitly acknowledged, to avoid a situation where SRP-ID-numbers remain unacknowledged after the wrap. This means that the PCC may need to issue two PCRpt messages on detecting a wrap.
Notes:
incase of srp id wrap, once PCC detects it, PCC needs to issue PCRpt message not PCUpd message.
Errata ID: 5970
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Subham Burnwal
Date Reported: 2020-01-31
Verifier Name: Deborah Brungard
Date Verified: 2020-07-13
Section 8.5 says:
19 Invalid Operation
Error-value
1: Attempted LSP Update Request for a non-delegated
LSP. The PCEP-ERROR object is followed by the LSP
object that identifies the LSP.
It should say:
19 Invalid Operation
Error-value
1: Attempted LSP Update Request for a non-delegated
LSP.
Notes:
RFC 8231 Section 6.3 - LSP Object is not part of PCErr message.
Errata ID: 6231
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dhruv Dhody
Date Reported: 2020-07-13
Verifier Name: Deborah Brungard
Date Verified: 2020-09-29
Section 8.5 says:
20 LSP State Synchronization Error
Error-value
1: A PCE indicates to a PCC that it cannot process (an
otherwise valid) LSP State Report. The PCEP-ERROR
object is followed by the LSP object that
identifies the LSP.
It should say:
20 LSP State Synchronization Error
Error-value
1: A PCE indicates to a PCC that it cannot process (an
otherwise valid) LSP State Report.
Notes:
This is a companion errata to https://www.rfc-editor.org/errata/eid5970 which identified the issue in Error-type 19 Error-value 1. The same issue exists for Error-type 20 Error-value 1 i.e. LSP Object is not part of the PCErr message.
Errata ID: 6289
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dhruv Dhody
Date Reported: 2020-09-14
Verifier Name: Deborah Brungard
Date Verified: 2020-09-29
Section 7.3.2 says:
Length (16 bits): indicates the total length of the TLV in octets and MUST be greater than 0. The TLV MUST be zero-padded so that the TLV is 4-octet aligned.
It should say:
Length (16 bits): indicates the length of the value portion of the TLV in octets and MUST be greater than 0. The TLV MUST be zero- padded so that the TLV is 4-octet aligned.
Notes:
The "total length of the TLV" is incorrect, as in PCEP the TLV formatting is as per RFC 5440 which requires the length to be of the value portion only. The other text such as "MUST be greater than 0", the padding rules along with "without a NULL terminator" also point to the fact that the intention of the authors/WG was not "total" (and it is simply a mistake).
Errata ID: 5492
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Upendra Singh
Date Reported: 2018-09-05
Verifier Name: Deborah Brungard
Date Verified: 2019-02-11
Section 6.1 says:
Under section 6.1, PCRpt message is defined.
In definition of path,
Where:
<path>::= <intended-path>
[<actual-attribute-list><actual-path>]
<intended-attribute-list>
It should say:
Where:
<path>::= <intended-path>
[<actual-attribute-list><actual-path>]
[<intended-attribute-list>]
Notes:
The change aligns the RBNF with the following text in the document (section 6.1) -
Note that the intended-attribute-list is optional and
thus may be omitted.
Errata ID: 6012
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dhruv Dhody
Date Reported: 2020-03-10
Verifier Name: Deborah Brungard
Date Verified: 2020-07-13
Section 5.8.3 says:
If the PCC receives a PCUpd message for an LSP object identified with a PLSP-ID that does not exist on the PCC, it MUST generate a PCErr with Error-type=19 (Invalid Operation), error-value 3, (Attempted LSP Update Request for an LSP identified by an unknown PSP-ID) (see Section 8.5).
It should say:
If the PCC receives a PCUpd message for an LSP object identified with a PLSP-ID that does not exist on the PCC, it MUST generate a PCErr with Error-type=19 (Invalid Operation), error-value 3, (Attempted LSP Update Request for an LSP identified by an unknown PLSP-ID) (see Section 8.5).
Notes:
s/PSP-ID/PLSP-ID/
Thanks to Rebecca Vanrheenen from RFC Editor team for spotting this while editing another I-D.
Status: Held for Document Update (1)
RFC 8231, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", September 2017
Note: This RFC has been updated by RFC 8786, RFC 9353
Source of RFC: pce (rtg)
Errata ID: 5796
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Hillol
Date Reported: 2019-07-29
Held for Document Update by: Deborah Brungard
Date Held: 2020-07-13
Section 7.3.3 says:
Value Description
----- -------------------------------------
1 Unknown reason
2 Limit reached for PCE-controlled LSPs
3 Too many pending LSP Update Requests
4 Unacceptable parameters
5 Internal error
6 LSP administratively brought down
7 LSP preempted
8 RSVP signaling error
It should say:
Remove Value 2 2 Limit reached for PCE-controlled LSPs
Notes:
Value 2 "Limit reached for PCE-controlled LSPs" can occur when an PC update message comes for either PCInitiated or PCDelegated LSP. But since the lsp is already created or delegated, it means the resource is available and allocated. Also RFC 8281 (section 5.3) states that if LSP provisioned exceeds the limit, an LSP error message should be sent with Error-type=19 (Invalid Operation) and
Error-value=6 (PCE-initiated LSP limit reached). So, I believe there is no scenario where LSP Error code TLV "Limit reached for PCE-controlled LSPs" would be used.
Please let me know if there is some scenario which can trigger the same.
Status: Rejected (1)
RFC 8231, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", September 2017
Note: This RFC has been updated by RFC 8786, RFC 9353
Source of RFC: pce (rtg)
Errata ID: 6627
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Oscar Gonzalez de Dios
Date Reported: 2021-07-01
Rejected by: John Scudder
Date Rejected: 2021-10-06
Section 6.4 says:
<request>::= <RP>
<END-POINTS>
[<LSP>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
It should say:
<request>::= <RP>
<END-POINTS>
[<LSP>]
[<CLASSTYPE>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
Notes:
RFC 5455 defines the CLASSTYPE object and specifies that the CLASSTYPE object MUST
be inserted after the END-POINT objects. RFC 8231 defines the LSP object and specifies that the LSP object MUST be inserted after the END-POINTS object. Hence, it is not clear if CLASSTYPE or LSP goes after END-POINTS. Hence, to disambiguate and avoid interoperability issues, the proposal is to include the CLASSTYPE object in the updated grammar. The order would be <END-POINTS>[<LSP>][<CLASSTYPE>]
--VERIFIER NOTES--
See also the mail thread at https://mailarchive.ietf.org/arch/msg/pce/UmqIZSDtRqe7yC5v0wHU64mrGuI/ for more discussion and detail.
In https://mailarchive.ietf.org/arch/msg/pce/VUM5GymISrBiPgoUEVH8IkaM3tU/, the AD at the time (Adrian) rejected erratum 3672, which is similar to this one in that it complains about ambiguous ordering and asks for a fix. Adrian ends his rejection comment with
“In rejecting this Errata report I note that the reported error is not a typo,
but a deliberate decision of the authors and working group. The fix, therefore,
if it is to be applied needs to be achieved through a consensus document.”
AFAICT this reasoning applies equally in the current case. Actually, it applies even more so, because the WG was offered draft-cmfg-pce-pcep-grammar-02 and didn’t do anything with it, which implies no consensus was demonstrated to go forward with a solution to the identified problem.
Therefore, I'm also rejecting this erratum. The right way forward is for the WG to take on this problem.