PCE Redundancy Extensions in Path Computation Element Communication Protocol (PCEP)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 14 April 2026.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

PCE redundancy case is very important and complicate scenario, as PCEP protocol doesn't support exchange of session information between PCEs.¶

2. Terminology

This document uses the following terms defined in [RFC5440]: PCC, PCE, PCEP Peer, and PCEP speaker.¶

The base PCEP specification [RFC4655] originally defined the use of the PCE architecture for MPLS and GMPLS networks with LSPs instantiated using the RSVP-TE signaling protocol. Over time, support for additional path setup types, such as SRv6, has been introduced [RFC9603]. The term "LSP" is used extensively in PCEP specifications and, in the context of this document, refers to a Candidate Path within an SR Policy, which may be an SRv6 path (still represented using the LSP Object as specified in [RFC8231].¶

3. PCEP Extensions

Let's consider simple configuration:¶

     +--------+        +--------+
     | PCE 1  |        | PCE 2  |
     +--------+        +--------+
         |                |
          |              |
           |            |
          +-------------+
          |     PCC     |
          +-------------+

     PCE1                PCC                          PCE2
     |                   |                             |
     | Active Session    | Active Session              |
     | PCE Init          | PCE Init                    |
     |------------------>|                             |
     | Terminated Session|                             |
     |                   |                             |
     |                   | Start del and state         |
     |                   | timers                      |
     |                   |                             |
     |                   | Del timer expired           |
     |                   |                             |
     |                   | Put LSPs (PCE1) as orphan   |
     |                   |<----------------------------|
     |                   | Take delegation LSPs (PCE1) |
     |                   |---------------------------->|
     |                   | State timer expired         |
     |                   | (internal)                  |
     |                   | Delete LSPs (PCE1)          |

• Note:

  PCE2 session can be created/exist in different states after or in parallel with PCE1 session and others.¶

  Only in the timeslot between expiration of the deletion timer and

  the state timer, PCE2 can take delegation.¶

Figure 2: PCE redundancy and take delegation timeslot¶

A PCE1 can instantiate LSPs on a PCC. When session between PCE1 and PCC is terminated, PCC starts delegation and state timers.¶

Once delegation timer is expired, all LSPs are changed to orphan. Once state timer is expired, all LSPs in orphan state are deleted by PCC.¶

PCE2 can take delegation of orphan LSPs only, but doesn't aware about timers of PCE1-PCC session.¶

This document specifies PCEP extensions to handle this situation in different scenarios:¶

Multiple parallel sessions in mode active-standby Multiple parallel sessions in mode active-active Sequential sessions (one session is terminated, then another session is established)¶

 +---------------+----------------------------------------------+
 |     Type      |               Length = 16                    |
 +---------------+----------------------------------------------+
 |                    IPv4 Delegation Address                   |
 +--------------------------------------------------------------+

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      Type     |               Length = 52                   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                             |
 +                 IPv6 Delegation Address                     +
 |                        (16 octets)                          |
 +                                                             +
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PCC SHALL send this TLV for any delegated LSP to all PCEs with
active
session in PCRpt message.

New NT (notification type) and NV (notification value) are required
for
 PCNtf:

  New NT - Delegation timeout
  New NV - TBD

New DELEGATION-TIMER-EXPIRATION TLV is required in Notification
(PCNtf)
 Message MUST be used for this new NT:

4. Operation

After receiving the PCNtf message with new NT,
the active PCE SHALL/MAY take delegation for all
LSPs that were delegated to this PCE (LSP with this IP
delegated address)

Here, maybe, new sub-TLV or new flag in PCInit message
will help: get all LSPs were delegated to specific IP
(like as PLSP ID = 0 in PCInit with remove flag message
means deletion for all PCE initiated LSPs):

5. Manageability Considerations

All manageability requirements and considerations listed in [RFC5440], [RFC8231], and [RFC9604] apply to the PCEP extensions defined in this document.¶

A PCE or PCC implementation MAY allow the capability of supporting
PCEP extensions introduced in this document to be enabled/disabled
as
part of the global configuration.  An implementation SHOULD allow
the
operator to view the advertised and received capabilities.

6. Security Considerations

The security considerations described in [RFC5440], [RFC8231], and [RFC9604] are applicable to this document. No additional security measures are required.¶

7. IANA Considerations

IANA maintains a registry, named "STATEFUL-PCE-CAPABILITY TLV Flag
Field", within the "Path Computation Element Protocol (PCEP)
Numbers"
registry group.  IANA is requested to make the following assignment:

       +------+--------------------------------+---------------+
       | N    | Description                    | Reference     |
       +------+--------------------------------+---------------+
       | TBD2 | IPv4 delegation address        | This document |
       +------+--------------------------------+---------------+
       | TBD3 | IPv6 delegation address        | This document |
       +------+--------------------------------+---------------+
                               Table 2

       +------+--------------------------------+---------------+
       | N    | Description                    | Reference     |
       +------+--------------------------------+---------------+
       | TBD4 | PCE address (was owner) IPv4   | This document |
       +------+--------------------------------+---------------+
       | TBD5 | PCE address (was owner) IPv6   | This document |
       +------+--------------------------------+---------------+
       | TBD6 | Delegation timeoutr            | This document |
       +------+--------------------------------+---------------+
                               Table 3

Appendix A. Acknowledgements

Author's Address