RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (2)

RFC 8231, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", September 2017

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: 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.

Status: Reported (1)

RFC 8231, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", September 2017

Source of RFC: pce (rtg)

Errata ID: 5796
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Hillol
Date Reported: 2019-07-29

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.

Report New Errata