Lessons (5, study in order)

Lesson 1 · Why Segment Routing grew out of MPLS tunnels

Beginner · about 8 min

Goal: Get straight on what problem SR actually solves, instead of memorizing concepts right away.

A quick recap of LDP's and RSVP-TE's pain points

LDP: follows the IGP, can't specify a path, and has no idea how much bandwidth is left anywhere.

RSVP-TE: can specify a path and reserve bandwidth, but the cost is that every hop has to maintain a separate piece of state for every tunnel, kept alive by periodic refreshes — once tunnels pile up, just maintaining that soft state becomes a real burden on a carrier network.

★ This is exactly what Segment Routing set out to solve: is there a way to specify a path that doesn't require devices along the way to maintain any state at all?

SR's core idea: write the path into the packet header, not into the memory of devices along the way

SR's approach: break the entire explicit path into a string of "segments" and push them directly onto the packet's label stack.

Devices along the way only need to recognize the label and know what to do with it — they never need to know which tunnel this packet belongs to at all.
This is the exact opposite of RSVP-TE's approach: RSVP-TE says "have every hop remember this tunnel"; SR says "every hop remembers nothing — the answer is already written on the packet."

The key difference: the label is computed, not negotiated

SR's most common kind of segment is called a Prefix-SID: every device floods a globally unique index via an IGP extension (IS-IS / OSPF), and once other devices learn it, they compute the formula themselves:

label = SRGB starting value + index

and now they know "which label to use to reach this device" — with no need to check in with it at all. This is also exactly why the SRGB must be configured identically network-wide: if the formula's inputs don't match, the computed labels won't either.

Key takeaways

• SR exists to solve RSVP-TE's problem of transit nodes carrying too much state
• How: push the explicit path onto the packet's label stack — devices along the way don't need to remember any "tunnel" at all
• The label is computed from SRGB + index, never negotiated via signaling

Lesson 2 · Prefix-SID and SRGB

Beginner · about 8 min

Goal: Understand exactly what the arithmetic "16000 + 2 = 16002" is doing.

Prefix-SID: assigning an index to a prefix (usually a loopback)

Every device assigns its own loopback a Prefix-SID index (also called a Node-SID); this index is flooded network-wide via an IGP extension, and once others learn it, they compute the label themselves.

The index is just a relatively small number (say, 1, 2, 3…) — the label value isn't the index itself, it's the result after adding the SRGB's starting value.

SRGB: Segment Routing Global Block, the label's "conversion baseline"

The SRGB is a range of labels each device reserves specifically for SR (the common default is 16000–23999).

The same index computes to a different label value on two devices with different SRGBs — so real-world deployments strongly recommend the same SRGB network-wide, or planning and troubleshooting both become a real headache.

Try it: see how this formula gets used on the packet-simulation page

Beijing, Seoul, Tokyo, and San Francisco have indexes 1, 2, 3, and 4, and all share an SRGB starting value of 16000, so their labels are 16001, 16002, 16003, and 16004 respectively.

Go to page ② (packet simulation) and watch how these labels get pushed onto the data packet, then popped off hop by hop.

Key takeaways

• Prefix-SID = a globally unique index assigned to a prefix
• Label = SRGB starting value + index — the SRGB must match network-wide
• This conversion needs zero signaling negotiation — it's purely computed locally

Lesson 3 · Adjacency-SID: when you need to pin down a specific link

Advanced · about 8 min

Goal: Prefix-SID can only get you to "a device," never to "a specific link" — that's its inherent limitation.

Prefix-SID's limitation: the target is a device, not a link

If there are two equal-cost links (ECMP) between two devices, Prefix-SID can only tell devices along the way "go to this device" — which specific link gets used is up to local load-balancing logic. You can't force it to take one specific link using Prefix-SID.

Adjacency-SID: pinned to one specific adjacency

An Adjacency-SID (Adj-SID) isn't bound to a device — it's bound to "my one specific link to a given neighbor." As soon as an Adj-SID is on the label stack, the device that receives it must send it out that exact specified link, with zero choice in the matter.

★ Unlike Prefix-SID: an Adj-SID is usually only meaningful locally on that one device — it needs no network-wide conversion, and is "precision-guided" by design.

Combining them: Prefix-SID for most of the path, Adj-SID at the critical hop

The common real-world approach is: use Prefix-SID for most of the path (to save label-stack depth), and only insert an Adj-SID at the one hop where you "must avoid a specific link" or "must force a choice under ECMP."

This page's walkthrough scenario is a straight chain with no alternate route, so Prefix-SID alone is enough the whole way — with no ECMP, Prefix-SID is inherently the only path anyway.

Key takeaways

• Prefix-SID pins down a device, Adj-SID pins down one specific link
• Under ECMP, only Adj-SID can force traffic onto one specific link
• Common real-world usage: mostly Prefix-SID, with Adj-SID mixed in at critical hops

Lesson 4 · SR-TE Policy: color, endpoint, segment list

Advanced · about 10 min

Goal: Understand exactly what those few lines of config are saying.

Three fields you must remember

An SR-TE Policy is uniquely identified by three fields:

· color: a numeric tag attached to this Policy; routes can use a BGP Color Community to automatically match onto the Policy of the matching color (the key to automatic traffic steering)
· endpoint: this tunnel's destination (usually the egress device's loopback)
· segment list / explicit path: which segments to pass through, in order — equivalent to RSVP-TE's ERO

Binding-SID: wrapping the entire Policy in one more shell

A binding-SID is a label assigned to the Policy itself. Its purpose: another device only needs to push this one label to steer traffic into the entire Policy, without ever needing to know the full length of the Policy's segment list.

This is especially useful in multi-domain scenarios: a domain's border device only needs to know "push this binding-SID" — it doesn't need to know how many hops the other domain takes internally.

Try it: copy the config on the packet-simulation page step by step

Go to step ③ on page ② (packet simulation) and copy the segment-list and te-policy lines line by line, paying attention to how the three SIDs in the segment list correspond to "the explicit path passing through Seoul, then Tokyo, in order."

Key takeaways

• A Policy is uniquely identified by color + endpoint
• The segment list is the explicit path, equivalent to RSVP-TE's ERO
• The binding-SID is a shell wrapped around the whole Policy — very useful in multi-domain scenarios

Lesson 5 · A head-to-head comparison with RSVP-TE

Troubleshooting · about 10 min

Goal: Same network, same path, two ways to build a tunnel — where exactly do they differ.

Step-count comparison: 12 signaling steps vs. 4 forwarding steps

The RSVP-TE page finishes with 12 automatic steps (8 signaling + 4 forwarding).

This SR-TE page has only 4 automatic steps, and all of them are data forwarding — because the path is already in the packet header, so there's no need to check in with any hop ahead of time.

State comparison: who maintains state for this tunnel

RSVP-TE: every hop along the way maintains soft state for "this tunnel" and refreshes it periodically.

SR-TE: devices along the way only maintain "my own SID table" — this table has nothing to do with how many Policies exist network-wide — this is the biggest motivation for carrier networks moving to SR: tunnel counts can scale to tens of thousands with ease.

Try it: flip back and forth between the two paths

The RSVP-TE and SR-TE pages walk through exactly the same physical path (Beijing→Seoul→Tokyo→San Francisco). Flip back and forth between the two "why does it work this way" explanations, and make sure you can clearly explain "same path, two approaches — where's the difference."

Key takeaways

• RSVP-TE: 12 steps of signaling + forwarding; SR-TE: only 4 forwarding steps
• SR-TE's transit-node state has nothing to do with tunnel count; RSVP-TE's does
• A basic SR-TE Policy isn't bandwidth-aware — bandwidth awareness needs a PCE