Summary

  • RFC 9830 gives BGP an SR Policy address family and encodings for candidate paths, but BGP is not the consumer that selects and installs the active policy.
  • A Distinguisher keeps advertisements separate without adding semantic meaning; Color and Endpoint identify the policy, while SRPM compares eligible candidates from BGP and other sources.
  • Evidence must preserve receipt, BGP selection, intended-headend import, SRPM validation, active-candidate choice, Binding SID, forwarding installation and observed packets as different events.

A valid route can still be only a proposal

The opening case is constructed to expose a protocol boundary, not to describe a real controller, router or deployment. The BGP updates can be correctly encoded, accepted by a peer and retained in a BGP table. Those are valuable facts. They prove that a candidate path crossed the BGP carriage layer. They do not prove that the headend accepted its segment semantics or programmed it for traffic.

RFC 9830 is unusually explicit about this separation. It defines how BGP originates and propagates Segment Routing Policy candidate paths. It does not make BGP their actual consumer. At the headend, candidate information passes to the Segment Routing Policy Module, or SRPM. That module can learn other candidates through CLI, NETCONF, PCEP or local configuration, validate their policy-specific contents, choose an active candidate, associate a Binding SID and install state in the data plane.

That is two selections, not one. BGP chooses a best route for a particular NLRI under BGP rules. SRPM chooses an active candidate for a policy under SR Policy rules. A green BGP route and a green SR Policy are therefore different receipts, even when a user interface places them on the same screen.

The Distinguisher separates without explaining

The SR Policy NLRI contains a Distinguisher, a Color and an Endpoint. Color and Endpoint identify the policy key. The Distinguisher lets an originator create distinct NLRIs for multiple candidate paths of that policy or for advertisements aimed at different headends.

The standard says the Distinguisher has no semantic value. That sentence should govern observability design. A Distinguisher can stop BGP from forcing two advertisements into the same route-selection contest. It cannot tell an operator why one candidate exists, whether it is safer, who approved it, which service it supports or whether it should beat a candidate learned from another protocol.

When different Distinguishers let several BGP routes for one Color/Endpoint tuple reach the headend, BGP can pass several candidates to SRPM. The receiving system also attaches origin information assembled from the Route Origin Community, ORIGINATOR_ID or the peer's Router ID in a defined order. That origin record helps reconstruct protocol provenance. It is not a corporate identity, a change approval or proof that the sender had authority to redirect a service.

The result is a useful but bounded identity stack: NLRI identity keeps a route distinct; policy identity groups candidates under Color and Endpoint; originator information locates a protocol source; SRPM's Protocol-Origin and Discriminator distinguish candidate sources; a change record explains human authority. Removing any layer makes later explanations weaker. Treating one layer as all the others makes them false.

BGP syntax and SR semantics have different judges

RFC 9830 defines structural tests that belong to BGP. An SR Policy update needs the correct SAFI, NLRI length and Tunnel Encapsulation Attribute form. The SR Policy Tunnel Type is 15. A prohibited tunnel type, duplicated SR Policy TLV or malformed required structure can make the update unusable and trigger treat-as-withdraw handling.

That containment rule protects the BGP session from one bad route while withdrawing the affected information. It still does not mean that every update surviving BGP checks is a valid SR Policy candidate. The RFC directs BGP not to perform semantic verification of individual SR Policy fields. Those checks belong to SRPM.

The difference matters for incident labels. “Withdrawn by BGP encoding check,” “ignored sub-TLV,” “not imported for this headend,” “rejected by SRPM,” and “eligible but not selected” identify different decision owners and different repair paths. Compressing them into “policy invalid” destroys the location of the decision.

Unknown or inapplicable fields reinforce the point. Some fields must be ignored and may be removed during propagation. Reserved bits are transmitted as zero and ignored on receipt. Only the first instance of some single-instance sub-TLVs is used while later copies are ignored. These rules preserve extensibility and session continuity, but they also mean the bytes originated, the bytes received and the information handed to SRPM need not be identical sets.

Preference is not BGP preference

An SR Policy candidate can carry Preference, Priority, Binding SID, Segment Lists, weights, names and Explicit NULL behavior. The familiar words tempt operators to assign them to the wrong layer.

The Preference sub-TLV informs SRPM's candidate-path selection. It does not enter BGP best-path selection. Priority concerns the order in which policies are recomputed after a topology change; it is not the rank of one BGP route against another. Segment-list weight distributes traffic among valid lists in a selected candidate; it is not evidence that the list was installed or that measured traffic matches the ratio.

Names are even weaker. A policy or candidate name is symbolic and may be truncated for signalling. It is helpful to people, but it is not the policy key and cannot replace the Color/Endpoint plus candidate identity. A dashboard that joins solely on a display name can merge two policies or split one policy across renames.

Binding SID fields also leave room for local authority. Depending on flags and data-plane form, a headend can verify, allocate or reject a Binding SID under SRPM rules. An SRv6 endpoint behavior can be left opaque for the headend to choose. A sender can recommend traffic-class or TTL values while the receiver may override them by local policy. Explicit NULL behavior may also be overridden to match deployment requirements.

The advertisement is thus neither a command nor a finished forwarding record. It is a structured candidate whose fields have different degrees of force. Evidence should say “received,” “accepted,” “overridden,” “allocated,” “selected” or “installed,” rather than applying one undifferentiated status to the whole payload.

Intended headend is not active headend

Many controllers send a policy directly to its headend. Where direct sessions do not scale, route reflectors or multiple ASes inside one trusted SR domain can propagate it. Route Targets then identify the intended headends.

Route Target import is an audience decision. It proves that local policy considered the advertisement intended for this receiving role. It does not prove that the candidate passed SRPM validation, beat a PCEP or configured candidate, obtained a usable Binding SID or reached the forwarding plane. A missing Route Target can prevent a correct candidate from reaching the intended module; an over-broad Route Target can disclose a policy to routers that were never supposed to see it.

The security consequence is larger than reachability. SR Policy advertisements can reveal endpoints, node addresses, SIDs and commercially sensitive path design. BGP sessions require configuration, but session establishment alone does not authorize every address family or every recipient. The approved SR domain, peer role, SAFI, Route Targets and export policy need an explicit disclosure record.

That record should survive route reflection. The headend may receive origin information through several fallback mechanisms, and the immediate peer may be a reflector rather than the controller that created the candidate. “Received from this neighbor” and “originated by this controller” are separate fields. Neither proves who approved the business purpose.

Withdrawal does not tell you what stopped forwarding

When a BGP SR Policy route is withdrawn, BGP removes one source contribution. SRPM may still have another BGP candidate with a different Distinguisher, a PCEP candidate, a configured candidate or a valid backup. The active policy can stay unchanged, switch candidates, become invalid or disappear. The withdrawal alone does not choose among those outcomes.

The same caution applies in the other direction. A new BGP best path may be delivered to SRPM without changing the active candidate. Its Preference may lose to another source, a segment may fail verification, its Binding SID request may be unusable, or local policy may reject it. Counting BGP updates is not counting forwarding changes.

Proof of effect needs a longer chain: raw update received; structural BGP result; selected BGP route for the NLRI; Route Target import; origin reconstruction; SRPM semantic result; candidate-set snapshot; active-candidate decision; Binding SID state; installed segment lists and weights; programmed RIB/FIB state; and packets observed on the expected path. Each record needs time, device, software version and reason.

Minimum standards work best when authority stays local

RFC 9830 standardizes a difficult interoperability surface: the address family, NLRI, attributes, candidate fields, error handling and propagation rules needed to carry SR Policy proposals through BGP. That common language is the minimum shared layer. It does not need to decide every local deployment choice to be useful.

This is where Heng Lu's minimum-specification principle becomes operational. Shared encoding lets independent implementations exchange a candidate. Local SRPM policy retains the decision that bears local consequences. Running-code primacy then demands proof from the actual headend and forwarding plane, not an assumption derived from the prestige of a Standards Track document. Reality-layer discipline keeps the proposal, the selected control state and packet behavior apart.

The practical test is simple. Send two BGP candidates for one Color/Endpoint with different Distinguishers. Add a higher-preference candidate through PCEP or local configuration. Observe which BGP routes survive, what reaches SRPM, what SRPM rejects, which candidate becomes active, which Binding SID and segment list enter the FIB, and where packets go. Then withdraw each source separately. If the monitoring system cannot explain every transition without calling all of them “BGP policy,” it has lost the authority boundary RFC 9830 carefully preserved.

Sources