Segment Routing Architecture
updated by
- rfc-9256 — Segment Routing Policy Architecture
Extracted elements (27)
BSID provides scalability, network opacity, and service independence: policy instantiation (the SID list) is stored only at the nodes imposing the policy. Traffic directed toward those nodes requires only the BSID, so policy changes affect only the imposing nodes and not the traffic sources.
Identical SRGBs are strongly recommended on all nodes in an SR-MPLS domain because computing the label following an anycast segment requires knowing which label a set of topologically-equal next-hops will use. Without identical SRGBs, the label stack following an anycast segment cannot be correctly computed and misrouting (including VPN traffic leakage) may result.
For LAN subnetworks, additional IGP protocol mechanisms (IS-IS and OSPF extensions) are required so that each router in the LAN can advertise an Adj-SID per neighbor, since standard DR/DIS flooding does not expose individual node-to-node adjacencies.
In SRv6, non-SR-capable routers can still forward packets toward a node that owns an SRv6 SID because standard IPv6 FIB entries for shorter-mask covering prefixes suffice. This allows SR traffic to traverse nodes that do not understand SR, which is a key backward-compatibility property of SRv6.
A node MUST install a FIB entry for any locally originated Adj-SID of value W attached to a set of links B with: Incoming Active Segment = W, Ingress Operation = NEXT, Egress interfaces = load-balance across any data-link within set B.
A source SR node MUST NOT use an SR Policy containing a Strict-SPF segment if the path crosses a node that does not support the Strict-SPF algorithm, since such nodes will not install forwarding entries for it.
An IGP-Anycast segment MUST NOT reference a particular node. Within an anycast group, all routers in the SR domain MUST advertise the same prefix with the same SID value.
An IGP Node-SID MUST NOT be associated with a prefix that is owned by more than one router within the same routing domain.
Each global segment MUST be bound to a unique index or address within an SR domain. Implementations SHOULD protect the network in case of conflict detection by providing a deterministic resolution approach.
For SR-MPLS, node N advertising Prefix-SID SID-R with CONTINUE behavior for directly connected neighbors MUST maintain a FIB entry: Incoming Active Segment = SID-R, Ingress Operation = NEXT, Egress interface = NULL.
If a node learns of a Prefix-SID whose value falls outside the locally configured SRGB range, the node MUST NOT use that Prefix-SID and SHOULD issue an error log reporting a misconfiguration.
In SR-MPLS, a remote node M MUST maintain a FIB entry for each learned Prefix-SID SID-R: Ingress Operation is NEXT if the next-hop is the originator and M is instructed to remove the active segment, otherwise CONTINUE; Egress interface is towards the next-hop along the path computed by the advertised algorithm.
In SRv6, an operator MUST explicitly instantiate an SRv6 SID; IPv6 node addresses are not SRv6 SIDs by default. A node advertising address R as a segment MUST maintain a FIB entry with Incoming Active Segment = R, Ingress Operation = NEXT, Egress interface = NULL.
Parallel adjacency suppression MUST NOT be performed by the IGP, so that all Adj-SIDs representing IGP adjacencies between two nodes can be advertised. When a node binds Adj-SID V to local data-link L it MUST install a FIB entry: Incoming Active Segment = V, Ingress Operation = NEXT, Egress Interface = L.
The Prefix-SID allocation process MUST NOT allocate the same Prefix-SID value to different prefixes within the SR domain.
A Binding SID (BSID) is bound to an SR Policy; packets arriving with an active segment equal to the BSID are steered onto the bound SR Policy. A local BSID SHOULD be allocated from the SRLB; a global BSID MUST be allocated from the SRGB.
An IGP-Adjacency Segment (Adj-SID) is attached to a unidirectional adjacency or set of adjacencies and enforces switching of the packet toward a specific interface or set of interfaces, overriding SPF routing decisions. Its flags convey eligibility for protection, local/global scope, and persistence across restarts.
An IGP-Prefix Segment (Prefix-SID) is an IGP segment attached to an IGP prefix, global by default within the SR domain. Its context is the tuple <prefix, topology, algorithm>; multiple SIDs MAY be allocated to the same prefix so long as this tuple is unique.
BGP Peering Segments enable source-routed inter-domain paths for Egress Peer Engineering (EPE). Three types are defined: PeerNode SID (next-hop is the peering node), PeerAdj SID (next-hop via the specific peering interface), and PeerSet SID (load-balance across a group of peers).
SR-MPLS encodes a segment as an MPLS label and an SR Policy as a stack of labels. The active segment is the top label; upon completion of a segment, the label is popped (NEXT operation), and an incomplete segment performs a SWAP (CONTINUE operation).
SRv6 encodes a segment as an IPv6 address and an SR Policy as an ordered list of IPv6 addresses in a Segment Routing Header (SRH). The active segment is the Destination Address (DA) of the IPv6 packet; NEXT is implemented by decrementing SegmentsLeft (SL) and copying the next segment to DA.
The SR Global Block (SRGB) is the set of global segments in an SR domain. In SR-MPLS it is a node-local set of labels reserved for global segments; in SRv6 it is the set of global SRv6 SIDs. Using identical SRGBs on all nodes in the SR-MPLS domain is strongly recommended.
The SR Local Block (SRLB) is a local property of an SR node containing labels (SR-MPLS) or IPv6 addresses (SRv6) reserved for local segments. Controllers may discover available local segments via the control plane.
Two Prefix-SID algorithms are defined: Algorithm 0 (Shortest Path First) follows the standard ECMP-aware SPF and permits local policy overrides; Algorithm 1 (Strict-SPF) mandates ECMP-aware SPF forwarding and prohibits any local policy override, though FRR mechanisms remain compliant.
By default, SR operates within a trusted domain and traffic MUST be filtered at the domain boundaries. For SR-MPLS, domain boundary routers MUST filter any external traffic destined to labels within the SRGB, SRLB, or outside these blocks. Explicit routing information MUST NOT be leaked through the boundaries of the administered domain.
For SRv6, domain boundary routers MUST filter external traffic destined to addresses within the SRGB or SRLB of the trusted domain. Violations of the trust model can result in malicious looping, evasion of access controls, and hiding the source of DoS attacks.
SR does not introduce new congestion control requirements; best-effort delivery is assumed. Where SR policies are in use, bandwidth allocation may be managed by monitoring traffic associated with the binding SID, and circuit-breaker mechanisms such as RFC 8084 may be applicable.