SR-MPLS and SRv6 in real deployments — traffic steering, path control, and what actually changes in operations
1. What Is Segment Routing — The Real Explanation
Segment Routing is a source-based routing architecture. Instead of requiring every router in the network to maintain per-flow state — which is what RSVP-TE demands — SR encodes the entire forwarding path in the packet header at the ingress node. Transit routers simply execute the instruction list embedded in the packet. No per-flow state, no signalling protocol overhead, no RSVP hello messages consuming CPU cycles across every core router in the network.
This is the fundamental shift. In RSVP-TE, you signal a tunnel path and every router along that path must maintain RSVP session state. In a network with 500 gNB sites and 50 RSVP-TE tunnels per site, that is 25,000 RSVP sessions spread across your core routers. Add redundant paths, bypass tunnels, and FRR state — you are looking at hundreds of thousands of RSVP objects. This does not scale. Operators with large 5G deployments hit this wall hard.
Segment Routing solves this by eliminating per-flow state from transit nodes entirely. The ingress PE knows the path. It encodes it as a stack of Segment Identifiers (SIDs) in the packet. Transit routers execute SID instructions mechanically — no awareness of what flow this is or why it is taking this path.
2. Real Network Architecture — SR-MPLS vs SRv6
Two Flavours of Segment Routing
Segment Routing comes in two dataplane variants, and operators need to understand the real differences before choosing:
| Aspect | SR-MPLS | SRv6 |
| Dataplane | MPLS label stack — SIDs are MPLS labels | IPv6 extension header (SRH — Segment Routing Header) |
| Existing HW compatibility | Works on any MPLS-capable router — no HW upgrade needed | Requires IPv6 forwarding and SRH processing — older HW may not support |
| Overhead | 4 bytes per SID (MPLS label) | 16 bytes per SID (IPv6 address) — higher overhead on WAN links |
| Programmability | Limited — label space constrains flexibility | High — full IPv6 address space as SID = fine-grained steering |
| Operational maturity | Production-ready, widely deployed in GCC operators today | Emerging — large-scale deployments increasing, not yet universal |
| Migration path | Drop-in for existing MPLS networks — reuse PE/P hardware | Requires IPv6 underlay and HW capability assessment first |
For most GCC operators today, SR-MPLS is the practical choice. It leverages existing MPLS hardware, eliminates RSVP-TE signalling complexity, and provides immediate operational benefits. SRv6 is the long-term direction — particularly for operators building new cloud-native core networks and MEC infrastructure — but it demands a more deliberate migration plan.
Segment Types and SID Roles
In Segment Routing, a SID is an instruction. Different SID types encode different forwarding behaviours:
| SID Type | What It Does | Real Use Case |
| Node SID | Route to a specific router node via ECMP shortest path | Basic reachability — CU to UPF via any path in the core |
| Adjacency SID | Forward out a specific interface to a specific neighbour | Force traffic onto a specific link — bypass congested segment |
| Prefix SID | Route to a specific IP prefix via shortest path | Steer RAN traffic to specific subnet (e.g. UPF cluster) |
| Binding SID (BSID) | Represents an entire SR policy as a single SID | Traffic steering: map a traffic class to a pre-defined policy |
| Service SID (SRv6) | Encode VPN or service endpoint in IPv6 address | SRv6 VPN — encapsulate L3VPN forwarding in SRH |
3. Step-by-Step Real Flow — SR Policy Traffic Steering
Enterprise Slice Forced onto Low-Latency Path
Here is a concrete scenario: an operator has deployed a 5G network slice for a manufacturing enterprise customer in Muscat Industrial Area (Rusayl). The enterprise SLA requires end-to-end latency below 10ms from the UE to the enterprise application server hosted at a MEC node in Seeb.
The default IGP shortest path from the Rusayl gNB site PE to the Seeb MEC PE goes via Ruwi core — adding an extra hop and 4ms of latency. The operator needs to force this enterprise slice traffic onto a direct Rusayl-to-Seeb path, bypassing Ruwi entirely. In the old MPLS-TE world, this required a new RSVP-TE tunnel with explicit route configuration and RSVP state on every node. With SR, the ingress PE handles it alone.
Step 1 — SR Policy Definition at Ingress PE
The operator defines an SR Policy on the Rusayl PE router. The policy has:
- Color: 100 (identifies this as the low-latency enterprise policy)
- Endpoint: Seeb MEC PE loopback address
- Candidate path: explicit SID list [Node SID of Rusayl P router, Adjacency SID of direct Rusayl-to-Seeb link, Node SID of Seeb MEC PE]
This SID list is the complete forwarding instruction. No other router needs to know this path exists. The Rusayl PE pushes this SID stack onto every enterprise slice packet that arrives from the gNB CU-UP.
Step 2 — Packet Enters the Network
An enterprise UE sends a packet. The gNB CU-UP forwards it via GTP-U over N3 to the Rusayl PE. The PE matches the packet to the SR Policy (via DSCP marking or VRF colour attribute in BGP). It pushes the SID stack onto the packet: [Node SID Rusayl-P | Adj SID direct-link | Node SID Seeb-MEC-PE | Original IP Packet].
Step 3 — Transit Nodes Execute SIDs Mechanically
The Rusayl P router receives the packet. It reads the top SID (its own Node SID — meaning ‘you have arrived at this node, proceed to next instruction’). It pops its own SID, reads the next SID (Adjacency SID for the direct Rusayl-to-Seeb link), and forwards the packet out that specific interface. No RSVP state. No path lookup. One label operation.
Step 4 — Egress PE Delivers to MEC
The packet arrives at the Seeb MEC PE with only the final Node SID or a bare IP header (if PHP applied). The PE strips remaining SR headers, performs VRF lookup, and forwards the inner packet to the MEC application server. Total path: Rusayl → direct link → Seeb. The Ruwi hop was bypassed entirely — without touching the Ruwi router configuration at all.
Key insight: This is the operational revolution of SR. The path change was made entirely at the ingress PE. No RSVP signalling to other nodes. No coordinated configuration across multiple routers. The operator’s SDN controller computed the path and pushed the SR Policy to one router via BGP-SR or NETCONF/YANG. Operations teams that used to spend days coordinating RSVP-TE changes across multiple routers now do it in minutes.
4. Practical Example — GCC Operator SR Deployment
A typical GCC operator deploying SR-MPLS for 5G transport will organise it as follows:
| Traffic Class | SR Policy Color | SID List Strategy | Benefit over RSVP-TE |
| VoNR / real-time | Color 10 | Lowest latency path — avoid high-utilisation links via TE metric | No RSVP session per tunnel — SR TI-LFA handles FRR automatically |
| Enterprise slice (MEC) | Color 20 | Explicit path to nearest UPF/MEC PE — bypass core hops | Path change in minutes from SDN controller — no router-by-router config |
| 5G N2 control plane | Color 30 | Diverse path from N3 — different physical route for resiliency | Disjoint path guaranteed via SR disjointness constraint — no manual TE |
| Bulk data / internet | Color 0 (default) | IGP shortest path — no explicit SID list | No overhead — falls through to standard IP/LDP forwarding |
5. SR vs MPLS-TE — Honest Comparison
Where SR Wins, Where RSVP-TE Still Has an Edge
| Capability | RSVP-TE | SR-MPLS | Verdict |
| Per-flow state in core routers | Yes — scales poorly with site count | No — stateless core | SR wins clearly |
| Explicit path control | Yes — ERO in RSVP setup | Yes — SID list at ingress | Equivalent |
| Bandwidth admission control | Yes — RSVP CAC per tunnel | Not natively — needs SR-TE with bandwidth constraints | RSVP-TE edge for guaranteed BW |
| Fast Reroute | Pre-computed bypass tunnels | TI-LFA — topology independent, automatic | SR TI-LFA simpler to operate |
| Operational complexity | High — RSVP on every router | Low — only ingress PE needs SR Policy | SR wins significantly |
| SDN/automation integration | Complex — tunnel-per-path model | Clean — BGP-SR, PCEP, NETCONF | SR wins clearly |
| Hardware requirements | Any MPLS HW | Any MPLS HW (SR-MPLS) or IPv6+SRH (SRv6) | SR-MPLS equal, SRv6 more demanding |
The honest answer: RSVP-TE with bandwidth admission control still has a role in networks where guaranteed bandwidth reservation per tunnel is a hard requirement — typically for very high-value enterprise SLAs where overbooking is unacceptable. But for RAN transport in a 5G network with hundreds of gNB sites, SR-MPLS wins on every operational dimension.
6. Key Parameters and Configurations
| Parameter | Where Configured | Typical Value / Setting | Impact if Wrong |
| SRGB (SR Global Block) | All SR-capable routers — IS-IS/OSPF SR extension | 16000–23999 (IANA default range) | Label conflicts if SRGB differs across routers in same domain |
| Node SID index | Each router’s loopback — IS-IS SR config | Unique integer per router (e.g. 101, 102…) | Duplicate SID index = forwarding loop or blackhole |
| Adjacency SID | Auto-allocated per interface OR manually pinned | Dynamic preferred; pin for explicit path policies | Dynamic adj SID changes after router reload — update SR Policies |
| SR Policy color | Ingress PE — BGP or local SR policy config | Operator-defined per traffic class | Wrong color = traffic on wrong path, SLA breach |
| TI-LFA | All IS-IS/OSPF SR nodes | Enabled globally, post-convergence paths pre-computed | Disabled = no FRR — failure causes multi-second outage |
| SR-TE metric | TE metric on each IS-IS/OSPF interface | Set higher on high-latency or congested links | Wrong TE metric = SR PCE computes wrong low-latency path |
7. Common Issues in the Field
- SRGB mismatch across routers — if different routers in the same IS-IS domain are configured with different Segment Routing Global Blocks, Node SIDs from one router conflict with labels used by another. This causes forwarding loops or silent traffic blackholes that are very difficult to diagnose. Define SRGB once, document it, enforce it in your router provisioning templates.
- Adjacency SID changing after maintenance — dynamic adjacency SIDs are re-allocated after a router reload or IS-IS adjacency reset. Any SR Policy using an explicit adjacency SID in its SID list becomes invalid after this event. Traffic falls to a non-preferred path silently. Pin adjacency SIDs for all SID lists used in SR Policies.
- SR Policy not instantiated — an SR Policy defined via BGP-SR or PCEP will not forward traffic if the candidate path is down (SID list unreachable) or preference not met. Check SR Policy operational state, not just config. A policy can be configured but inactive.
- TI-LFA post-convergence path computation failure — TI-LFA requires IS-IS/OSPF to compute backup paths for every prefix. If the topology has nodes without SR capability mixed in (brownfield migration), TI-LFA cannot compute SR-native backup paths through those nodes. Mixed SR/non-SR domains need careful FRR planning.
- SRv6 MTU explosion — each SRv6 SID adds 16 bytes. A SID list with 4 SIDs adds 64 bytes to the packet, plus the SRH fixed header. On WAN links with standard 1500-byte MTU, this causes fragmentation immediately. SRv6 deployments require jumbo frames or MTU planning from day one.
- PCE path computation latency — in SDN-driven SR deployments, the Path Computation Element (PCE) computes optimal SR paths centrally. If PCE is overloaded or has stale topology information (TED not updated), it computes suboptimal or invalid paths. Monitor PCE health as a first-class network element.
8. Troubleshooting Approach
SR Has Less State to Debug — But You Need the Right Tools
One advantage of SR is that the control plane is simpler — there is no distributed RSVP state to reconstruct. But debugging data plane forwarding requires SR-specific tools:
- Verify SR capability advertisement — check IS-IS or OSPF SR TLVs are being advertised by all nodes. A router missing SR capability advertisement will not be usable as an SR transit node. Use: show isis segment-routing or show ospf segment-routing.
- Check Node SID and Adjacency SID allocation — on each router, verify SIDs are allocated correctly and match the planned design. Any duplicate SID index in the domain is a critical error.
- Validate SR Policy operational state — on the ingress PE, check: show segment-routing traffic-eng policy. Verify the policy is Active, the candidate path is Up, and the correct SID list is installed in the forwarding table (LFIB/FIB).
- Use SR ping and SR traceroute — these work like MPLS ping/traceroute but for SR paths. They verify end-to-end forwarding along the SR Policy SID list, identifying exactly which hop drops or misforwards the packet.
- Check TI-LFA backup path — after topology computation, verify each prefix has a computed backup next-hop: show isis fast-reroute summary. If coverage is below 100%, identify the topology constraints causing gaps.
- Correlate with PCE logs — in SDN-driven deployments, cross-reference SR Policy failures with PCE path computation logs. A Policy going down often traces back to a PCE computation rejection or topology update delay.
Field Note: In a live GCC operator SR migration, we found that 15% of adjacency SIDs were dynamically allocated and changed after a planned IS-IS maintenance. Seventeen SR Policies silently fell to suboptimal paths. The fix was straightforward — pin all adjacency SIDs used in explicit SID lists — but the detection required comparing SR Policy SID lists against current adj-SID allocations, which had to be done manually. Automate this check in your network validation scripts.
9. Design Recommendations — Consultant Level
- Migrate to SR-MPLS first, SRv6 later — SR-MPLS reuses existing MPLS hardware and IS-IS/OSPF infrastructure. It delivers immediate operational benefits with minimal risk. Plan SRv6 as a Phase 2 for cloud-native core and MEC deployments where IPv6 underlay is already in place.
- Define SRGB as an organisational standard — document the SR Global Block (e.g. 16000–23999) and enforce it across all routers via configuration templates. Never allow different SRGB ranges in the same IS-IS domain.
- Pin all adjacency SIDs used in SR Policies — never use dynamic adjacency SIDs in explicit SID lists. The operational risk of SID change after maintenance is too high. Most platforms support static adjacency SID allocation — use it.
- Enable TI-LFA on all SR nodes from day one — TI-LFA provides automatic topology-independent FRR without bypass tunnel pre-configuration. It replaces RSVP-TE FRR entirely and is simpler to operate. Verify coverage > 99% across all prefixes post-deployment.
- Integrate SR with a PCE/SDN controller — the full value of SR is realised when path computation is centralised. Deploy a PCE (e.g. Cisco SR-PCE, Nokia WavePath, or open-source ONOS/Goldstone) that has real-time topology awareness and can push SR Policies to ingress PEs dynamically based on traffic conditions.
- Use Binding SIDs to abstract SR Policies — expose SR Policies to the RAN domain as Binding SIDs. The CU-UP or PE marks enterprise traffic with a specific DSCP/VRF colour, and the SR policy automatically steers it to the correct path. This decouples RAN configuration from transport path decisions.
- Plan TE metrics carefully — SR path computation uses TE metrics, not IGP metrics. Set TE metrics to reflect actual latency and capacity on each link. Wrong TE metrics result in PCE computing paths that look optimal on paper but perform poorly in practice.
10. Summary — Practical Takeaways
Segment Routing is not hype. It solves a real and painful scalability problem with RSVP-TE that every operator with a large 5G deployment will encounter. The elimination of per-flow state from core routers, the ability to change traffic paths from a single ingress PE, and the clean integration with SDN controllers are genuine operational improvements — not marketing.
SR-MPLS is the right first step for any operator running an existing MPLS network. It is low-risk, hardware-compatible, and delivers immediate simplification. SRv6 is the right long-term direction for operators building cloud-native infrastructure, but it requires IPv6 readiness and hardware assessment before committing.
The field issues to watch are SRGB consistency, adjacency SID stability, TI-LFA coverage completeness, and PCE health. Get these right from day one and SR will make your transport operations significantly simpler than RSVP-TE ever was.
| Takeaway | Action |
| SR eliminates per-flow state from core routers | Start SR-MPLS migration planning — assess IS-IS SR capability on all routers |
| SRGB must be consistent across the domain | Define SRGB as an org standard, enforce via provisioning templates |
| Pin adjacency SIDs in all SR Policies | Never use dynamic adj-SIDs in explicit SID lists — pin them in router config |
| TI-LFA replaces RSVP-TE FRR | Enable TI-LFA globally, verify > 99% prefix coverage post-deployment |
| PCE is a first-class network element | Monitor PCE health, TED freshness, and path computation latency continuously |