This post originally appeared in Human Infrastructure Magazine, a weekly newsletter included with a free membership to Ignition, our membership site.
Old timey network engineers might remember source routing. By default, we turned it off as a security risk, mitigating a potential MitM attack. Best path routing or bust, baby.
Sadly, best path routing isn’t sufficient for many networks. Artisanal routing techniques are all the rage, often to meet service chaining needs.
Two emerging artisanal techniques are Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6). As Segment Routing is the new hotness, let’s squint at these two approaches.
SR-MPLS Vs. SRv6
Both SR technologies encode path information in the packet, but each one does it differently.
- SR-MPLS uses a label stack to describe the desired path through the network. Label Switch Routers observe the label, pop it, and forward.
- SRv6 uses a Segment Routing Header (SRH) embedded in an IPv6 packet to describe the desired path through the network. SRH-aware nodes read the header, update a pointer, swap the destination address, and forward.
Both SR approaches require little of the routing infrastructure itself. No SR state is maintained in the core network, as each packet has forwarding instructions embedded in it.
Instead, an edge router, or possibly a controller, creates the paths and encodes the label stack or SRH in the packet before it’s sent into the core.
SRv6 Adoption Challenges
SR-MPLS has seen some adoption, particularly among service providers. SRv6, however, lags. Why? In a nutshell, hardware.
SR-MPLS asks nothing special of ASICs when it comes to forwarding. There’s a label. Perform a lookup. Pop the label. Forward the packet. Yes, there is control plane software specific to SR-MPLS, but that doesn’t impact the ASIC’s ability to forward packets. As a result, SR-MPLS has relatively low adoption costs.
By contrast, SRv6 asks something special of ASICs. The SRH is a new IPv6 header to interact with, and it’s still an IETF draft. SRv6 nodes must take several actions along an SR path, including reading the SRH, re-writing the IPv6 destination field to the next node in the path, updating a pointer, and performing a node-specific action.
None of these requirements are insurmountable, but as with any new packet-level technology, asking ASIC designers to commit features requires serious customer demand. Why bake features into silicon that no one will use?
Ameliorating the situation somewhat is that non-SRv6 capable routers forward the packet normally, ignoring the SRH. Not every network node must cope with the SRH.
Hardware & Software Support For SRv6
Thus far, I’ve found evidence of SRv6 support in Cisco’s NCS5500 and Nexus 9300GX, and in Barefoot Networks’ programmable Tofino chip. In addition, I found a rumor that Juniper might support SRv6 in its Penta chip. That makes sense, as the Penta is also programmable. There might be more platforms supporting SRv6 I didn’t spot.
In a Tech Field Day presentation, Cisco’s Jakub Horn stated, “Our first hardware implementation right now is on two platforms. One is the custom silicon. Second is the merchant silicon. Both are shipping right now in [IOS-XR] 6.1 release. Obviously, capability-wise, they are slightly different. Custom silicon is slightly better than the merchant…Both are shipping right now.”
In software, the Linux kernel supports SRv6 as of kernel versions 4.10 via the SREXT kernel module. That’s an option if you’d like to hack around or roll your own with a whitebox. The open-source FD.io project also supports SRv6.
Those software options sound like reasonable edge computing use cases, as service providers want to do fancy service chaining in central offices. There’s enough power in x86 paired with the right projects to handle the forwarding load in an edge scenario.
Who’s Driving SRv6?
Cisco seems to be the driving force behind SRv6. Cisco’s made a chip investment. Cisco folks have also done much work in the IETF related to SRv6, and seem tied to the FD.io SRv6 implementation.
Why? I’m not sure. In Cisco’s SRv6 presentations, the main theme is network simplification. That is, operators can deliver the same apps and services they did with an MPLS stack, only with a simpler IPv6 fabric. Cisco has all the pieces–hardware and software offerings driving a complete SRv6 solution.
Simplification is an interesting point, but I’m not sure MPLS is that complex of a problem for operators. In addition, any significant change to an SP network is going to be a slow burn. Brownfield is hard, even when new tech is installed as patches of green.
Will “simplification” drive SRv6 adoption? At the moment, I don’t see it.
What’s Next For SRv6?
I’m sorting out my opinion on where SRv6 might fit into the networking world. If you have an opinion, let me know via [email protected]. I’m writing a hoopla-free technical whitepaper on SRv6 for publication on Ignition, and my research continues.