Summary

  • RFC 9857 lets an SR Policy headend, or a PCE acting for headends, advertise candidate-path state through BGP-LS to external components.
  • The NLRI identifies the headend even when the PCE is the producer; Protocol-Origin describes how the candidate was instantiated, not the observation time or a complete producer chain.
  • A defensible decision joins the advertisement to a producer/session epoch, current SRPM state, an independent FIB receipt, observed traffic and a service measurement in the same interval.

A useful answer arrived without its age

An external controller receives a BGP-LS update for an SR Policy candidate path. The descriptor matches the expected headend, color, endpoint, originator and discriminator. The Candidate Path State TLV says the path was evaluated, has a valid SID list and is active. A Binding SID is present. The update is syntactically clean.

That is real evidence. It is also not yet a safe instruction to move a service.

RFC 9857 was written to make locally available SR Policy state visible outside the node that holds it. The use cases are consequential: path computation, reoptimization, service placement and network visualization. The document complements RFC 9830, which sends SR Policy candidate paths toward a headend using BGP. RFC 9857 carries operational state back toward controllers. The direction has changed, and so has the audit question. It is no longer “did BGP deliver the candidate?” It is “what exactly did the receiving controller learn about the running candidate, from whom, and when?”

The protocol provides a strong vocabulary for the first half of that question. It does not provide a complete clock or execution receipt for the second.

Headend identity is not always producer identity

RFC 9857 permits the BGP-LS Producer to be the SR Policy headend itself. It also permits a PCE to originate the advertisement on behalf of headends after receiving their state through PCEP. Those arrangements are operationally different even when they describe the same candidate.

The distinction is easy to lose because the Local Node Descriptors TLV identifies the headend in both cases. When a PCE produces the route, it must not put its own identifiers into that NLRI descriptor. It may include its BGP Router-ID, AS or confederation member in the BGP-LS Attribute. The specification also gives the PCE case separate “in PCEP” Protocol-Origin values.

Protocol-Origin is valuable, but it answers a narrower question: which protocol or component was responsible for instantiating the candidate path. It is not a universal statement that the BGP speaker directly observed the headend's SR Policy Manager at the moment the consumer received the update. A PCE-produced record can include state previously reported by a PCC. RFC 8231 defines that PCC-to-PCE LSP State Report and the synchronization context around it.

A serious consumer therefore retains two identities. The first is the subject: the headend and candidate path named by the RFC 9857 descriptors. The second is the reporter chain: authenticated BGP peer, actual BGP-LS producer, direct-headend or PCE-proxy mode, and—where a PCE relays the state—the PCC/PCEP report from which the claim was derived. Flattening those into one “source” field creates confidence that the encoding never promised.

State flags are claims with precise meanings

The Candidate Path State TLV is not decorative telemetry. Its flags distinguish administrative shutdown, active and backup status, evaluation, validity, delegation, controller provisioning, transit eligibility and drop-upon-invalid behavior. The E and V flags must be joined: if evaluation has not occurred, validity cannot be treated as a completed verdict. Preference and priority add decision context.

The A flag is especially important. RFC 9857 points to RFC 9256 and describes an active candidate as one provisioned in the forwarding plane. The correct reading is not “the controller merely selected it in a database.” The producer is reporting a materially stronger operational condition.

But a reported condition is still a report. The same update can include Binding SID status and individual SID lists with computation, verification, resolution, topology and monitoring flags. A consumer can learn that a specified BSID was unavailable, that fallback allocation occurred, that a list failed resolution or that monitoring removed it from forwarding. These fields help explain failure instead of compressing it into one green or red icon.

They do not independently prove that the exact hardware table accepted the object, that counters moved, or that a service met its objective. That boundary is not a criticism of the flags. It is what makes them useful: each field has a defined scope rather than an unlimited claim.

The missing temporal join

RFC 9857 defines candidate identity, state encodings and advertisement procedures. Its candidate-path record does not carry a producer observation timestamp, a monotonic report generation, an SRPM transaction number or a forwarding-chip acknowledgement. The BGP-LS Instance Identifier identifies a routing instance; it is not a temporal epoch.

The base RFC 9552 model matters here. BGP-LS distribution is subject to policy, and a speaker may control when information is updated to a consumer in order to reduce information flow. RFC 9857 inherits those BGP-LS operational considerations. The latest route in a consumer's database can therefore be valid BGP state while being too old for the decision the application is about to make.

Freshness has to be made explicit at the receiving system. Record the time of receipt, the BGP session generation, resets and resynchronization, replacement and withdrawal history, and the maximum permitted age for the intended action. If a PCE is the producer, add the age and identity of the preceding PCEP report. “Current” should mean current inside a declared window and chain, not merely present in a table.

Five separate receipts after BGP-LS

The first receipt is the BGP-LS record itself: exact candidate identity, flags, attributes, producer and receive epoch.

The second comes from SR Policy Manager at the named headend. It should reproduce the candidate identity, evaluation, validity, active choice, BSID and SID-list generation. A mismatch says the controller is holding an older or differently scoped account.

The third is a forwarding receipt. It comes from the FIB, hardware programming channel or a comparably direct device readback. It identifies the programmed BSID and treatment, the installation generation, success or rejection, and the target hardware context. The RFC 9857 A flag supports the expectation; this receipt independently corroborates it.

The fourth is traffic observation. Counters and scoped probes show whether the intended traffic exercised the programmed treatment. They need denominators, reset provenance and time bounds. Traffic can be absent, misclassified or carried elsewhere while every control object remains internally coherent.

The fifth is the service outcome. Delay, loss, availability or application success must be measured over the affected population and interval. A service result cannot be backfilled from a path metric or an “active” label.

The result is a joined proof, not a larger green light. RFC 8402 places Segment Routing inside a trusted SR domain; RFC 9857's security section accordingly limits disclosure to trusted nodes and applications. Trust controls who may speak. It does not remove the need to record what each speaker directly knew.

What the registry and erratum establish

The current IANA BGP-LS registry records Candidate Path NLRI type 5, Segment Routing Protocol-ID 9 and RFC 9857's descriptor and state TLVs. The Datatracker record establishes the document's standards history. Neither record demonstrates a vendor implementation or production deployment.

The RFC Editor errata record lists verified EID 8709. It corrects three occurrences of “SR Binding SID sub-TLV” to “SR Binding SID TLV” in Section 5.1. That editorial correction matters for accurate terminology but does not alter producer roles, candidate-state flags or the freshness boundary.

Heng Lu's essay on Running-Code Primacy supplies the broader discipline: publication and registration do not make operational reality by declaration. RFC 9857 already respects that discipline by reporting state rather than pretending to create it. The operator's obligation is to preserve the report's scope all the way to execution and outcome.

Sources