Summary

  • In the SR Policy architecture, “active” means that the headend has selected the best valid candidate path. It does not mean that a particular flow matched the steering condition or entered that path.
  • A useful proof chain must connect the policy tuple and selected candidate to the segment list, BSID and FIB state, the actual steering selector, packet encoding, observed path and measured service objective.
  • Default BGP steering can send traffic along the ordinary IGP path when the route does not carry the authorised colour or no matching valid policy exists, even though another policy is active on the headend.

The green status that did not move the flow

Imagine an operator checking a latency-sensitive service after a customer reports a regression. The controller shows the intended SR Policy as valid and active. Its preferred candidate path is present. The segment list looks plausible. Yet a probe from the affected ingress follows the ordinary shortest path.

There is no contradiction. The policy display answers a selection question: which valid candidate path won for this policy at this headend? The probe answers a forwarding question: which instructions did this packet actually receive, and where did those instructions take it? A route that lacks the authorised colour-and-next-hop match can miss the policy steering rule and retain its normal IGP resolution. The policy may remain perfectly active while carrying none of the traffic under investigation.

That distinction matters because “active” is an attractive stopping point. It is compact, machine-readable and usually green. But it sits near the beginning of the causal chain, not at the end.

What active state establishes

RFC 9256 identifies an SR Policy by the tuple <Headend, Color, Endpoint>; at one headend, <Color, Endpoint> is sufficient. A policy can have multiple candidate paths. A candidate is usable when it is valid, and the active candidate is the best valid one, selected primarily by preference. Relevant state changes require the selection process to run again.

This is meaningful evidence. It tells the operator which policy object is under discussion and which candidate currently represents it. It can also identify one or more active segment lists and their weights. What it does not establish is that the target traffic was steered onto the policy. RFC 9256 is explicit that the active candidate path is used for traffic that is actually steered to it, subject to protection behaviour. The conditional phrase is the operational hinge.

If several segment lists are active, traffic may be distributed per flow according to weights. The accuracy of that distribution is implementation-dependent. A single successful probe therefore cannot certify the full weighted population, just as one unexpected probe cannot by itself prove that every flow missed the policy.

Steering is a separate decision

For BGP destination steering, the default behaviour described by RFC 9256 joins three facts: the route’s next hop, an authorised Color Extended Community and a valid SR Policy matching that next hop and colour. When the match exists, the route can resolve over the policy. When it does not, the documented default is ordinary IGP resolution to the next hop.

This creates several states that a dashboard can easily compress into one reassuring line. The policy may be active but the route may carry no colour. The colour may be present but not authorised. The endpoint derived from the next hop may not match. The matching policy may have become invalid. A deployment may also use an explicit drop-on-invalid behaviour rather than fallback. Those are steering and resolution facts, not candidate-selection facts.

The Binding SID is another place where identity can be overstated. A BSID belongs to the active candidate path and provides a forwarding instruction into the policy. Its availability must be checked, conflicts should raise an alert, and its association can change during the life of the policy. RFC 9256 therefore says it must not be used to identify the policy. The stable identity remains the policy tuple, while the BSID is current forwarding state that must be verified.

The packet carries the decisive instructions

RFC 8402 describes Segment Routing as ordered instructions imposed at a headend. In SR-MPLS those instructions appear as a label stack; in SRv6 they appear as an ordered SID list, commonly in an SRH. When a local active segment matches a policy BSID, the packet is steered into the associated policy.

The packet thus provides evidence that no control-plane status can substitute for. A label or SID capture can show whether the expected instructions were imposed. Interface and forwarding counters can show whether the programmed action was exercised. A path-aware probe can test the resulting route, while latency and loss measurements test the service objective. Each observation answers a different question, and together they close the gap between selected intent and delivered behaviour.

Protection complicates the picture without erasing it. A constituent IGP segment can be protected by TI-LFA. During fast reroute, the temporary repair path may not satisfy the exact SR Policy constraints. An active policy and an unexpected transient path can therefore both be legitimate. The useful incident record must capture timing and protection state instead of treating any deviation as proof that selection failed.

Sources