Source routing, segments, and the two data planes

1Source routing, without the 1990s baggage

Segment Routing starts from one design choice: the sender decides the path. RFC 8402, Proposed Standard, July 2018, is the root document, and everything else in this course normatively references it.^[1] Its opening sentence is worth memorising because it is the whole model: “Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an SR Policy instantiated as an ordered list of instructions called ‘segments’.”^[1]

The second sentence is the one that sells it: “SR supports per-flow explicit routing while maintaining per-flow state only at the ingress nodes to the SR domain.”^[1] That is the difference between SR and RSVP-TE. In an RSVP-TE network every router on the path holds state for every tunnel that crosses it. In an SR network the ingress node writes the instruction list onto the packet and every other router forwards on what it reads. Nothing to refresh, nothing to re-signal, nothing to leak when a router reloads.

A segment is an instruction, not a tunnel. The instruction can be topological (“go to node 5 by the shortest path”) or a service (“look this packet up in VRF blue”). RFC 8402 splits the instantiation of that idea in two, and the definitions are verbatim: “SR-MPLS: the instantiation of SR on the MPLS data plane” and “SRv6: the instantiation of SR on the IPv6 data plane.”^[1] The SID definitions follow the same shape: an SR-MPLS SID is “an MPLS label or an index value into an MPLS label space explicitly associated with the segment”, while an SRv6 SID is “an IPv6 address explicitly associated with the segment.”^[1]

That last phrase is where most of the confusion in this course comes from and where most of its power lives. An SRv6 SID is a real IPv6 address. It is routable, it appears in a routing table, you can ping it, and an ACL can match it.^[4]

2PUSH, NEXT, CONTINUE - one table you will redraw for customers

RFC 8402 defines three primitives and then says exactly how each one is realised in both data planes. PUSH inserts a segment at the top of the list: the outermost label in SR-MPLS, the first segment in the SRH in SRv6.^[1] NEXT is verbatim: “In SR-MPLS, NEXT is implemented as a POP of the top label. In SRv6, NEXT is implemented as the copy of the next segment from the SRH to the destination address of the IPv6 header.”^[1] CONTINUE is verbatim too: “In SR-MPLS, the CONTINUE operation is implemented as a SWAP of the top label. In SRv6, this is the plain IPv6 forwarding action of a regular IPv6 packet according to its destination address.”^[1]

Behind all three sits the single most useful sentence in the document: “Active Segment: … In the MPLS data plane, it is the top label. In the IPv6 data plane, it is the destination address.”^[1] If a learner only remembers one line from this module, make it that one. Every later mechanism - endpoint behaviors, compression, service SIDs - is a variation on “what do I do when my own address shows up as the destination”.^[4]

flowchart LR
  SRC["SR source node\nPUSH"] --> T1["transit router\nCONTINUE = plain IPv6 forwarding"]
  T1 --> E1["segment endpoint\nNEXT = copy next SID into DA"]
  E1 --> T2["transit router\nCONTINUE"]
  T2 --> E2["last segment endpoint\ndecapsulate and deliver"]
  E2 --> DST["inner packet to the service"]

3The taxonomy, and the SRGB problem SRv6 does not have

RFC 8402 defines the segment types once, for both data planes: IGP-Prefix Segment (the Prefix-SID), IGP-Node Segment (Node-SID), IGP-Anycast Segment, and IGP-Adjacency Segment (Adj-SID), including parallel adjacencies and LAN adjacency segments.^[1] BGP segments - the BGP Prefix Segment and the BGP peering segments used for egress peer engineering - are section 4, and the Binding Segment is section 5.^[1] None of that vocabulary changes when you switch data planes, which is the honest answer to a customer asking whether SR-MPLS knowledge transfers. It does. The SR Policy model transfers too: RFC 9256 identifies a policy by the tuple headend, color, endpoint, where “the color is an unsigned non-zero 32-bit integer value that associates the SR Policy with an intent or objective.”^[7] Color is not QoS and not a VLAN.

What does change is label coordination. In SR-MPLS the SRGB is “a local property of a node” identifying reserved local labels for global segments, and the spec says “using identical SRGBs on all nodes within the SR domain is strongly recommended.”^[1] Anyone who has run a multi-vendor SR-MPLS design has spent a meeting on that recommendation. In SRv6 the SRGB is simply “the set of global SRv6 SIDs in the SR domain” and the SRLB is “a set of local IPv6 addresses reserved for local SRv6 SIDs.”^[1] There is no range to negotiate, because the identifiers are addresses and you already have an address plan.

Address space is the SRv6 version of that conversation instead. RFC 9602 (October 2024) had IANA assign 5f00::/16 for “Segment Routing (SRv6) SIDs”, allocation date 2024-04, so that packets carrying SIDs can be identified and filtered at a domain edge and the domain can “fail closed”.^[8] It is available, not mandatory - and in practice you will meet ULA blocks: fcbb::/16 in Cumulus Linux^[10] and fcbb:bbbb:1:: style locators in FRR’s own output examples.^[15]

4Three node roles: who actually needs SRv6

RFC 8754 section 3 names exactly three roles: the SR source node, the transit node and the SR segment endpoint node.^[2] The source node imposes the segment list. The segment endpoint node is the one whose local SID matches the destination address, and it runs the endpoint processing that decrements Segments Left and copies the next segment into the destination address.^[2] The transit node does nothing SR-specific at all: it is an IPv6 router forwarding an IPv6 packet on the destination address.^[2]

That is the single most valuable architectural fact for a Dell OEM conversation, and it is why the lab for this lesson deliberately puts a vrnetlab/dell_sonic:4.5.1 node in the middle of the path. Dell’s published Enterprise SONiC Distribution Compatibility Matrix 4.4.0 contains no occurrence of SRv6 or segment routing in its feature rows, and whether 4.5.x adds any is unverified because the 4.5 matrix sits behind the Dell Digital Locker login.^[12] None of that stops the node from being a legitimate hop, because a transit node is only required to forward IPv6.^[2][11]

The same logic explains the architecture NVIDIA documents on the switch side, verbatim: “The NICs connected to the switch fabric perform SRv6 origination and termination, and the switches act as SRv6-aware nodes.”^[10] The endpoints are the interesting devices; the fabric mostly routes.

sysctl -w net.ipv6.conf.all.seg6_enabled=1 net.ipv6.conf.eth1.seg6_enabled=1
ip -6 route add 2001:db8:beef::/64 encap seg6 mode encap \
  segs fcbb:bbbb:2::1,fcbb:bbbb:3::100 dev eth1

5What it costs: 4 bytes a label against 16 bytes a segment

The comparison table below is the one to have ready. Every row is sourced, and the row customers fight about is the header cost.

The arithmetic behind the cost row: an outer IPv6 header is 40 bytes, the SRH base is 8 bytes, and each segment adds 16 bytes.^[2] So a three-segment encapsulation costs 96 bytes of overhead where a three-label MPLS stack costs 12, because each MPLS label stack entry is 4 octets.^[14] Against RFC 8200’s floor - “IPv6 requires that every link in the Internet have an MTU of 1280 octets or greater” - that is real budget, and it is spent on every packet.^[6]

Two things close the gap and both are recent enough that customer documentation has not caught up. RFC 9800 (June 2025, Standards Track) specifies compressed segment list encoding and updates RFC 8754, which is what lets several segments share the 128 bits you were already paying for.^[5] And RFC 9855 (October 2025) finally made TI-LFA a Proposed Standard, which retires the “we do not deploy pre-standard features” objection that had blocked it for years.^[9] Lesson 2 spends the MTU budget byte by byte; lesson 4 gets most of it back.