Segment Routing Policy Architecture
updates
- rfc-8402 — Segment Routing Architecture
Extracted elements (30)
The Binding SID provides scaling, network opacity, and service independence. It enables classification results to be encoded efficiently in packet headers so intermediate aggregation nodes do not need to re-classify traffic, decoupling the steering decision point from the headend.
The BSID SHOULD NOT be used as an identifier for an SR Policy because the association of an SR Policy with a BSID may change over the life of the SR Policy (e.g., upon active path change when a new active path does not have a specified or available BSID).
The candidate path selection tiebreaking order (Preference → Protocol-Origin → Originator → Discriminator) is designed to allow operators to override protocol defaults via Preference, establish default cross-protocol preferences via Protocol-Origin, support redundant controllers deterministically via Originator, and ensure deterministic final selection via Discriminator regardless of signaling order.
The Drop-upon-Invalid behavior was designed for use cases where operators want traffic (e.g., a Pseudowire) to only be transported on a path meeting specific constraints; when those constraints are no longer met, they want the traffic dropped rather than rerouted via the IGP shortest path.
When steering unlabeled IPv6 BGP destination traffic over an SR Policy composed of segment lists based on IPv4 SIDs and an 'IPv6 Explicit NULL label' is not present as the bottom label, the headend SHOULD automatically impose one.
A segment list of an explicit candidate path MUST be declared invalid when it is empty, its weight is 0, it mixes SR-MPLS and SRv6 segment types, the headend cannot perform path resolution for the first SID, cannot resolve any non-first SID of type C–K, or verification fails for any SID requested to be verified.
An SR Policy MUST be identified through the tuple <Headend, Color, Endpoint>. In the context of a specific headend, an SR Policy MUST be identified by the <Color, Endpoint> tuple.
Candidate paths of different SR Policies MUST NOT have the same BSID. When a specified BSID is not available (optionally not in the SRLB), an alert message MUST be generated via mechanisms like syslog.
For composite candidate paths, the endpoints of constituent SR Policies and the parent SR Policy MUST be identical, the colors MUST be different, and constituent SR Policies MUST NOT use composite candidate paths.
If no solution is found to the optimization objective and constraints for a dynamic candidate path, then the dynamic candidate path MUST be declared invalid.
In multi-domain deployments where the headend may be unable to verify reachability of SIDs in remote domains, Types A or B MUST be used for SIDs whose reachability cannot be verified. The first SID MUST always be reachable regardless of its type.
Only the active candidate path MUST be used for forwarding traffic steered onto the SR Policy, except for fast-reroute scenarios where a backup candidate path may be used.
The SR Policy state MUST also reflect the reason when a policy and/or its candidate path is not active due to validation errors or not being preferred.
Under Specified-BSID-only restrictive behavior, if the active candidate path has an unspecified or unavailable BSID, no BSID is bound and the candidate path is considered invalid. An alert MUST be triggered via mechanisms like syslog, and other candidate paths MUST then be evaluated.
When building the MPLS label stack or SRv6 SID list from a segment list, the node MUST interpret segments such that the first segment is the topmost MPLS label or first SRv6 SID (active segment), and the last segment is the bottommost label or last SRv6 SID.
Whenever a new path is learned, an active path is deleted, the validity of an existing path changes, or an existing path is changed, the candidate path selection process MUST be re-executed. The candidate path with the highest Preference value among valid paths is selected.
A candidate path is uniquely identified by the tuple <Protocol-Origin, Originator, Discriminator> within the context of an SR Policy. The identity MUST be uniquely established to handle add, delete, or modify operations unambiguously regardless of source.
Eleven segment descriptor types (A–K) are defined for use in SR Policy segment lists: Type A (SR-MPLS Label), Type B (SRv6 SID), Types C–H (various IPv4/IPv6 prefix and adjacency resolution types for SR-MPLS), and Types I–K (IPv6 prefix and adjacency resolution types for SRv6).
Per-destination steering uses the BGP Color Extended Community (RFC 9012): a BGP route's next-hop N and Color C match a valid SR Policy (color=C, endpoint=N), causing the route to be installed with next-hop equal to the SR Policy's BSID rather than via N.
Protocol-Origin is an 8-bit value indicating the mechanism used to signal or provision the candidate path. Recommended default values are: PCEP=10, BGP SR Policy=20, Via Configuration=30; lower numeric value indicates lower preference as a tiebreaker.
The Binding SID (BSID) of an SR Policy is the BSID of its active candidate path. A BSID is available when its value (MPLS label or IPv6 address) is not associated with any other usage. The BSID MAY change over the life of the SR Policy and SHOULD NOT be used as an identifier for the SR Policy.
The Discriminator is a 32-bit value that uniquely identifies a candidate path within the context of an SR Policy from a specific Protocol-Origin. For BGP SR Policy, the BGP distinguisher is used; for PCEP and configuration, the default value is 0.
Three color-only BGP destination steering types are defined: Type 0 (default, match on N+C only), Type 1 (fall through to null-endpoint SR Policy of same address-family then any address-family), and Type 2 (additionally fall through to any endpoint with matching color).
When a BGP route has multiple Color Extended communities each with a valid SR Policy, the BGP process selects the SR Policy for the Color Extended community with the highest numerical value. When the highest-color SR Policy is inactive, the next highest color is considered.
IANA created a new 'Segment Types' subregistry under the 'Segment Routing' registry (originally created by RFC 8986). It maintains alphabetic identifiers (A–Z, then AA–AZ, etc.) for segment types usable within an SR Policy segment list, with Specification Required allocation policy.
If an address used as an SR Policy endpoint is advertised by more than one node due to misconfiguration or spoofing, traffic steered over the SR Policy may be diverted to an undesired node. Mechanisms for detection of duplicate prefix advertisement should be used, though their details are outside this document's scope.
Misconfiguration or error in setting the BGP Color Extended Community on BGP routes can result in forwarding packets along undesired paths when per-destination steering is in use.
Symbolic names signaled with SR Policies and candidate paths are unrestricted free-form text from external parties; implementations should display them in a manner that differentiates them from known-good information and users should validate using the specific policy identifiers rather than relying on symbolic names.
SR Policy validity: a policy is valid when it has at least one valid candidate path. Upon transition to invalid state, the SR Policy and its BSID are removed from the forwarding plane and all steered traffic falls back to classic forwarding. The Drop-upon-Invalid behavior optionally keeps the policy in the forwarding plane with a drop action instead.
The Originator is a 160-bit value formed by concatenating a 4-byte ASN (low-order 16 bits for 2-byte ASNs, high-order bits set to 0) and a 128-bit node address (IPv4 addresses in the lowest 32 bits, high-order bits set to 0).