Devil's Advocate - Segment Routing, Why?

Wed Jun 17 17:06:35 UTC 2020

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200617/efc6e351/attachment.html>