Summary

  • RFC 9757 can coordinate BGP session setup, explicit peer routes, prefix advertisements and Raw or Tunnel forwarding through PCEP, but a valid PCInitiate records controller intent and a PCRpt records bounded PCC testimony.
  • The operational proof chain must continue through controller authority, synchronization, bilateral BGP identity, policy acceptance, RIB/FIB installation, packet canaries, ordered recovery and verified cleanup.

A controller can receive a perfect row of acknowledgements while the service remains unproved. One router says it processed the peer instruction. Three more report their explicit routes. Two edge devices say they sent the prefixes. Every message carries the expected path name and controller identifier. The screen turns green. Yet no record in that sequence necessarily shows that the far BGP speaker accepted the route, that every forwarding table contains the intended next hop, that the transition was loop-free, or that a packet crossed the path.

RFC 9757 makes that gap unusually important because it extends a controller protocol into the ordinary machinery of a Native IP network. Published as an Experimental IETF document, it applies PCE-as-a-Central-Controller to paths built from BGP sessions, host routes and prefix announcements. The RFC Editor record and Datatracker record establish the document's identity and status. The RFC itself asks for implementation and deployment feedback on operational impact, scalability and stability. That is a boundary, not fine print: allocated objects and normative procedures do not establish adoption or operating success.

Three instructions, one path name, several truths

The mechanism reuses PCInitiate and PCRpt. For a Native IP instruction, PCInitiate carries an SRP object, an LSP object, a Central Controller Instruction of Object-Type 2, and exactly one of three new objects. BPI describes the BGP peer. EPR describes a host route toward that peer. PPA describes prefixes to advertise to it. A Symbolic Path Name ties related instructions to one end-to-end path; a CC-ID distinguishes a controller instruction within the PCEP session.

This is strong correlation, not atomic execution. One path can require different objects at different devices, and each device reports only the work assigned to it. The PCRpt format can acknowledge an instruction or participate in state synchronization. It cannot become an independent witness merely because it repeats the same object. A PCC is reporting what its PCEP and local control modules believe they processed.

The distinction starts before any instruction. Both PCEP speakers must advertise Path Setup Type 4 and the Native-IP capability bit. Inconsistent negotiation produces defined errors and session termination. This protects protocol use from silent capability mismatch. It does not prove that the PCE has current topology, the right organizational mandate, the complete set of PCCs or a safe change window. RFC 9757's security section calls for PCE authentication and protected PCEP communication. Operations must still retain the authenticated controller identity, authorization scope, decision owner and epoch.

A cryptographically protected command can be precisely attributable and still be wrong, stale or out of scope.

BGP establishment needs two witnesses

The BGP Peer Info object carries peer AS, local and peer addresses, EBGP TTL, a status/error field and the T bit that selects forwarding strategy. The addresses must be dedicated to this Native IP use rather than shared with a manually established session. A receiving PCC should try to establish the session and report progress, establishment or failure.

The key word is report. RFC 9757 does not change the BGP finite-state machine defined by RFC 4271. It sends selected setup parameters toward the local BGP module; many other values come from defaults. A BPI status of “established” is useful evidence from one device. It is not, by itself, a bilateral session record. The operating receipt should join both endpoints' local and remote addresses, AS numbers, AFI/SAFI, transport protection, policy instance, router identity, session generation and establishment times. Otherwise a stale session, an unexpected default or the wrong peer can occupy the same reassuring label.

RFC 8821 supplies the larger CCDR architecture in which multiple BGP sessions help create Native IP path choice. That architectural objective does not collapse BGP import and export policy. When a PPA tells an edge PCC to advertise prefixes to a named peer, RFC 9757 requires a report after the PCC has successfully sent them. “Sent” stops at the local side of the exchange. It does not prove transport delivery, the peer's Adj-RIB-In, route-policy acceptance, best-path selection, onward advertisement or use in forwarding. For consequential changes, retain the outgoing update identity, the receiving peer's evidence, the exact policy revision, the resulting Loc-RIB choice and the FIB entry that traffic will actually encounter.

A route acknowledgement is not a line-card read

EPR is the bridge between peer setup and reachability. It installs host routes toward peer addresses, normally above dynamically learned IGP routes and below manually or otherwise statically configured routes. The PCC must verify that the next hop is reachable. The PCE must add EPR state in reverse end-to-end path order to avoid a transient loop, remove it in forward order, and install an updated next hop before deleting the old instruction.

Those ordering rules are an operational control surface. A controller log should therefore preserve a path version, per-device dependency order, dispatch and acknowledgement times, next-hop resolution and the point at which old state was removed. A success PCRpt can show that the PCC accepted or completed the EPR operation under its implementation. Independent RIB and FIB reads are still required. So are adjacency state and packet observation. A route may exist in a control-plane table yet lose the preference contest, fail hardware programming, point at a stale adjacency or arrive after another device has already removed its old path.

The same discipline applies to Raw and Tunnel modes. Raw mode forwards on the user's original destination and offers moderate path control; traffic from a different ingress can share a preferred segment. Tunnel mode uses IP-in-IP between the selected entry and exit to constrain the ingress/egress pair more tightly. The BPI T bit records the selected strategy. It does not prove encapsulation, decapsulation, MTU safety, source validation, tunnel endpoint identity or the path taken by observed packets.

A canary should therefore carry ingress identity, flow class, size, timestamps and expected egress, with separate evidence from both tunnel endpoints when Tunnel mode is selected.

Failure turns correlation into a time problem

RFC 9757 treats BPI, EPR and PPA with the same Symbolic Path Name as attributes of one path in the LSP database and invokes the synchronization procedures of RFC 8232. The base stateful model in RFC 8231, the PCE-initiated procedures of RFC 8281 and the central-instruction procedures of RFC 9050 supply the surrounding state, delegation and timeout machinery.

Synchronization proves what was reported within a defined database version and session context. It does not freeze the network. If a PCC falls out of control, the PCE must recompute and redeploy on active PCCs while avoiding transient loops. If the PCE fails, instructions may be redelegated; existing state can survive until a State Timeout Interval rather than disappearing immediately. The evidence chain therefore needs a controller epoch, PCEP session generation, database version, PCC membership set and the precise moment each instruction changed authority.

Cleanup is not one delete button. The PCE sends explicit removal instructions for PPA, EPR and BPI. The safe proof follows the dependency in reverse operational meaning: confirm the intended advertisements are withdrawn, confirm obsolete forwarding is gone without cutting the remaining path prematurely, confirm the BGP session and configuration are removed, then confirm no stale state survives in RIB, FIB, tunnel tables or the synchronized database. The final witness is a negative and positive traffic test: the retired path no longer carries the canary, while the intended surviving or rollback path still does.

Heng Lu's Running-Code Primacy supplies a useful editorial discipline here: publication and coordination artifacts cannot outrank implementation, validation, deployment and use. Minimum Initial Specification separates a common technical vocabulary from later local choices. Applied to RFC 9757, that means respecting the protocol's valuable correlation layer without asking it to certify facts outside its observation.

The leadership ledger has ten linked receipts: controller authority and epoch; mutual capability; completed synchronization; per-object request and report; bilateral BGP identity; route-policy acceptance; RIB/FIB realization; Raw/Tunnel state; packet and service canaries; recomputation, withdrawal and rollback. RFC 9757 improves the first half of that chain. Its value is not that PCRpt becomes packet proof. Its value is that the boundary can be made explicit before a green controller screen becomes an unsupported business decision.

Source register

The current document record includes the RFC 9757 errata search. The supporting PCEP baseline is RFC 5440, while RFC 8408 and RFC 8283 provide the path-setup-type and PCECC context. The editorial tests also draw on Heng Lu's Reality, Not Advocacy and Reality Layers.