Local Protection Enforcement in the Path Computation Element Communication Protocol (PCEP)
updates
- rfc-5440 — Path Computation Element (PCE) Communication Protocol (PCEP)
Extracted elements (14)
The L flag is a single boolean bit and cannot distinguish between PROTECTION MANDATORY, UNPROTECTED MANDATORY, PROTECTION PREFERRED, and UNPROTECTED PREFERRED — all of which are needed to enforce different SLA policies on LSPs sharing the same topology. This limitation motivates the introduction of the E flag.
The Local Protection Desired (L) flag in PCEP's LSPA object originated in RSVP-TE, where it signals to downstream routers that they may use local repair, but does not require them to do so. Different PCEP implementations interpreted the L flag as either PROTECTION MANDATORY or PROTECTION PREFERRED, creating operational inconsistencies that this document resolves.
UNPROTECTED MANDATORY is motivated by scenarios where an LSP is protected via a diverse secondary LSP; if local protection is invoked on the primary LSP upon failure, traffic may temporarily traverse links violating TE requirements (e.g., insufficient bandwidth), making it preferable to tear down the LSP immediately and switch to the pre-engineered secondary path.
A PCC or PCE that does not support this document ignores the E flag and treats it as 0 in PCRpt and PCUpd messages per RFC 5440 (PCC-initiated LSPs) or RFC 8281 (PCE-initiated LSPs). A legacy PCE will therefore not enforce the protection constraint even if the PCC sets E=1.
For PCC-initiated LSPs, the E flag in a PCUpd message from a legacy PCE is always 0 (echoed from PCRpt but the bit is ignored), so a supporting PCC SHOULD ignore the E flag value received from the PCE in a PCUpd message to avoid misinterpreting legacy behavior.
For PCE-initiated LSPs, the PCC MAY process the E flag from the PCE's PCUpd message, and the PCE SHOULD ignore the E flag from the PCC's PCRpt message, since either peer may not yet support this document.
If a PCE cannot infer the protection status of a resource, it MAY use local policy. For Segment Routing paths, it is RECOMMENDED that a PCE assume a Node SID is protected, and that an Adjacency SID is protected if the backup flag advertised with the Adjacency SID is set.
When both the L flag and E flag are set to 0, the PCE SHOULD consider the protection eligibility as UNPROTECTED PREFERRED but MAY treat it as UNPROTECTED MANDATORY, for example when the PCE detects (via out-of-band means) that it is interacting with a legacy PCC expecting legacy behavior.
When the L flag is set to 0 and the E flag is set to 1, the PCE MUST consider the protection eligibility as an UNPROTECTED MANDATORY constraint — no links in the path may have protection eligibility.
When the L flag is set to 1 and the E flag is set to 0, the PCE MUST consider the protection eligibility as a PROTECTION PREFERRED constraint — protection is desired but not strictly enforced.
The Protection Enforcement (E) flag is defined as bit 6 in the Flags field of the LSPA object, adjacent to the existing Local Protection Desired (L) flag at bit 7. Together, the two bits encode four protection constraint modes: PROTECTION MANDATORY, PROTECTION PREFERRED, UNPROTECTED PREFERRED, and UNPROTECTED MANDATORY.
IANA allocated bit 6 in the 'LSPA Object Flag Field' subregistry of the 'Path Computation Element Protocol (PCEP) Numbers' registry, with description 'Protection Enforcement' and reference RFC 9488.
The E flag introduces no new sensitive information and requires no additional security measures beyond those already applicable to PCEP. Securing the PCEP session using TLS per RFC 8253 and the best current practices in RFC 9325 is RECOMMENDED.
The LSPA object Flags field is 8 bits wide. Bit 7 is the L (Local Protection Desired) flag from RFC 5440; bit 6 is the new E (Protection Enforcement) flag defined by this document. Remaining bits are reserved. The LSPA object also contains 32-bit Exclude-any, Include-any, and Include-all fields, plus 8-bit Setup Priority and Holding Priority fields.