PCE

Summary

The Path Computation Element (PCE) Working Group met at IETF 126 to discuss the status of its active documents, progress several key technical drafts, and evaluate new proposals. The WG has published 77 RFCs to date, has 6 documents currently in the IESG hands, and maintains 16 active working group documents. Key discussions focused on operational clarifications, stateful PCE amendments, performance measurement extensions, Segment Routing Point-to-Multipoint (SR P2MP) policies, Network Resource Partition (NRP) extensions, and new security profiles.

Key Discussion Points

1. Introduction

Presenter: Julien Meuric & Dhruv Dhody
Slides: 1. Introduction
Discussion:
- WG Status: Julien Meuric highlighted recent publications and active document statuses. draft-ietf-pce-pcep-secure-tls has been published. Three documents are in the RFC Editor Queue, and three are with the AD.
- Adoption Queue: Dhruv Dhody outlined the priority queue. draft-ietf-pce-sr-p2mp-policy is currently in Working Group Last Call (WGLC). The chairs plan to progress draft-ietf-pce-entropy-label-position to last call next, while draft-ietf-pce-sr-path-segment is waiting on the resolution of SPRING dependencies. draft-ietf-pce-pcep-extension-pce-controller-p2mp is also slated to progress soon.
- Cross-WG Coordination: Susan Hares raised questions on coordinating P2MP policy work between PCE, IDR, and BESS. Ketan Talaulikar (AD) advised that protocol extensions should align with the base SPRING/PIM specifications, and coordinating progress between working groups is a task for the chairs.

2.1 Operational Clarification

Presenter: Andrew Stone
Slides: 2.1 Operational Clarification
Draft: draft-ietf-pce-operational
Discussion:
- Andrew Stone presented updates incorporating comments from Adrian Farrel.
- New text was added to clarify handling PCE overload states: implementations should continue to send report messages to keep the PCE informed of LSP state changes, but should throttle reporting frequency where possible based on local policy.
- Julien Meuric suggested adding text addressing other message types under overload conditions (e.g., performance monitoring or auto-bandwidth).
- Dhruv Dhody reminded the WG that this document is strictly for clarification, not protocol updates (amendments), and noted that they need to discuss with the AD how the IESG will interpret this kind of document.

2.2 Stateful Amendment

Presenter: Andrew Stone
Slides: 2.2 Stateful Amendment
Discussion:
- This draft was forked from the operational draft to house actual protocol updates/amendments.
- Focuses on three areas: stateful LSP bring-up (skipping PC requests), discouraging the use of SR-EROs and SRv6-EROs, and handling orphan LSPs by discouraging delegation requests and relying on PCC re-delegation.
- Julien Meuric suggested clarifying the PCE's behavior when PC updates are sent without a preceding request (noting that the PCE can stay quiet and not respond, which must be clearly documented). Andrew agreed to add this clarification. The authors are seeking WG adoption.

2.3 Performance Metrics

Presenter: Rakesh Gandhi
Slides: 2.3 Performance Metrics
Discussion:
- The draft defines PCEP extensions for PM in SR and MPLS TE LSPs. The major delta is using notification messages instead of report messages to report measurements, which helps optimize processing by omitting EROs/RROs.
- Lei Zheng asked for clarification on the "R" flag (loopback delay measurement). Rakesh Gandhi explained that it uses STAMP timestamps to calculate delay when remote timestamps are unavailable.
- Dhruv Dhody suggested adding a reference to the SR PM draft.
- Chenqiang An suggested adding references to existing IGP metric definitions (e.g., RFC 7471) to ensure consistent terminology (e.g., unidirectional vs. one-way delay).
- Session Polls:
  - Poll 1: Have you read the PM I-D? — yes: 8, no: 8, no_opinion: 0 (total: 29)
  - Poll 2: Do you think the PM I-D is ready for WG adoption? — yes: 8, no: 1, no_opinion: 6 (total: 32)
- Julien Meuric concluded there is positive interest and the chairs will initiate an adoption call on the mailing list once the draft receives more exposure.

3.1 SR P2MP Policy

Presenter: Hooman Bidgoli
Slides: 3.1 SR P2MP Policy
Draft: draft-ietf-pce-sr-p2mp-policy
Discussion:
- The presenter clarified that the current draft only covers MPLS encapsulation; a separate draft will be introduced for SRv6.
- Changes between v14 and v19 include updated error handling (new IANA error types), incorporating multipath backup behavior, updating the CCI object for PCUpdate messages, and editorial updates.
- Susan Hares highlighted concerns regarding interactions between BGP tunnel encapsulation (RFC 9012) and the BEST multicast controller draft, emphasizing the need for clear error handling when both BGP and PCEP mechanisms are deployed.
- Dhruv Dhody requested that WG members review the message flow diagrams in the appendix during the ongoing WGLC to ensure the new pictorial format is useful.
- Zafar Ali requested offline coordination regarding the Fast Reroute (FRR) discussion in Section 4.3.6.

3.2 Binding Label/SID Extensions

Presenter: Samuel Sidor
Slides: 3.2 Binding Label/SID Extensions
Discussion:
- The draft addresses fallback behaviors when binding label/SID allocation conflicts occur (which is currently undefined in PCEP).
- Two behaviors are proposed: (1) keeping the LSP in a DOWN state during a conflict, or (2) falling back to a local allocation on the PCC and reporting both the requested and allocated values back to the PCE.
- Recent updates resolved capability flag naming confusion, defined TLV ordering, and added new error codes. The authors requested WG adoption.

4.1 Extensions for Network Resource Partition (NRP)

Presenter: Lei Zheng
Slides: 4.1 Extensions for Network Resource Partition (NRP)
Draft: draft-ietf-pce-pcep-nrp
Discussion:
- Version 01 renamed the NRP TLV to "NRP-ID TLV" to align with BGP and updated terminology to align with TEAS WG definitions.
- Zafar Ali and Jie Dong discussed dependencies with SPRING’s SR Policy NRP work, suggesting it be added as an informative reference.
- Dhruv Dhody advised the authors to resolve existing IESG comments on other NRP drafts and recommended being more technically concrete on what "NRP-aware path computation" means (e.g., node/link filtering, resource allocation) instead of using generic "should" statements.

4.2 Path Delay Difference

Presenter: Yao Liu
Slides: 4.2 Path Delay Difference
Discussion:
- The draft proposes a new "multipath delay difference" metric to limit the latency difference among multiple paths or branches of a single PCEP LSP (useful for load balancing and P2MP receivers).
- Andrew Stone questioned the multicast use case, noting that optimizing for shortest-delay routing generally solves this naturally. Rejecting a path due to a strict delay difference constraint could lead to total service loss, which is operationally worse than slightly delayed delivery.
- Hooman Bidgoli noted that multicast optimization must be run by the PIM WG, stating that modifying individual sub-branches is highly complex and can trigger traffic disruptions during live events.
- Dhruv Dhody suggested focusing on a single, strong use case rather than overcomplicating the draft.

4.3 Extensions for Computing-Aware Traffic Steering (CATS)

Presenter: Chenqiang An
Slides: 4.3 Extensions for Computing-Aware Traffic Steering
Discussion:
- Introduces PCEP extensions to support the CATS framework where the Path Computation Element acts as a CATS Path Selector (C-PS).
- The C-PS must first select the egress CATS forwarder and then compute the network path based on both network and computing metrics. The draft proposes a new computing metric type, CSID TLV, and CS-Instance-ID TLV.
- Next steps include aligning the proposed parameters closely with the CATS WG.

4.4 Precision Availability Metrics (PAM)

Presenter: Christian
Slides: 4.4 Precision Availability Metrics
Discussion:
- Based on feedback from previous meetings, the authors changed their approach. Instead of defining a dedicated PAM metric object, they now propose reusing the existing Objective Function (OF) framework (RFC 5541).
- The draft defines three PAM-oriented objective functions: compliance against PAM, minimum violated intervals, and minimum severely violated intervals.
- The presenter asked for feedback on this new design direction before refining the draft further.

4.5 Implicit TLS in PCEP

Presenter: Zafar Ali
Slides: 4.5 Implicit TLS in PCEP
Discussion:
- In scenarios where both peers are pre-configured via policy to use TLS, sending the initial StartTLS message in clear text introduces potential security risks.
- The draft proposes "implicit TLS" where the TLS handshake is initiated immediately over the existing TCP port, simplifying the PCEP state machine. No new TCP ports are requested.
- Dhruv Dhody urged caution, reminding the WG that the security area strongly recommended the StartTLS approach when RFC 8253 was developed. He advised engaging the Security Directorate early to avoid major blockages later.
- Hooman Bidgoli supported the implicit TLS concept, noting that other transport protocols (like RADIUS and TACACS) use implicit TLS over TCP from the outset rather than in-band negotiation.

Decisions and Action Items

Action Item: Andrew Stone to send Ketan Talaulikar (AD) an email request to initiate early feedback/review on draft-ietf-pce-operational.
Action Item: Authors of draft-ietf-pce-pcep-nrp to review recent IESG comments on other NRP-related documents and refine the technical description of "NRP-aware path computation."
Decision: The chairs will launch a mailing list adoption call for the Performance Measurement (PM) draft.

Next Steps

SR P2MP Policy: WG members are encouraged to review draft-ietf-pce-sr-p2mp-policy and provide feedback on the list (specifically regarding the appendix's flow diagrams and the FRR sections) during the ongoing WGLC.
Stateful Amendment: Authors will update the Stateful Amendment draft to clarify PCE behavior when PC updates are received without a preceding request.
Security Coordination: Authors of the Implicit TLS proposal will initiate early discussions with the IETF Security Area to evaluate the deployment profile.

Automatic IETF Minutes

PCE