RFC 9256 - SR Policy Architecture¶

Common Pitfalls

BSID allocation must be unique per headend. Each Binding SID must uniquely identify a single SR Policy on a given headend. If two policies inadvertently share a BSID, traffic may be steered into the wrong policy. Some implementations dynamically allocate BSIDs to avoid conflicts, but explicit allocation requires careful planning.

Candidate path preference is NOT the same as route preference. SR Policy candidate path preference is an internal ordering mechanism within a single policy. It does not interact with BGP Local Preference, IGP metric, or other routing protocol preferences. A higher candidate path preference means that path is preferred, but this only matters among candidate paths of the same SR Policy.

A policy with no valid candidate path is operationally down. If all candidate paths have invalid segment lists (e.g., unresolvable SIDs), the entire SR Policy becomes invalid. Traffic previously steered via the policy's BSID will be dropped or fall back depending on the implementation.

Weighted ECMP requires careful weight assignment. When a candidate path has multiple segment lists with weights, the traffic split is proportional to the weights (e.g., weights 1:3 means 25%/75%). Setting all weights to 1 produces equal distribution. A weight of 0 is not valid.

Color is not a priority. The Color value (32-bit integer) is an opaque identifier for intent. A higher color value does not mean higher priority -- it simply identifies a different SLA class or steering intent. Color matching is exact.