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.
I’d love to have a further discussion on this – because – I disagree that SRm6 pushes hardware – SRv6 – certainly has major issues with regards to header sizes and all sorts of other things (aside from the fact that it fundamentally violates portions of the IPv6 specification in my view)
The differences though are more succinct than what is described here. SRv6 violates IPv6 standards – SRm6 doesn’t. SRv6 has a massive and profound impact on traffic volumes – and in some cases makes ATM look like a walk in the park – SRm6 is designed to ensure that doesn’t happen. And a few other key differences.
Will also add this – one of our use cases for SRm6 is found in the fact that certain vendors have refused to implement the TLV’s required to make SR-MPLS work on certain platforms – basically attempting to force SRv6 down peoples throats if we want it or dont want it. and SR-MPLS is something we do need and want.
Happy to discuss offline though – feel free to drop me an email
Shuuunn!!!
I forward packets based on their dst address. Maybe I’m a love child of a heretic and a dinosaur, but it seems to work out. Tbh, MPLS was the SR of the early 2000s. All in all, we’re past that age. The CPU limits of 20 years ago past are laughable now.
When it comes down to scalability, robustness and interoperability in a truly multivendor environment, one must carefully examine the good old Internet, and how it essentially gets along without label exchange or per packet path-preprogramming. Why is that everyone near the networking market tries to save the world at Layer-3?
In my prehistoric sight the network is only there to get that damn packets from A to B. If an application needs to exactly know what will happen ad which hop in the transmission path, and pre-program the nodes along the way, it simply will not scale. If an application requires end to end control over the entire communications infrastructure, it will be fragile for not being able to adapt to A constantly changing environment. it will never grow up to reach out to millions – unless the super-duper SRv6 programmable network is built by the One Provider end to end, which is kind of a challenging task to accomplish. And what is then the next step? Building p2p L2 interconnects so all applications can still use hard coded RFC1918 static addresses to talk to each other?
It’s a funny thing to see only the layer-3 things to evolve – in order we can ensure somehow the above application layers don’t have to change at all.
Thanks for the write-up, it truly made my day.
Most vendors implement what customers ask. BGP in the DC fabric comes from Microsoft and Facebook and deployed by multiple large operators. Segment routing is huge in MSDCs and SPs, and not because vendors are pushing it — these guys want a TE dataplane that they can drive from their own controllers. In my time at a vendor, I’ve actually seen the vendor trying to push back on yet another mousetrap being demanded for by every other customer. In other cases vendors are talking up the tech/designs that their most progressive customers are telling them work best for them. Maybe we’re giving vendors too much credit for all the ills in the networking industry.
This is an issue I’ve been raising more often. Customers have a responsibility to avoid/stop requesting features because vendors feel pressure to deliver them. Saying no to a customer who is waving a large purchase order around, well, thats hard to resist.
I agree with your point that SR is well suited to SDN. Using software to program flow paths is how SDN started and its seems that replacing OpenFlow with SR is a useful abstraction for a few networks. The underlying issue in Ethan’s article is that SR is limited to a few niche use cases. Possibly there are less than ten companies with networks that need these features but vendors are certainly going to sell SR to every customer.
And thats where the process breaks down. Many customers do not know what they are buying, vendors do not understand what they are selling. Selling an 18-wheeler truck as a family sedan is dumb but here we are with Segment Routing.