This post originally appeared in the July 30th 2020 issue of Human Infrastructure, a free newsletter from the Packet Pushers. If you’d like to get a weekly dose of commentary, links to tech blogs, and a few amusements, sign up here.
I exchanged emails with a network engineer working on a service provider network. In his estimation, “SRv6 is simply marketing snake oil that sends shivers down our data centre spines.” He wanted to get my take. We here at Packet Pushers Intergalactic have spilled digital ink and recorded some podcasts on segment routing, including SRv6.
Segment routing, SR-MPLS specifically–I get it. SRv6 and competing variants such as SRm6? I am dubious. What follows is an edited version of my thoughts from my email exchange.
Why SRv6 At All?
I have heard the vendor claim that SRv6 simplifies the transport stack, and that such simplification is a really big deal. Blah blah complexity reduction, blah blah ROI, blah blah TCO.
Perhaps, but my take is that the point of SRv6 from a vendor perspective is to move metal and create a new platform ecosystem. Cisco and Juniper (and all of them) always need new income streams, and so they want to see SRv6 adopted. Here’s my logic.
- Silicon is required to act on the Segment Routing Header (SRH) lookups and operations at scale.
There isn’t much silicon out there that can deal with SRH. The argument I’ve heard against silicon being an adoption barrier is that a core network doesn’t need every box to be able to handle the SRH. Those devices incapable of handling SRv6 will simply forward the IPv6 packet and ignore the SRH.
That feels like a hollow claim. One of SR’s big ideas is to move traffic along a carefully engineered path, so boxes that can’t participate in the scheme become potential engineering problems. Maybe I’m overthinking it.
- SRv6 headers are potentially large enough to impact payload sizes, creating transport inefficiency.
While it’s been a few months since I was paying attention, this problem is what SRm6 is all about—fixing that problem. Only now with SRm6, we’ve added a mapping function to explain what the heck the tidy SID encoded in the routing header is supposed to mean.
Wait a minute…wasn’t SRv6 broadly about making the core simpler, not needing to distribute labels? Did SRm6 just indirectly reinvent MPLS via the mapping function? How is this simpler?
- Speaking of SR-MPLS…
SR-MPLS doesn’t force hardware refreshes on those who might implement it, unlike SRv6. SR-MPLS seems a low-cost way for network operators to extract more revenue from their expensive infrastructure.
SR-MPLS works with the silicon that’s already deployed. Yes, label stack depth is a problem on some platforms, and maybe you need to add a policy controller to your core to compute label paths. Still, SR-MPLS is more immediately deployable than SRv6 or SRm6.
But from a vendor perspective, SR-MPLS doesn’t move metal. SRv6 & SRm6 do.
- There is a standards competition between Cisco (SRv6 camp) and Juniper (SRm6 camp).
In my observations of the IETF in recent years, sharp industry disagreements often come down to money. I infer that vendors must think there’s big money at stake with segment routing and SRv6.
My sense is that Cisco is slowly losing the battle, as SRv6 is a non-starter for most anyone I’ve spoken to. SRm6 seems more palatable. Even so, I don’t know of anyone on the operator side who tells me SRv6 or SRm6 solves a big problem they have.
Some have suggested that LDPv6 would be welcome, helping move to an all-v6 core while still leveraging the well-known, mature, and trusted MPLS stack operators have been using for decades now.
- So what’s going on here? What are the vendors doing?
Perhaps moving metal is only part of the vendors’ motivation. SRv6 is also a platform on which to deliver a new transport ecosystem of glitter and unicorn tears. Let’s think this through.
Assume that hardware with SR(x)6-capable silicon is the foundation of this ecosystem. Okay. Gotta program those SR paths, though. How will those paths get programmed? Oh, our vendors will sell us clusters of fancy SDN controllers to figure out the paths based on policies you’ll write–see how much flexibility you get?
Then you’ll be on your way to packet-by-packet path engineering nirvana in a brave new IPv6 world. Oh, and did your rep mention how much simpler this all will be without that nasty MPLS core? Seriously, so much simpler! No state maintenance in the core! Boo-freaking-YA!!
By the way…the controller software running on the policy engine clusters–which you’ll have to distribute several of regionally and globally, of course–will be robust and bug-free. And, um, just the tiniest bit proprietary. I mean, they’ll say multi-vendor, right? But what will that actually mean? Never quite what you want it to.
Let’s face it. Vendors hope to lock you into a new SR ecosystem by helping you build some bonkers application that makes you enough revenue that the thought of dismantling it is unthinkable. If I was a vendor, I’d contribute as much as required to the IETF to meet Big Spendy Customer’s RFP requirements, but what I really want to do is lock you in. Recurring revenue and handcuffed customers drive shareholder value, and Wall Street is merciless and demanding.
- What do you mean you don’t need all this SRv6 stuff?
You heretic. Aren’t you deploying 5G? Of course you need it! Shun the non-believer! Shuuunnnnn…
Ahem.
While some of that rant is–arguably–hyperbole, I believe it’s how vendors think as they compete for fewer customers and less greenfield. Did we mention the looming specter of disaggregation and whitebox? That tech is not taking the place of big iron core routers, but it’s certainly chipping away at revenues earned from the SP market.
SR(x)6 is one way vendors can keep us buying stuff. And if the vendors do it right, maybe they can tie us down for a few years with a system we can’t escape.
Or maybe I’ve got it all wrong. I admit I got up on the cynical side of the bed this morning.
