IETF moves PCE state sync to Experimental for three-node test

Three PCEs, Different Maps: IETF Puts State Sync on Trial

Why it matters

The IETF's new PCE state-sync draft has changed its label from Standards Track to Experimental. Its reason is concrete: when three path controllers lose a session, each may see a different set of reachable peers. No implementation is listed to settle the question in running networks.

Daniel Kade3 November 2026 at 18:54 UTCReading Time 2 minLast update: 3 November 2026

A broken link in a three-controller synchronization mesh illustrates the split-view question in IETF PCE state-sync revision 16. Conceptual editorial image.

Summary

The IETF's 11 June revision 15 said Standards Track. The 2 November revision 16 says Experimental and reports no known implementations.
The proposed full mesh shares label-switched-path state among path computation elements (PCEs). With three or more PCEs, each cannot see sessions between its peers. A broken session can leave different controllers choosing different computing PCEs for related paths, with less optimal results.

A network operator can hand separate label-switched paths to several path computation elements, or PCEs. RFC 8231 lets a path computation client (PCC) report path state to a stateful PCE and delegate control of one path. The new IETF draft goes a step further: PCEs exchange that state directly, so a controller can compute across dependent paths or take over when a PCC-to-PCE connection fails. The participating PCEs must form a full mesh of state-sync sessions.

That mesh has a blind corner. The 2 November draft says a PCE can see its own sessions but cannot directly observe a session between two other PCEs. With two controllers the views align. With three or more, a failure can make their lists of reachable peers differ for a while. A delegated PCE chooses a computing peer according to priorities configured by the operator; those priorities are not advertised by the protocol. Related paths in one association group may then land with different computing PCEs. The draft's one-step sub-delegation and forwarding rules prevent a computation loop, while the grouped calculation can become less optimal.

Revision 16 makes this uncertainty the point of the document. Revision 15 carried Intended status: Standards Track; the new title page reads Experimental. Section 6 says no implementations are known at posting. The experiment asks whether locally configured priorities suffice beyond two PCEs or whether the protocol must advertise priorities and specify an explicit role change. As checked on 4 November, the IETF document record still displays Intended RFC status: Proposed Standard and AD Evaluation::Revised I-D Needed alongside revision 16. The draft text and tracker metadata currently describe different intended statuses.

The published text has no implementation trace, three-PCE failure test or measured service effect. A multi-controller trial with session loss, priority changes and path-group outcomes would answer the draft's own question.