SRv6: what is Segment Routing for IPv6 and why operators are already migrating
In network operator forums over the past few years, SRv6 has gone from being a standards proposal to a technology running in production. At RIPE SEE 14 and NANOG 96, multiple operators presented real implementations: migrations from MPLS to SRv6, L3VPN deployments over SRv6, and traffic engineering use cases that previously required complex MPLS infrastructure.
For network operators in Latin America, the time to understand SRv6 is now: not to deploy it tomorrow (in most cases it’s not yet the right moment), but to put it on the planning radar and understand how it affects the equipment and architecture decisions being made today.
The problem with MPLS that SRv6 addresses
MPLS has been the dominant transport protocol in ISP cores for over twenty years. It works well for what it was designed to do, but it has operational frictions that become more visible as networks grow:
Complex control plane: MPLS requires additional protocols for label distribution: LDP (Label Distribution Protocol) or RSVP-TE for traffic engineering, on top of the underlying IGP. Each of these protocols has its own state, its own convergence process, and its own set of debugging tools. The protocol overlay is a permanent source of operational complexity.
RSVP-TE doesn’t scale well: To do traffic engineering in MPLS (rerouting traffic through specific paths to optimize utilization), RSVP-TE is used. The problem is that RSVP-TE is a stateful protocol on every node in the path: each router along the LSP (Label Switched Path) must maintain information about that tunnel. In networks with many TE tunnels, this becomes a scalability and stability issue.
Interoperability and extensions: Adding new behaviors in MPLS (new actions on intermediate nodes) generally requires new label types or new protocol extensions, with the corresponding standardization process.
End-to-end visibility: In classic MPLS, the only header visible on intermediate nodes is the label. The traffic debugger sees the label but not necessarily the complete flow context.
SRv6 doesn’t solve all of these problems at once, but it addresses the most fundamental ones in an elegant way.
What is Segment Routing
Segment Routing is a network architecture paradigm based on a simple idea: instead of each node along the path making forwarding decisions based on local tables (the classic MPLS model), the ingress node specifies the complete path by encoding it in the packet itself.
The path is encoded as a list of segments. Each segment is an instruction: “send this packet to this node,” “take this egress interface,” “apply this service.” Intermediate nodes simply follow the instructions in the header, without needing to maintain session state or flow-specific tables.
This idea has two main implementations:
SR-MPLS (Segment Routing with MPLS labels): Segments are encoded as standard MPLS labels in a label stack. It reuses the existing MPLS dataplane with the advantages of the SR control plane. This is the adoption path for networks that already have MPLS and want to migrate gradually.
SRv6 (Segment Routing over IPv6): Segments are encoded as IPv6 addresses in a special extension header called the Segment Routing Header (SRH). It uses IPv6 as the dataplane, eliminating the need for MPLS entirely.
SRv6 in detail: how it works
The Segment Routing Header (SRH)
SRv6 works by adding a special extension header to the IPv6 packet: the SRH (Segment Routing Header, defined in RFC 8754). The SRH contains:
- Segment List: a list of IPv6 addresses, ordered from last to first (the first segment to be processed is at the end of the list)
- Segments Left: a pointer to the currently active segment
- Tag and Flags: additional metadata
The Destination Address field of the outer IPv6 header always points to the currently active segment. When a node processes the packet, it looks at the Destination Address, executes the function associated with that address, decrements Segments Left, copies the next segment to Destination Address, and forwards the packet.
SIDs: segments as functions
Each IPv6 address in the Segment List is a SID (Segment Identifier). What makes SRv6 special is that each SID is not just a destination address: it is a function that the node owning it must execute when it receives a packet with that address as Destination.
The most important SRv6 data plane functions:
End (Endpoint): The node is the segment’s endpoint. It processes the SRH, updates the pointer, and forwards to the next segment. This is the most basic SID, equivalent to “pass through this node.”
End.X (Endpoint with layer 3 cross-connect): Like End, but the node must also forward the packet through a specific interface to a specific neighbor. Useful for traffic engineering: forcing traffic to take a particular link.
End.DT4 / End.DT6 (Endpoint with decapsulation and table lookup): The node decapsulates the SRv6 header and performs a lookup of the inner address in a specific VRF routing table. This function is the foundation for implementing L3VPN over SRv6 without needing MPLS.
T.Encaps (Transit with encapsulation): The ingress node encapsulates the original packet inside a new IPv6 header with SRH. This is the function the head-end uses to initiate an SRv6 path.
The encoding of the function within the IPv6 address is not arbitrary. The SID address has a structure:
uSID: solving the overhead problem
A legitimate criticism of SRv6 in its original form is the header overhead. Each SID in the list is a 128-bit IPv6 address (16 bytes). A Segment List with 4 segments adds 64 bytes of overhead to the packet. For low-latency traffic or small payloads, this can be significant.
The solution is uSID (micro-SID), defined in RFC 9252 and quickly adopted by the major vendors. uSID compresses multiple segments within a single 128-bit IPv6 address using the 16-bit blocks of the host field:
With uSID, a single IPv6 address can encode up to 6 or 7 segments (depending on the locator size). The overhead drops dramatically: instead of 64 bytes for 4 segments, you can have 4 segments in 16 bytes (a single additional IPv6 address).
Most production implementations today use uSID. Huawei VRP 8.x+, Cisco IOS-XR 7.x+, and Nokia SR OS all have uSID support in their SRv6 implementations.
Operational use cases in production
L3VPN over SRv6 (SRv6 PE)
The use case gaining the most traction among ISPs is the implementation of L3VPN over SRv6, replacing the traditional MPLS + BGP VPNv4 combination.
In the classic MPLS L3VPN model:
- The ingress PE does a lookup in the customer’s VRF and encapsulates the packet with two MPLS labels: the VPN label (identifies the VRF on the egress PE) and the transport label (routes the packet through the MPLS core to the egress PE).
In SRv6 L3VPN:
- The ingress PE does a lookup in the customer’s VRF.
- It encapsulates the packet with a new IPv6 header whose Destination is the
End.DT4SID of the egress PE for that specific VRF. - The packet transits the core using the normal IGP (the SID’s Locator is routable).
- The egress PE receives the packet, recognizes the
End.DT4SID, decapsulates the SRv6 header, and does a lookup in the corresponding VRF.
No LDP. No RSVP. No label distribution. The VPN state is encapsulated in the SID’s IPv6 address.
Traffic engineering without RSVP-TE
With SR-TE (Segment Routing Traffic Engineering), traffic engineering is implemented without the state overhead of RSVP-TE. Instead of signaling an end-to-end tunnel with state on every node, the head-end simply includes in the Segment List the sequence of nodes or links it wants the traffic to traverse.
If you want a customer’s traffic to take the path A-B-D instead of the shortest path A-C-D, the head-end builds a Segment List with [End.X from A to B, End of D]. Intermediate node B doesn’t need to know anything about the flow: it simply processes the SRH.
Customer traffic VRF-Customer-1:
[End.X(A→B), End.X(B→D), End.DT4(D, VRF-Customer-1)]
General best-effort traffic:
[End.DT4(D, global table)] (shortest IGP path)
Service Function Chaining
SRv6 is especially well suited for programmatically inserting network functions (firewalls, DPI, CGNATs, proxies) into the traffic path. Each function is a SID that traffic must visit. The head-end builds the Segment List including the function’s SID.
SRv6 and vendors: current support status
Huawei VRP
Huawei has one of the most complete SRv6 implementations among ISP vendors. The NE series equipment (NE40E, NE8000) supports SRv6 from VRP 8.x in production, including:
- SRv6 BE (Best Effort, no TE) with End and End.DT4/DT6
- SRv6 TE Policy with node and adjacency segments
- SRv6 L3VPN (BGP VPNv4/VPNv6 over SRv6)
- EVPN over SRv6
- uSID
The access and distribution switches (CloudEngine series) have more limited support. For an ISP using Huawei in the core and distribution, the most realistic early adoption scenario is SRv6 on core PE and P routers, with access remaining on MPLS or flat routing during a transition phase.
Cisco IOS-XR
Cisco was one of the first to implement SR-MPLS in production and has extended that support to SRv6 in IOS-XR 7.x:
! Enable SRv6 on Cisco IOS-XR
segment-routing
srv6
locators
locator CORE
micro-segment behavior unode psp-usd
prefix 2001:db8:1::/48
!
!
!
!
! Configure SRv6 for BGP VPNv4
router bgp 65001
address-family vpnv4 unicast
vrf-table-label
!
!
vrf CUSTOMER-1
rd 65001:1
address-family ipv4 unicast
segment-routing srv6
locator CORE
alloc mode per-vrf
!
!
!
!
Nokia SR OS
Nokia has built its ISP portfolio (7750 SR series, 7450 ESS) with Segment Routing as a central pillar for years. SRv6 support in SR OS is extensive and includes advanced uSID and traffic engineering functions.
When SRv6 makes sense for an ISP in LATAM
SRv6 is not for every ISP today, and it’s important to be honest about that. The conditions under which SRv6 makes sense to consider in the short term:
You have core equipment that already supports it: If your core runs on Huawei NE, Cisco ASR 9000 / NCS, or Nokia 7750, the hardware probably supports SRv6 with a software upgrade. The activation cost is low.
You’re planning to replace the MPLS core: If you’re in an equipment refresh cycle, the time to evaluate SRv6 is during the design of the new architecture. It’s much harder to insert SRv6 into an existing MPLS network than to plan for it from the start.
You have VPN services you want to simplify: If you operate L3VPN for enterprise customers and the MPLS control plane is a permanent operational burden, SRv6 L3VPN can significantly simplify operations by eliminating LDP and RSVP.
You’re considering SD-WAN connectivity offerings or differentiated services: SRv6 is the natural transport plane for programmatic path orchestration, which is the technical foundation of SD-WAN and network slicing.
The conditions under which SRv6 is probably not the right priority right now:
- The network still runs stable MPLS with mid-life equipment.
- The technical team has no experience with IPv6 in production (SRv6 requires IPv6 maturity as a prerequisite).
- There is no concrete business case that justifies the adoption effort.
What we see in the field
In our consulting projects with ISPs in Latin America, SRv6 frequently comes up as a technology that technical teams want to understand but are not yet piloting. The main blocker is usually not the technology itself or the equipment (which in many cases already supports it), but the training curve and the lack of local operational references.
Adoption will accelerate over the next two to three years as the major regional carriers (who are already piloting or have SRv6 in production) begin to offer services that assume SRv6 on the access side. Regional ISPs that understand the technology will be better positioned to integrate into those ecosystems.
Learn more about our network architecture design and technical consulting services.
Want to evaluate SRv6 in the context of your network?
We can review your current architecture, identify whether your equipment is ready for SRv6, and design an adoption roadmap that fits your operational reality.
Let’s talk about your architecture →
Have questions about SRv6, MPLS, or network architecture? Write to us at [email protected] — we reply to every message.