Summary

  • A successful PCRep carrying an explicit route proves that a PCE found a path under a particular topology, constraint set, objective and policy view. It does not prove that a PCC accepted the result or that a device installed it.
  • Later receipts answer later questions: signaling or programming, reservation, RIB/FIB state, PCC reports, packet telemetry and service measurements. None can be safely inferred from the computation alone.

The controller has returned a green result. Its diagram shows an elegant route from ingress to egress. The PCEP response contains an Explicit Route Object, or ERO, and the metrics fit the request. Yet no router has said that it accepted the route. No resource has been shown as reserved. No FIB has been read back. No packet has been observed taking the path.

What exists at that moment is a computed path.

This distinction is easy to lose because network-control software compresses a long sequence into one visual object. A line on a topology map may represent a proposal, a delegated intention, a signaled LSP, an installed forwarding entry or a measured traffic path. The drawing can look identical while the underlying evidence is completely different.

Adrian Farrel's contribution to the PCE architecture is useful precisely because the original model does not require that compression. RFC 4655, published in 2006 by Farrel, Jean-Philippe Vasseur and Jerry Ash through the IETF PCE Working Group, defines a Path Computation Element as an entity that computes a path from a network graph while applying computational constraints. It places computation in an architecture with separate routing-information, policy and signaling functions. That separation is not a historical inconvenience. It is the operational contract.

The answer belongs to its inputs

The PCE does not consult a timeless network. It operates on a Traffic Engineering Database. RFC 4655 defines the TED as topology and resource information for a domain, populated through IGP extensions or other mechanisms. A PCE may have complete, partial or out-of-band information. The architecture warns that weaker synchronization can increase the failure rate of computed paths or yield suboptimal ones during frequent change.

A positive result therefore means: given this graph, this resource view and the semantics applied now, the computation found a solution.

The request narrows the claim further. RFC 5440, written by Vasseur and Jean-Louis Le Roux, defines the PCReq and PCRep exchange. A PCReq can identify endpoints, bandwidth, priorities and other constraints. RFC 5541 supplies objective-function machinery: minimize this cost, optimize that property, choose among feasible paths by a declared rule. Local policy can reject a request, alter what is returned or govern which PCE and constraints a PCC uses.

These are different concepts. A constraint says what a path must or must not do. An objective function says how to choose among candidates. Policy says what an administrative actor permits or prefers. The TED says what the computation believes the network looks like. When operators store only the ERO, they discard much of the provenance needed to reproduce the answer.

What a positive PCRep actually says

RFC 5440's successful sequence is remarkably disciplined: the PCE receives a request, successfully computes a path and sends the computed path to the PCC. Section 7.9 says the ERO in the PCRep encodes the computed TE-LSP path. It also says that the explicit path is available for immediate signaling.

“Available for” carries the whole boundary. The ERO can become an input to the next mechanism. It is not evidence that the next mechanism ran.

In an RSVP-TE deployment, RFC 3209 defines a signaling and reservation process. Nodes along the route can reject setup; state can change between computation and signaling; resources can be unavailable despite the earlier view. In a Segment Routing deployment, an SR Policy candidate path and its segment list still have to be instantiated at a headend, and traffic still has to be steered into the policy. RFC 9256 makes those layers visible, while RFC 8664 defines how Segment Routing path information is carried over PCEP.

The technologies should not be blurred. RSVP-TE can signal and reserve hop by hop. Segment Routing can program a headend with a segment list and avoid per-path state in intermediate nodes. Both, however, preserve the same evidentiary rule: a computed representation is not the data-plane event it is meant to cause.

Stateful PCE adds receipts, not magic

The original PCEP request/reply model is often described as stateless. Later work added state synchronization, delegation and PCE-initiated LSPs. Those extensions make the control loop richer; they do not make computation self-proving.

RFC 8231 is explicit that the PCC retains LSP-state ownership. Even when an active stateful PCE controls selected attributes of a delegated LSP, attributes received from the PCE remain subject to the PCC's local policy. Delegation can be revoked per LSP. It is authority to update a defined object, not ownership of the router or proof that packets moved.

The decisive receipt comes later as a Path Computation LSP State Report, or PCRpt. When an LSP becomes up or active, the PCC reports that state. If setup fails, it reports down and a cause. RFC 8231 goes further: there is no direct correlation between a PCRep and PCRpt, and multiple state reports may follow one computation reply. That sentence should end the habit of treating a green PCRep as an installed service.

RFC 8281 lets a stateful PCE initiate LSP creation. Initiation is stronger than advice, but it remains a request to an execution point. Device policy, capability, signaling and operational state still sit between intention and outcome.

The proof ladder after computation

An operator who wants to claim that a path is real needs a sequence of receipts.

First comes acceptance: did the PCC accept the reply or update under its local policy? Next comes execution: did it signal an RSVP-TE LSP, program a Segment Routing policy or use another mechanism? Then comes resource and installation evidence: were reservations made where the technology requires them, and did the intended RIB and FIB state appear on the relevant devices?

Only after that does the question become physical: are packets actually traversing the intended interfaces or segments? Counters, probes, path traces and flow telemetry answer that question. Loss, latency, jitter and availability over a defined interval answer the separate service question. Compliance needs its own scope and evidence again.

A FIB entry is not a packet trace. A packet trace is not an SLA. A state report is not a customer outcome. The proof ladder is not bureaucratic overhead; it is how a control system avoids reporting its intention as reality.

Vendor practice reinforces the point. Juniper's PCEP documentation says that a PCC re-signals an LSP after receiving PCE attributes and provides separate commands for the PCEP session, PCC-known LSPs, Segment Routing TE detail and protocol routes. Its Paragon troubleshooting guide describes a provisioning acknowledgement while the LSP remains operationally down because the PCC cannot signal it. That is one implementation, not a universal protocol rule, but it makes the failure boundary concrete.

Farrel's proper credit

Farrel's IETF record spans far more than one architecture. The strongest claim here is deliberately narrower. In RFC 4655, he, Vasseur and Ash helped establish a vocabulary in which computation, policy, topology knowledge and signaling can be inspected separately. Vasseur and Le Roux then specified the base PCEP exchange. Later authors and the PCE Working Group added stateful operation, delegation, initiation and Segment Routing extensions. Implementers made the pieces run; operators decide what evidence is sufficient.

That attribution matters for the same reason the protocol boundary matters. Network control is cooperative work across documents, code, devices and operations. Assigning it to one person would repeat the category error this architecture helps prevent: treating one visible artefact as the whole system.

Source register