Segment Routing Traffic Engineering (SR-TE) replaces RSVP-TE’s hop-by-hop signaling with a source-routed model where the headend router encodes the entire path as a SID list — eliminating per-LSP state from every transit router in your SP backbone. For CCIE SP candidates, understanding both technologies and their tradeoffs is now essential: the v6 lab tests SR-TE policies, TI-LFA, and Flex-Algo alongside legacy RSVP-TE tunnels.
Key Takeaway: SR-TE is rapidly replacing RSVP-TE in production SP networks because it eliminates control-plane state from the core, scales better, and integrates natively with SDN controllers — but RSVP-TE’s built-in bandwidth reservation still matters for specific use cases, and both appear on the CCIE SP lab.
This guide goes deeper than surface-level comparisons. I’ll walk through the architectural differences, show you side-by-side IOS-XR configurations, explain when each technology wins, and cover exactly what to expect on the CCIE SP lab exam.
How Does RSVP-TE Work in Traditional MPLS Networks?
RSVP-TE has been the standard traffic engineering protocol in SP networks since the early 2000s. Understanding its mechanics is critical — both for the CCIE SP lab and for understanding why the industry is moving away from it.
The RSVP-TE Signaling Model
RSVP-TE creates Label Switched Paths (LSPs) through a multi-step signaling process:
- Path message — The headend router sends a PATH message downstream, hop-by-hop, specifying the Explicit Route Object (ERO) with the desired path
- Resv message — The tail-end router responds upstream with a RESV message, allocating labels and optionally reserving bandwidth at each hop
- State maintenance — Every transit router maintains per-LSP soft state, refreshed by periodic RSVP messages (default: every 30 seconds)
Here’s a basic RSVP-TE tunnel on IOS-XR:
interface tunnel-te 100
ipv4 unnumbered Loopback0
destination 10.0.0.5
signalled-bandwidth 500000
path-option 10 explicit name PATH-TO-PE5
path-option 20 dynamic
!
explicit-path name PATH-TO-PE5
index 1 next-address strict ipv4 unicast 10.1.1.2
index 2 next-address strict ipv4 unicast 10.2.2.3
index 3 next-address strict ipv4 unicast 10.3.3.5
Why RSVP-TE Has Scalability Problems
The fundamental issue is per-LSP state on every transit router. In a network with 500 PE routers running full-mesh RSVP-TE tunnels, each P router must maintain state for thousands of LSPs. According to Cisco Live’s 2025 SR deployment guide, this creates three compounding problems:
- Memory consumption — Each LSP consumes RSVP state, MPLS forwarding entries, and TE tunnel interface resources
- CPU overhead — Periodic PATH/RESV refresh messages (every 30 seconds per LSP) consume control-plane processing
- Convergence delays — When a link fails, RSVP-TE must re-signal affected LSPs, which takes time proportional to the number of affected tunnels
In a Tier 1 SP network with thousands of LSPs, these problems are not theoretical — they directly impact convergence time and operational stability.
How Does Segment Routing Traffic Engineering Work?
SR-TE fundamentally changes the traffic engineering model by moving all path state to the headend router. According to Network Devices Inc.’s 2025 comparison guide, this creates a “stateless core” architecture that eliminates the scalability bottlenecks of RSVP-TE.
The SR-TE Source-Routing Model
Instead of signaling a path hop-by-hop, SR-TE works like this:
- SID assignment — Each router advertises its Node SID and Adjacency SIDs via IS-IS or OSPF extensions
- Path computation — The headend router (or an external SR-PCE controller) computes the desired path
- SID list encoding — The complete path is encoded as an ordered list of SIDs in the packet header
- Stateless forwarding — Transit routers simply pop the top SID and forward based on their local label table — no per-tunnel state required
Here’s the equivalent SR-TE policy on IOS-XR:
segment-routing
traffic-eng
segment-list SL-TO-PE5
index 10 mpls label 16002
index 20 mpls label 16003
index 30 mpls label 16005
!
policy POL-TO-PE5
color 100 end-point ipv4 10.0.0.5
candidate-paths
preference 100
explicit segment-list SL-TO-PE5
!
preference 50
dynamic
pcep
!
metric
type igp
!
!
!
!
!
!
!
Notice the difference: no tunnel interface, no RSVP signaling, no bandwidth reservation messages. The SR-TE policy exists only on the headend router. Transit routers have zero awareness that this traffic-engineered path exists.
SR-TE Policy Components
An SR-TE policy is identified by three elements:
| Component | Purpose | Example |
|---|---|---|
| Headend | The router originating the policy | PE1 (10.0.0.1) |
| Color | A numeric value representing an intent (low-latency, high-bandwidth, etc.) | 100 |
| Endpoint | The destination router | PE5 (10.0.0.5) |
The color concept is what makes SR-TE powerful for service differentiation. You can create multiple policies to the same endpoint with different colors, each representing a different SLA. BGP then uses Automated Steering to map services to the appropriate SR-TE policy based on color communities — something RSVP-TE achieves far less elegantly.
What Are the Key Technical Differences Between SR-TE and RSVP-TE?
This is the comparison table I wish I’d had when I was studying for the CCIE SP lab. According to analysis from Immad Khan’s deep dive on LinkedIn and WWT’s SR-MPLS enterprise guide, here’s how they stack up:
| Feature | RSVP-TE | SR-TE |
|---|---|---|
| Signaling protocol | RSVP-TE (hop-by-hop) | None — IGP extensions (IS-IS/OSPF) distribute SIDs |
| State in transit routers | Per-LSP state on every hop | Stateless — only headend knows the policy |
| Bandwidth reservation | Native (RESV message) | Requires SR-PCE with bandwidth-aware computation |
| Path computation | CSPF on headend or external PCE | Headend CSPF, SR-PCE, or Flex-Algo |
| Fast Reroute | FRR with backup tunnels (facility/1:1) | TI-LFA (Topology-Independent Loop-Free Alternate) |
| SDN integration | Limited — PCEP bolt-on | Native — SR-PCE + PCEP is core architecture |
| Operational complexity | High — RSVP state, refresh timers, ERO management | Lower — no signaling protocol to troubleshoot |
| Scalability ceiling | ~5,000–10,000 LSPs per P router (practical limit) | Limited only by label stack depth (typically 10–12 SIDs) |
| Multi-domain TE | Complex — inter-AS RSVP requires stitching | Native — SR-PCE computes paths across IGP domains |
The scalability difference is the killer feature. In a network with 200 PE routers, a full-mesh RSVP-TE deployment creates ~40,000 LSPs that every P router must maintain. With SR-TE, the P routers maintain zero tunnel state. The headend routers each maintain only their own policies — typically dozens, not thousands.
How Does TI-LFA Compare to RSVP-TE FRR?
Fast Reroute is where SR-TE delivers one of its most compelling advantages over RSVP-TE.
RSVP-TE FRR: The Legacy Approach
RSVP-TE Fast Reroute requires pre-signaling backup tunnels — either facility backup (protecting a link or node) or one-to-one backup (per-LSP protection). Configuration example:
interface tunnel-te 100
fast-reroute
!
mpls traffic-eng
interface GigabitEthernet0/0/0/0
backup-path tunnel-te 999
The problem: you need to pre-configure backup tunnels, and the protection coverage depends on your backup tunnel topology. Miss a scenario, and you have an unprotected failure case.
TI-LFA: Topology-Independent Protection
SR-TE uses Topology-Independent Loop-Free Alternate (TI-LFA), which automatically computes backup paths for any topology without pre-configuration:
router isis CORE
interface GigabitEthernet0/0/0/0
address-family ipv4 unicast
fast-reroute per-prefix
fast-reroute per-prefix ti-lfa
TI-LFA provides 100% topology coverage — it can protect against any single link or node failure by computing post-convergence paths using segment lists. No backup tunnels to design, no coverage gaps to worry about.
According to APNIC’s 2024 analysis on SR deployments, TI-LFA has become the primary FRR mechanism in new SP deployments, with sub-50ms failover times matching or beating RSVP-TE FRR performance.
What Should CCIE SP Candidates Focus On?
The CCIE SP v6 lab exam tests both technologies, but the balance is shifting. Based on Cisco’s exam topics and community feedback, here’s what to prioritize:
SR-TE Topics (High Weight)
- SR-MPLS configuration — Node SIDs, Adjacency SIDs, Prefix SIDs on IS-IS and OSPF
- SR-TE policies — Explicit and dynamic candidate paths, color/endpoint model
- Automated Steering — BGP color communities mapping services to SR-TE policies
- TI-LFA — Per-prefix fast reroute with topology-independent protection
- Flex-Algo — Custom IGP topologies for service differentiation (low-latency, disjoint paths)
- SR-PCE — Centralized path computation with PCEP
RSVP-TE Topics (Still Tested)
- Basic RSVP-TE tunnels — Explicit paths, dynamic paths, autoroute
- FRR — Facility backup, one-to-one backup
- RSVP-TE to SR-TE migration — Dual-stack operation, coexistence scenarios
- Bandwidth reservation — RSVP signalled bandwidth, admission control
Lab Strategy
In the CCIE SP lab, you’ll likely encounter scenarios where you need to:
- Configure SR-MPLS with IS-IS and verify SID distribution
- Build SR-TE policies with explicit and dynamic paths
- Implement TI-LFA for fast convergence
- Possibly troubleshoot an RSVP-TE tunnel that coexists with SR-TE
- Use Automated Steering to map L3VPN services to SR-TE policies by color
Don’t neglect RSVP-TE entirely — but invest 70% of your TE study time in SR-TE. That’s where the lab is heading, and it’s where SP networks are heading in production.
For a deeper look at SRv6 — the next evolution beyond SR-MPLS — check out our guide on SRv6 uSID migration from MPLS.
What Are Real SP Networks Doing in 2026?
The migration from RSVP-TE to SR-TE is well underway. According to Lightyear’s 2026 comparison guide, most Tier 1 and Tier 2 service providers are in some phase of SR adoption:
Phase 1 — Dual Stack (Where Most SPs Are Now)
- Run IS-IS with SR extensions alongside existing LDP/RSVP-TE
- Deploy SR-TE policies for new services while legacy services stay on RSVP-TE tunnels
- Enable TI-LFA to replace RSVP-TE FRR
Phase 2 — SR-PCE Deployment
- Deploy centralized SR-PCE controllers for multi-domain path computation
- Begin migrating bandwidth-sensitive services from RSVP-TE to SR-PCE-computed paths
- Implement Flex-Algo for service differentiation without per-tunnel state
Phase 3 — Full SR-TE
- Remove RSVP-TE entirely from the network
- All traffic engineering handled by SR-TE policies + SR-PCE
- Begin evaluating SRv6 for next-generation data plane
The consensus from Reddit’s r/ccie community echoes this reality: “MPLS+BGP is not going out of fashion in a hurry” — but the signaling layer (LDP and RSVP-TE) is absolutely being replaced by Segment Routing.
Frequently Asked Questions
What is the main difference between SR-TE and RSVP-TE?
SR-TE encodes the entire path as a SID list at the headend router, making the core stateless. RSVP-TE signals explicit paths hop-by-hop and maintains per-LSP state on every transit router — creating scalability challenges in large SP networks.
Is Segment Routing replacing MPLS?
SR-MPLS runs on the same MPLS data plane — it replaces LDP and RSVP-TE signaling, not MPLS itself. Most service providers are migrating from RSVP-TE to SR-TE while keeping MPLS forwarding. SRv6 is the longer-term evolution that replaces the MPLS data plane entirely.
Does the CCIE SP lab exam test Segment Routing?
Yes. The CCIE SP v6 lab heavily tests SR-MPLS, SR-TE policies, TI-LFA, and Flex-Algo on IOS-XR. RSVP-TE is still tested but SR-TE scenarios are increasingly dominant.
Can SR-TE and RSVP-TE coexist in the same network?
Yes. Most SP migrations run both protocols in parallel during a transition phase. SR-TE policies can coexist with RSVP-TE tunnels, and Cisco’s SR-PCE controller can manage both.
Does SR-TE support bandwidth reservation like RSVP-TE?
Not natively. SR-TE relies on external mechanisms like SR-PCE with bandwidth-aware path computation or Flex-Algo constraints. RSVP-TE’s built-in bandwidth reservation remains an advantage for networks requiring strict guarantees.
Ready to master both SR-TE and RSVP-TE for the CCIE SP lab? Contact us on Telegram @phil66xx for a free assessment — I’ll help you build a study plan tailored to your SP track goals.