Why architecture matters here
The architectural payoff of moving path state into the packet is that the network core becomes stateless with respect to individual paths. In an RSVP-TE MPLS network, every router on every engineered path holds tunnel state; adding a service or rerouting around a failure means signaling that state across the whole path, and the number of tunnel states grows with the number of paths times the number of hops. SRv6 keeps per-path state only at the ingress; transit nodes hold nothing beyond ordinary routing to the locators. That is why SRv6 scales to fine-grained traffic engineering and per-flow steering that would drown a signaled-tunnel core: the state that used to live in N routers now lives in one header.
The second reason the architecture matters is service programming. Because a SID can encode not just 'go here' but 'go here and do this' — decapsulate into a VPN, steer through a firewall, cross a specific link for latency — SRv6 unifies traffic engineering, VPNs, and service chaining into one mechanism. A service function chain that traditionally required a separate overlay (NSH, policy-based routing hacks) becomes an ordered SID list: firewall SID, then DPI SID, then delivery SID. One data plane, one header, expresses 'take this path and traverse these services and land in this tenant's table'. That consolidation is the strategic argument operators make for SRv6 over stitching multiple overlays together.
The third reason is that SRv6 runs on the IPv6 data plane you may already deploy, so transit devices that merely forward on the destination address need no SRv6 awareness at all — they route the packet toward the current active SID as if it were any IPv6 destination. This incremental-deployment property, plus the ability to use the vast IPv6 address space to encode instructions, is what made SRv6 attractive enough for large operators to build production backbones on it. But the same properties impose real constraints — header size, hardware SID-processing depth, MTU — that you must design around, which is exactly why understanding the machine, not just the marketing, is the difference between an elegant fabric and a mystery of dropped jumbo flows.
The architecture: every piece explained
Top row: how a packet gets its path. The ingress node (the SR source, often a provider edge router) classifies a flow and imposes a segment list — either by adding an SRH to the packet or, for native SRv6, by encapsulating the original packet in an outer IPv6 header whose destination is the first SID and whose SRH carries the rest. The SRH is an IPv6 routing extension header holding the ordered list of SIDs and a segments-left counter that points at the currently active segment. The active SID is copied into the IPv6 destination address, so ordinary forwarding carries the packet toward the node that owns it. A SID is Locator:Function[:Args]: the locator is a routable prefix advertised by the owning node; the function is the behavior to run on arrival. Transit nodes that are not the destination just forward on the IPv6 destination — no SRv6 processing, no per-path state.
Middle row: the instruction set and its containers. When a packet reaches the node owning the active SID, that node executes the endpoint behavior encoded in the function: End decrements segments-left and updates the destination to the next SID (plain 'continue'); End.X forwards out a specific adjacency (link-level steering for TE); End.DT4/End.DT6 decapsulate and look up the inner packet in a specific VRF table (the L3VPN delivery behavior); End.DX variants cross-connect to an attachment circuit. TE policy is how an operator expresses an explicit path as a SID list to satisfy a latency or disjointness constraint. Because full 128-bit SIDs are large and a list of them can bloat the header, micro-SIDs (uSID) pack multiple short SID 'IDs' into a single 128-bit container, dramatically shrinking the header for long paths — a practical necessity on real backbones.
Bottom rows: control and exit. The control plane computes and distributes paths: an IGP (IS-IS or OSPFv3) advertises locators and supports flexible algorithms (flex-algo) that let operators define custom shortest-path metrics (low-latency, specific link colors) so a plain destination SID can already follow an engineered path; BGP distributes VPN and service SIDs; a PCE can compute explicit, constraint-satisfying paths centrally. The egress node executes the final delivery behavior — decapsulate and forward the inner packet to the customer. The ops strip names the constraints that actually bite: MTU budgeting for the added header bytes, SID-list planning within hardware processing limits, flex-algo design, and awareness of each platform's maximum SID depth.
A word on how the SRH advances, because it is the mechanical heart of the model. The header carries the SID list as an array and a segments-left index that starts at the last segment and counts down. At each SID-owning node, the endpoint behavior decrements segments-left and copies the now-current SID from the list into the IPv6 destination address; forwarding then carries the packet toward that new destination. When segments-left reaches zero the final behavior runs — typically decapsulation and delivery. So the list is walked from the back, one instruction consumed per owning node, with the IPv6 destination field acting as the 'currently executing instruction' the ordinary forwarding plane already knows how to route on. That reuse of the plain destination field is precisely what lets unaware transit routers participate without any SRv6 logic at all.
End-to-end flow
Follow an L3VPN packet across an SRv6 backbone with a low-latency requirement. Two customer sites, A and B, are attached to provider-edge routers PE1 and PE2; the customer buys a premium service that must traverse the network's lowest-latency path, and PE2 places B's traffic in VRF blue. BGP has distributed PE2's delivery SID — a locator owned by PE2 with function End.DT4 bound to the blue VRF — to PE1. The IGP runs a flex-algo 'algo 128 = minimize latency', and PE1 has computed the low-latency path to PE2's locator as passing through core nodes P1 and P3 rather than the default shortest hop-count route through P2.
A packet from site A arrives at PE1. PE1 classifies it to the premium service, encapsulates it in an outer IPv6 header, and imposes a segment list: [P3-viaflexalgo, PE2::End.DT4-blue] — or, using flex-algo, possibly just the single destination SID whose locator is reachable only via the low-latency algorithm topology. Say the operator wants an explicit waypoint for disjointness, so the SRH lists an intermediate SID at P3 and the final delivery SID at PE2. Segments-left starts at 1, the active destination is P3's SID.
The packet forwards as ordinary IPv6 toward P3's locator; P1 and P2 en route hold no per-flow state and simply route on the destination address. At P3 — the node owning the active SID — the endpoint behavior End executes: segments-left decrements to 0, the destination address is rewritten to PE2's End.DT4 SID, and the packet continues. It arrives at PE2, which owns that final SID; the End.DT4 behavior fires: PE2 decapsulates the outer header, uses the function's table binding to look up the inner IPv4 packet in VRF blue, and forwards it to site B. The customer's packet crossed an engineered, latency-optimized, VPN-isolated path — and not one core router held tunnel state for it; the path lived entirely in the header PE1 wrote.
Now a failure: link P3–PE2 goes down. The IGP reconverges; PE1's flex-algo computation for PE2's locator updates to a new low-latency path, and subsequent packets get a new segment list. For sub-50ms protection before convergence, TI-LFA (topology-independent loop-free alternate) pre-computes a backup SID list that the failing node's neighbor pushes to steer around the break — SRv6's fast-reroute story, again expressed as SIDs rather than signaled backup tunnels. Throughout, the header carried the intelligence and the core stayed stateless, which is precisely the property that let this scale.
It is worth pausing on what did not happen in that walk, because the absences are the architecture. No router signaled a tunnel to any other router. No transit node was configured with, or even aware of, the customer's VPN. No soft state was refreshed on a timer, and no state teardown was required when the flow ended — the flow simply stopped, and because nothing held per-flow state, nothing had to be cleaned up. The path's entire intelligence existed for the lifetime of each packet, in that packet's header, and evaporated with it. That is the property that lets one controller express millions of distinct engineered paths across a core that scales with topology size rather than with path count — the same reason a stateless HTTP tier scales better than a stateful one, applied to the network fabric itself.