← Interview Prep

SR-TE — Theory

Segment Routing Traffic Engineering: steering traffic along an engineered path expressed as a segment list, with no per-flow state in the core.

SR-TE is traffic engineering built on Segment Routing. Instead of signalling a path hop-by-hop and holding per-LSP state on every router (RSVP-TE), the headend encodes the entire engineered path as an ordered segment list pushed onto the packet. The core just forwards on the top segment — it holds no per-path state. This is the single idea every SR-TE question circles back to, so anchor on it:

In SR-TE the state lives in the packet header (the segment/label stack imposed by the headend), not in the network. Transit routers forward by segment and have no knowledge of the end-to-end policy. That is what makes SR-TE scale and what makes it fundamentally different from RSVP-TE.

This page assumes you already know SR fundamentals — Prefix-SID, Adjacency-SID, the MPLS vs SRv6 dataplanes, and how the IGP floods SIDs. If not, start with Segment Routing — Theory.

The core idea: a path as a segment list

An engineered path is expressed as a stack of segments the headend imposes. Each segment is either a node/prefix segment (go to router X via IGP shortest path — ECMP-friendly) or an adjacency segment (traverse this exact link — pins a hop). Mixing the two lets you say "shortest path to the far side of the network, but cross this specific link on the way."

Engineer traffic from R1 to R6 via the "north" link R3-R4, avoiding R5

   R1 ── R2 ── R3 ═══ R4 ── R6      Segment list pushed at R1 (headend):
    │           ║  (north)   │        ┌─────────────┐
    │           ║            │        │  16003  Node-SID(R3)  │  → go to R3 (ECMP)
    └── R7 ──── R5 ───────── R6       │  24034  Adj-SID(R3→R4)│  → cross north link
                (south)               │  16006  Node-SID(R6)  │  → go to R6 (ECMP)
                                      └─────────────┘
  Core routers R2/R3/R4 keep NO per-path state — they forward on the top label only.

A pure node-SID list follows IGP shortest paths and naturally rides ECMP. Add adjacency-SIDs only where you must force a specific link — this keeps the stack short.
Stack depth (MSD — Maximum SID Depth) is a real hardware limit; path computation must respect how many labels the headend ASIC can push. Binding-SIDs (below) are the main tool to keep stacks shallow.

The SR Policy model

SR-TE is structured around the SR Policy — the modern, controller-friendly object model (RFC 9256). An SR Policy is uniquely identified by a tuple and contains a hierarchy of paths:

Level	What it is
SR Policy	Identified by `(headend, color, endpoint)`. Color is a numeric intent/SLA tag (e.g. "low-latency"); endpoint is the destination node.
Candidate Path	One policy has one or more candidate paths, each with a preference. The valid path with the highest preference becomes the active path; the others are backups.
Segment List	A candidate path is one or more segment lists. Multiple lists in one path carry weights for weighted ECMP (unequal load-balancing across engineered paths).

SR Policy  (headend=R1, color=100 "low-latency", endpoint=R6)
 ├─ Candidate Path  pref 200   (from PCE)          ◀── ACTIVE (highest valid pref)
 │   ├─ Segment List A  weight 3  [16003, 24034, 16006]
 │   └─ Segment List B  weight 1  [16007, 16005, 16006]   ← weighted ECMP 3:1
 └─ Candidate Path  pref 100   (explicit, local)   ◀── standby / fallback

Validation: a candidate path is valid only if its first segment resolves and all SIDs are reachable. If the active path goes invalid, the headend fails over to the next-highest preference automatically.
Candidate paths can come from different sources (local explicit config, BGP SR-TE, PCEP from a controller) — preference decides which wins, giving a clean controller-plus-local-backup design.

Binding SID (BSID)

A Binding SID is a single label that represents an entire SR Policy. Traffic arrives with the BSID on top; the headend of that policy swaps the BSID for the policy's full segment list and forwards. It is the key primitive for scale and abstraction.

Ingress imposes just:  [ BSID_R4 , ... ]        ← one label hides a whole policy
                              │
                     at R4 (policy headend): POP BSID  →  PUSH [16007, 24078, 16009]
                              │
                     packet continues on the expanded segment list

Stacking / scale: a controller can build an end-to-end path as "BSID of policy A, then BSID of policy B," keeping the label stack any single node imposes short — critical given MSD limits.
Abstraction & stability: an upstream domain references only the BSID; the internals of the downstream policy can change (re-optimize, reroute) without the upstream headend or its stack changing.
Anchoring point: the BSID is a stable steering target — BGP/service routes and other policies point at a BSID rather than at a fragile explicit label stack.

Path computation: explicit, dynamic, delegated

Where does the segment list come from? Three models, often combined per candidate path:

Model	Who computes	Notes
Explicit	Operator	The segment list (or a list of hops/SIDs) is configured by hand. Deterministic; no computation. Good for surgical, static paths.
Dynamic (local)	Headend	Headend runs CSPF over its SR-TE database (IGP topology + TE attributes distributed by IGP or BGP-LS) to compute a path meeting the metric/constraints.
Delegated (PCE)	Controller / PCE	Headend delegates to a stateful PCE via PCEP. The PCE has the whole multi-domain topology (via BGP-LS) and can do disjointness/global optimization the headend can't.

Objectives and constraints

Both dynamic and delegated computation optimize a metric subject to constraints:

Metric (minimize)	Constraints
IGP metric — mirror normal routing cost	Affinity (include/exclude links by admin colour / bit)
TE metric — a separate engineered cost	Disjointness — path-, link-, or node-disjoint from another policy (e.g. for a dual-plane / working+protect pair)
Latency / min-delay — measured link delay (RFC 8570 delay metrics)	SRLG — avoid links sharing a Shared Risk Link Group (same conduit/fibre)
	Hop count, bandwidth, max SID depth (MSD)

Stateful PCE — why it matters

A stateful PCE (RFC 8231) keeps a synchronized view of every delegated LSP/policy, so it can reoptimize and coordinate across policies — e.g. compute two truly disjoint paths, or rebalance after a failure. A stateless PCE only answers one-shot path requests.
PCE-initiated policies (RFC 8281): the controller can create policies on the headend, not just answer its requests — the basis for fully controller-driven TE.
The PCE learns topology through BGP-LS (link-state + TE attributes exported into BGP), giving it the multi-domain SR-TE DB it needs.

Steering traffic into a policy: color + endpoint, ODN, Automated Steering

Computing a policy is useless unless traffic actually enters it. SR-TE steering is built on the color + endpoint matching model rather than on static route-to-tunnel maps.

BGP Color extended community: a service/prefix advertised via BGP carries a color community expressing intent ("this VPN needs low-latency = color 100"). The BGP next-hop is the endpoint.
Automated Steering (AS): when a route resolves, the headend looks for an SR Policy matching (next-hop = endpoint, color). If one exists, the route is automatically installed over that policy's BSID — no static tunnel binding, no policy-based routing. Recolor the route → it moves to a different policy.
On-Demand Next-hop (ODN): if no policy exists for a needed (color, endpoint), the headend instantiates one on demand from an ODN template (which specifies the metric/constraints or delegates to the PCE), and tears it down when the last route using it withdraws. Policies appear and vanish with demand.

PE2 advertises  VPN prefix 10.1.1.0/24 , next-hop = PE2 , color = 100
        │
   PE1 receives route → needs (endpoint=PE2, color=100)
        │
   ODN: no such policy? → build one from template (min-delay, PCE-delegated)
        │
   Automated Steering: install VPN route over the policy's BSID
        │
   Traffic for 10.1.1.0/24  ──▶  low-latency engineered path to PE2

The payoff: intent-driven TE. The service simply asks for a colour; policies are created, steered, and removed automatically, scaling to thousands of PE pairs without per-tunnel configuration.

Flex-Algo integration

Flexible Algorithm (Flex-Algo, RFC 9350) lets the IGP itself compute shortest paths on a custom metric (e.g. delay) with constraints (exclude certain affinities), and assigns each participating prefix a Prefix-SID per algorithm. It solves a different slice of the problem than explicit SR-TE:

	Flex-Algo	Explicit / dynamic SR-TE
Where the path is computed	Distributed — every router runs SPF on the algo metric	At the headend or PCE
State in the packet	Usually a single Prefix-SID for the algo	A segment list (can be deep)
Granularity	Network-wide "plane" (all traffic to that SID follows the algo)	Per-policy, per-flow, arbitrary hops
Best for	Broad intent: a low-latency or disjoint "topology" for many destinations	Surgical, per-service paths and multi-domain steering

They compose: a common design uses Flex-Algo to build a network-wide low-latency plane (algo 128 = min-delay), then an SR-TE segment list uses the Flex-Algo Prefix-SIDs as its segments — getting a low-latency engineered path with a shallow stack (one SID per algo hop) instead of a long adjacency-SID list. ODN templates can request a colour that maps straight to a Flex-Algo instance.

SR-TE vs RSVP-TE

	SR-TE	RSVP-TE
Core state	None — path is in the packet's segment list	Per-LSP soft state on every transit router
Signalling	No path signalling; SIDs flooded by IGP once. Headend just imposes labels	RSVP Path/Resv messages set up & refresh each LSP hop-by-hop
Scale	Scales with edge nodes/policies; core is oblivious → very large N²	Limited by core state & refresh load (the classic "N² mesh" pain)
ECMP	Native — node-SIDs ride IGP ECMP; weighted ECMP via multiple segment lists	Poor — an LSP is a single pinned path; ECMP needs many parallel LSPs
Controller-driven	First-class: SR Policy + PCEP/BGP-LS + ODN/Automated Steering	Bolted on; PCE support exists but the model is LSP-centric
Protection	TI-LFA — sub-50ms, 100% coverage, precomputed backup segment list	FRR (facility/one-to-one) with bypass/detour LSPs — more state
Bandwidth admission	No per-hop reservation in the dataplane; done in the controller/PCE model	Explicit per-hop bandwidth reservation & admission control
Failure reconvergence	IGP reconverges; node-SIDs auto-follow new shortest paths	Head-end must resignal/reroute the LSP

The honest nuance: RSVP-TE's one advantage is hard per-hop bandwidth admission control in the dataplane. SR-TE moves that responsibility to a controller/PCE with a global view — which is generally a better place to solve it, and buys enormous state and operational savings everywhere else.

What it looks like on the box

# IOS-XR — an explicit + dynamic SR Policy with a BSID
segment-routing traffic-eng
 policy LOWLAT_TO_R6
  color 100 end-point ipv4 192.0.2.6
  binding-sid mpls 15006
  candidate-paths
   preference 200                       ! preferred: dynamic, min-delay
    dynamic
     metric type delay
    constraints affinity exclude-any name RED
   preference 100                       ! fallback: explicit hops
    explicit segment-list NORTH_PATH
!
segment-routing traffic-eng
 segment-list NORTH_PATH
  index 10 mpls label 16003             ! Node-SID R3
  index 20 mpls label 24034             ! Adj-SID R3->R4
  index 30 mpls label 16006             ! Node-SID R6

# Verify
show segment-routing traffic-eng policy color 100
show segment-routing traffic-eng policy name LOWLAT_TO_R6 detail
 Active path : preference 200 (dynamic, PCE) , BSID 15006
 SID list    : {16003, 24034, 16006}   Metric (delay): 34

Likely follow-up questions

Why does SR-TE scale better than RSVP-TE? (no per-LSP core state — path lives in the packet)
What three things identify an SR Policy? (headend, color, endpoint)
How is the active path chosen among candidate paths? (highest-preference valid path)
What problem does a Binding SID solve? (abstraction, stacking, shallow stacks, stable steering anchor)
Explain node-SID vs adjacency-SID in an engineered stack, and how each affects ECMP.
Explicit vs dynamic vs PCE-delegated computation — when do you use each?
What does a stateful PCE give you that a headend CSPF can't? (global view, disjointness, reoptimization)
How does a BGP service route pull up a policy automatically? (color community → ODN + Automated Steering)
How do Flex-Algo and SR-TE complement each other? (network-wide plane vs surgical per-service paths; algo SIDs as segments)
How is protection done? (TI-LFA vs RSVP FRR) — and what's the tradeoff vs RSVP bandwidth admission?
What's the MSD constraint and how do BSIDs / Flex-Algo help with it?

Related: Segment Routing — Theory · Life of a Packet.