Packet Path/

Segment Routing Explained: How a List of Labels Replaces RSVP

Segment routing moves the route into the packet: a short list of waypoints written at the edge and executed by a core that remembers nothing. SIDs, SR Policies, TI-LFA, Flex-Algo, and the SR-MPLS vs SRv6 choice — in plain English.

Routing · Intermediate · 10 min · October 22, 2026

Illustration: a glowing packet carrying a small stack of labels follows a highlighted amber detour path through a mesh of teal routers on a dark navy background

Imagine two ways to cross a city. In the first, you drive from a pre-printed itinerary: the waypoints are listed in order — ring road, river bridge, Elm Street — and every junction waves you through. In the second, you stop at every junction and ask a traffic officer, who must remember your whole trip — every traveller's trip, all day long.

That second picture is old traffic engineering — steering traffic onto chosen paths instead of the default shortest one. Segment Routing is the first picture: the itinerary travels with the packet, and the junctions forget you as you pass.

In plain EnglishSegment Routing puts a short list of waypoints — called segments — into the packet at the first router. Each router follows the instruction on top of the list, then forgets the packet. No router in the middle records your trip, so the network stays simple however many paths cross it.

The problem: steering without a memory bill

Classic MPLS (Multi-Protocol Label Switching — the label-based forwarding most large networks run) has a gap. Its usual partner, LDP, hands out labels following the IGP (Interior Gateway Protocol — IS-IS or OSPF, which finds shortest paths inside one network; our BGP guide covers the external counterpart). That is all it does: no say in which route a flow takes.

The older fix, RSVP-TE (Resource Reservation Protocol – Traffic Engineering), gives path choice — a tunnel pinned to an exact route. The catch: every router on that path must signal the tunnel and remember it — endpoints, path, bandwidth — refreshing it forever. State grows with tunnel count; Cisco and IETF sources describe the resulting scalability and operational cost.

The core idea: the route rides in the packet

Segment Routing is a source-routing architecture — the source picks the route — defined in RFC 8402. The ingress router, the headend, pushes an ordered list of instructions onto the packet. Each instruction is a segment, named by a Segment ID, or SID.

From there, every transit router's job is tiny: read the top instruction, forward accordingly, done. No per-flow or per-tunnel state to store, refresh, or clean up. The smarts sit at the edge; the core just executes.

Who has to remember the route? RSVP-TE: state on every router Router A Router B Router C keeps tunnel state tunnel state tunnel state Segment Routing: state only at the headend Headend Router B Router C holds the SID list no per-tunnel state no per-tunnel state

Two kinds of SID: landmarks and exact turns

Think of a Node SID as a landmark — "get to the cathedral" — and an Adjacency SID as an exact turn — "take this specific alley".

A Node SID (also called a Prefix SID) names a router's loopback or prefix and means the same thing everywhere. The IGP distributes them from one shared label range, the Segment Routing Global Block (SRGB). A Node SID only says "reach this router", so traffic follows the IGP's shortest path there — including spreading across equal-cost paths, as our ECMP explainer walks through.

An Adjacency SID is the opposite: meaningful only to one router, it forces one specific link, even one on no shortest path. Stack a few Node SIDs and you have a waypoint path: "via Denver, then Reno." You rarely list every hop; the IGP fills the stretches between.

A packet walk: Austin to Sacramento

Say the headend in Austin must deliver a packet to Sacramento, via Denver and Reno. Austin pushes a three-SID list: Denver, Reno, Sacramento.

Every router between Austin and Denver does the simplest thing it knows: forward toward Denver, the active segment on top of the list. At Denver, the packet has reached its first instruction, so that SID is popped and Reno becomes active. At Reno its SID pops too, and the final segment delivers the packet to Sacramento.

The middle routers needed only their ordinary routing table — no tunnel table, no memory of the packet.

One packet, three instructions One SID pops at each waypoint Denver Reno Sacramento packet Austin Denver Reno Sacramento pushes the list pops its SID pops its SID delivered

SR Policy: a named intent, not just a path

An SR Policy is how an operator asks for an outcome instead of typing a route. A policy is identified by its headend, its endpoint, and a color — an intent label such as "low-latency" or "avoid this region". A color is just a number; operators agree what each number means, the way a warehouse agrees red stickers mean fragile.

Inside a policy sit candidate paths, each with a preference; the highest-preference valid one is active, and if it fails the next takes over. A candidate can be dynamic — computed under constraints such as bandwidth, delay, or link affinity (include-or-exclude rules written as colours) — or explicit, a hand-written SID list. The site's SR-TE / CSPF Path Visualizer models exactly this.

When a link breaks: TI-LFA

A detour only helps if it is written down before the road closes. TI-LFA (Topology-Independent Loop-Free Alternate) is that written-down detour: for a protected link or node, the router precomputes a backup segment list in advance. When the failure happens, the neighbouring router swaps in the backup list and repairs the traffic locally and immediately — before the IGP has converged, with no signalling wait. The detour was already in the glovebox.

Flex-Algo: more than one meaning of "shortest"

"Shortest" is a choice, not a fact. Flex-Algo (Flexible Algorithm) lets operators define other ways to compute it — minimise measured delay instead of the IGP metric, or exclude certain links. Each definition is its own separate map over the same routers: same streets, different best route. A SID can be tied to one map, so it means "reach this router using the low-delay map".

SR-MPLS vs SRv6: same idea, two envelopes

The itinerary comes in two scripts: SR-MPLS writes each SID as an MPLS label; SRv6 writes each as an IPv6 address.

SR-MPLSSRv6
StandardRFC 8660RFC 8754 (SRH) · RFC 8986 (network programming)
A SID is…An MPLS labelA 128-bit IPv6 address
Where the list ridesThe MPLS label stackThe Segment Routing Header (SRH)
Forwarding planeReuses the existing MPLS forwarding planeIPv6 forwarding; a SID can also encode a function or behaviour
Header growthOne label per segmentOne 128-bit address per segment; lists can grow long

That is SRv6's trade-off and superpower at once: network programming — a SID encodes a behaviour, not just a place. The cost is header size; micro-SID (uSID) compression answers it by packing several micro-instructions into one 128-bit address.

Five mistakes that bite

  1. Listing every hop as Adjacency SIDs. A path hand-nailed through every router is fragile, and the long stack pressures the MTU — when two or three Node SIDs would do.
  2. An inconsistent SRGB. If routers disagree about the global block, the same label value means different SIDs on different boxes — packets head for the wrong landmark.
  3. Forgetting a Node SID follows the IGP. Between waypoints, traffic takes the IGP's shortest path — which may be exactly the congested link you were steering around.
  4. Assuming a controller is required. A headend can compute dynamic candidates itself; a controller (a PCE — Path Computation Element) is optional.
  5. No tested backup. With no TI-LFA and no second candidate, the first failure is the first test of the design — in production.

Verify it before you trust it

Three checks catch most SR surprises — examples in Cisco style (IOS XR / IOS XE), not universal syntax:

! IOS XR: policy state, active candidate
show segment-routing traffic-eng policy

! IGP view: advertised SIDs and SRGB
show isis segment-routing

! IOS XE: forwarding-table check
show mpls forwarding-table

A valid candidate whose label is missing from the forwarding table never became forwarding. Start at the headend.

Try it yourself

Build these paths with three free tools. The SR-TE / CSPF Path Visualizer lets you define SR policies with dynamic and explicit candidate paths and watch the winner get picked. Run a hand-written SID list's config through the Network Config Verifier first. And the BGP Toolkit covers the routes those policies steer.

Key takeaways

Keep reading