Hi all.
When the whole SR concept was being first dreamed up, I was mildly excited about it. But then real life happened and global deployment (be it basic SR-MPLS or SRv6) is what it is, and I became less excited. This was back in 2015.
All the talk about LDPv6 this and last week has had me reflecting a great deal on where we are, as an industry, in why we are having to think about SR and all its incarnations.
So, let me be the one that stirs up the hornets’ nest…
Why do we really need SR? Be it SR-MPLS or SRv6 or SRv6+?
I’ve heard a lot about “network programmability”, e.t.c., but can anyone point me toward a solution that actually does this in the way that it has been touted for years? A true flow that shows the implementation of “network programming” over any incarnation of SR? Perhaps one a customer can go to the shop and grab off the shelf?
A lot of kit does not currently support SR, be it in hardware or software. So are operators expected to dispose of boxes that are happily moving MPLS frames along with no complaints, and replace them with some newfangled creations that will support SR in code and silicon? At whose cost? Not just money, but time, people and working the day-to-day kinks out?
I’ve heard about “end-to-end service chaining” as a use-case for SR. To service-chain what? Classic telco’s don’t offer complex over-the-top services that operate at a such a scale that “service chaining” in SR would make lives easier. More than half of the traffic we are carrying is coming in over the public Internet, and not some private VPN. And if “service chaining” makes sense to the cloud and content operators who run humongous data centres where the servers significantly outnumber the routing/switching/transport gear, I’d naively posit that they have built a myriad of custom, in-house solutions, systems, tools and controllers to do all the “service chaining” they could ever need, and have been at it for more than 10 years, if not more, all to manage an MPLS/DWDM backbone. So what off-the-shelf “service chaining” controller are they going to walk into the shop and pay money for?
If I had to think of the number of network, content and cloud operators who have either said they’ve deployed some kind of SR, or intend to, you’re looking at probably 10% - 15% of a market. What about the other 85% - 90% of the operators whose requirements are so simple, thinking about dumping existing boxes, systems, tools and solutions that work very well in order to join the SR club doesn’t seem feasible. What problems are 90% of the operators running MPLS having that SR will truly fix, given that they don’t operate large, distributed data centres or have a 5G license?
What’s even more wild, is that there are equally a number of networks that are stalling IPv6 deployment, for some reason or other, meaning it will probably take us another 1 to 2 decades to see worldwide adoption of IPv6. If SRv6 or SRv6+ is “where the market is dying to go”, and a bunch of operators don’t have IPv6 in their plans, what gives?
To be clear, I’m not against SR; what has to come will come. What I am less enthused about is being forced into an all-or-nothing scenario for the going concern of my network. For those that are keen on SR, give them SR. But for those who would prefer to keep things simple in networks that are not about to fall over and die, let’s have LDPv6 and let’s implement RFC 7439.
Then let the operators choose.
On a personal note, it’s a pity Juniper gave in to the SRv6 fight, despite all the initial resistance. If they’d gone a different direction and simply implemented RFC 7439 (they have LDPv6 already), not only would that have put Cisco under serious pressure, but it would have solved the problems of many network operators that are desperately looking to go IPv6-only, and still maintain the rich MPLS services they and their customers have grown to like.
Mark.
