<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<font face="Tahoma">Hi all.<br>
<br>
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.<br>
<br>
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. <br>
<br>
So, let me be the one that stirs up the hornets' nest...<br>
<br>
Why do we really need SR? Be it SR-MPLS or SRv6 or SRv6+?<br>
<br>
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?<br>
<br>
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?<br>
<br>
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?<br>
<br>
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?<br>
</font><br>
<font face="Tahoma"><font face="Tahoma">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?<br>
<br>
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.<br>
<br>
Then let the operators choose.<br>
</font><br>
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.<br>
<br>
Mark.<br>
</font>
</body>
</html>