Segment Routing Primer — SR-MPLS and SRv6

1. The Problem with RSVP-TE

RSVP-TE (Resource Reservation Protocol — Traffic Engineering, RFC 3209) enabled explicit path control in MPLS networks but introduced significant operational complexity:

• Per-flow state: Every LSP requires state on every router along the path (RSVP PATH and RESV messages). In a network with thousands of LSPs, transit routers maintain huge soft-state tables that must be refreshed continuously.
• Head-end signaling: The ingress (head-end) router signals the path through RSVP. Any topology change requires re-signaling, creating convergence overhead.
• Scalability: The number of LSPs grows with O(N²) for full mesh, and each LSP consumes LFIB entries on every transit router.
• Fast-Reroute complexity: RSVP-FRR (RFC 4090) protects LSPs with pre-computed detours or facility bypass tunnels — a feature that works but adds another layer of state.

Segment Routing (RFC 8402) eliminates per-flow state at transit nodes entirely. The source router encodes the entire forwarding path as an ordered list of segments in the packet header itself. Transit routers process only the active segment and do not need LSP state.

2. SR Architecture (RFC 8402)

A segment is an instruction that tells a router how to forward the packet — it could mean "go to this node," "exit on this specific adjacency," or "apply this VPN lookup." Segments are identified by Segment Identifiers (SIDs). An ordered list of SIDs is the segment list (or SID-list). The active segment is processed at each hop; when processing is complete, the segment is removed and the next becomes active.

Two data-plane instantiations exist:

• SR-MPLS: SIDs are MPLS labels. The segment list is a label stack. Backwards-compatible with existing MPLS hardware.
• SRv6: SIDs are 128-bit IPv6 addresses. The segment list is carried in the Segment Routing Header (SRH, IPv6 extension header). IPv6-native; no MPLS required.

3. SR-MPLS: Node-SIDs, Adj-SIDs, and the SRGB

SR-MPLS (RFC 8660) defines two fundamental SID types, advertised by IS-IS (RFC 8667) or OSPF (RFC 8665) as TLV extensions:

The SRGB (Segment Routing Global Block) is the label range reserved for globally significant SIDs. The common default is 16000–23999 (Cisco, Juniper), though it is configurable. Node-SIDs are encoded as index values (e.g., index 100) and resolved to a label by adding the index to the SRGB base (e.g., 16000 + 100 = label 16100). All routers must use the same SRGB for global SIDs to be consistent — mismatched SGRBs between vendors or configurations cause mislabeling.

SR-MPLS label stack example — sending traffic from R1 to R5 via R3 (explicit waypoint), avoiding the direct R1→R5 path:

Ingress R1 pushes: [Node-SID(R3)] [Node-SID(R5)]
  R1→R2: outer label = SID(R3), inner = SID(R5)
  R2→R3: pops SID(R3) (PHP or explicit-null)
  R3 sees top label = SID(R5); forwards on shortest path to R5
  R5 pops SID(R5); delivers to local application

4. SRv6: SIDs as IPv6 Addresses

SRv6 (RFC 8986) encodes SIDs as 128-bit IPv6 addresses structured as:

| Locator (e.g., /48) | Function (operator-defined, typically 16 bits) | Argument (remaining bits) |

• Locator: Routable IPv6 prefix assigned to the node. Transit routers route toward this prefix normally. The locator is advertised in the IGP.
• Function: Identifies the specific operation to perform at the SID endpoint. Examples: End (forward to next SID), End.X (forward out specific adjacency), End.DT4 (decap and IPv4 table lookup — used for IPv4 VPNs), End.DX2 (decap and L2 cross-connect).
• Argument: Optional additional context for the function (e.g., a flow ID for entropy).

The segment list is carried in the SRH (Segment Routing Header, RFC 8754) — an IPv6 extension header with Next Header = 43 (Routing Header), Routing Type = 4. The SRH contains:

• Segment Left (SL): index into the segment list pointing to the active SID
• Tag: flow classification hint
• Segment List[0..n]: the ordered SIDs (last SID is the destination)

At each SR-aware node, if the IPv6 destination matches a local SID, the node executes the SID's function, decrements Segment Left, and copies Segment List[Segment Left] into the IPv6 DA before forwarding.

5. Traffic Engineering with SR-TE

SR-TE (RFC 9256 — SR Policy Architecture) replaces RSVP-TE LSPs with SR Policies, each defined by:

• Headend: The ingress node that instantiates the policy
• Color: A 32-bit identifier used to associate traffic (via BGP Color extended community) with the policy
• Endpoint: The destination node
• One or more candidate paths, each with a weighted segment list

Candidate paths are computed by the headend (using local CSPF/PCE) or distributed by a centralized SR-PCE/controller over PCEP (RFC 5440) or BGP SR Policy (see RFC 9256 §8). This eliminates the RSVP signaling plane entirely while preserving explicit path control.

On-Demand Next-Hop (ODN) is an SR-TE feature where the headend automatically instantiates an SR Policy when a BGP route arrives with a specific Color community, without pre-provisioning — enabling automated traffic steering for VPNs and CDN prefixes.

6. SR-MPLS vs SRv6 vs RSVP-TE

References

• RFC 8402 — Segment Routing Architecture
• RFC 8660 — Segment Routing with the MPLS Data Plane
• RFC 8665 — OSPF Extensions for Segment Routing
• RFC 8667 — IS-IS Extensions for Segment Routing
• RFC 8669 — Segment Routing Prefix SID Extensions for BGP
• RFC 8754 — IPv6 Segment Routing Header (SRH)
• RFC 8986 — Segment Routing over IPv6 (SRv6) Network Programming
• RFC 9252 — BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)
• RFC 9256 — Segment Routing Policy Architecture
• IETF SPRING Working Group — Source Packet Routing In NetworkinG (active SR drafts)