One of my readers successfully deployed LDPv6 in their production network:

We are using LDPv6 since we started using MPLS with IPv6 because I was used to OSPF/OSPFv3 in dual-stack deployments, and it simply worked.

Not everyone seems to be sharing his enthusiasm:

Now some consultants tell me that they know no-one else that is using LDPv6. According to them “everyone” is using 6PE and the future of LDPv6 is not certain.

During the discussion of the On Applicability of MPLS Segment Routing (SR-MPLS) blog post on LinkedIn someone made an off-the-cuff remark that…

SRv6 as an host2host overlay - in some cases not a bad idea

It’s probably just my myopic view, but I fail to see the above idea as anything else but another tiny chapter in the “Solution in Search of a Problem” SRv6 saga¹.

Henk Smit left a wonderful comment discussing various scalability aspects of SR-MPLS. Let’s go through the points he made:

When you have a thousand routers in your networks, you can put all of them in one (IS-IS) area. Maybe with 2k routers as well. But when you have several thousand routers, you want to use areas, if only to limit the blast-radius.

Absolutely agree, and as RFC 3439 explained in more eloquent terms than I ever could:

Whenever I compare MPLS-based Segment Routing (SR-MPLS) with it’s distant IPv6-based cousin (SRv6), someone invariably mentions the specter of large label stacks that some hardware cannot handle, for example:

Do you think vendors current supported label max stack might be an issue when trying to route a packet from source using Adj-SIDs on relatively big sized (and meshed) cores? Many seem to be proposing to use SRv6 to overcome this.

I’d dare to guess that more hardware supports MPLS with decent label stacks than SRv6, and if I’ve learned anything from my chats with Laurent Vanbever, it’s that it sometimes takes surprisingly little to push the traffic into the right direction. You do need a controller that can figure out what that little push is and where to apply it though.

Here’s an interesting question randomly appearing in my Twitter feed:

If you had a greenfield network, would you choose SR-MPLS, or SRv6? And why?

TL&DR: SR-MPLS, assuming you’re building a network providing end-to-end connectivity between hardware edge devices.

Now for the why part of the question:

In the Segment Routing vs LDP in Hub-and-Spoke Networks blog post I explained why you could get into interesting scaling issues when running MPLS with LDP in a large hub-and-spoke network, and how you can use Segment Routing (MPLS edition) to simplify your design.

Now imagine you’d like to offer VPLS services between hubs and spokes, and happen to be using equipment that uses targeted LDP sessions to signal pseudowires. Guess what happens next…

I got an interesting question that nicely illustrates why Segment Routing (the MPLS variant) is so much better than LDP. Imagine a redundant hub-and-spoke network with hundreds of spokes. Let’s settle on 500 spokes – IS-IS supposedly has no problem dealing with a link-state topology of that size.

Let’s further assume that all routers advertise only their loopbacks¹ and that we’re using unnumbered hub-to-spoke links to minimize the routing table size. The global routing table thus contains ~500 entries. MPLS forwarding tables (LFIB) contain approximately as many entries as each router assigns a label to every prefix in the routing table². What about the LDP table (LIB – Label Information Base)?

Years ago, I compared EVPN to SIP – it has a gazillion options, and every vendor implements a different subset of them, making interoperability a nightmare.

According to Andrew Alston, SRv6 is no better (while being a security nightmare). No surprise there.

Etienne-Victor Depasquale sent me a pointer to an interesting NANOG discussion: why would we need Segment Routing. It’s well worth reading the whole thread (until it devolves into “that is not how MPLS works” arguments), which happens to be somewhat aligned with my thinking:

• SR-MPLS makes perfect sense (excluding the migration-from-LDP fun)
• SRv6 (in whatever incantation) is mostly a vendor ploy to sell new chipsets.

Enjoy!

After I created the Segment Routing lab to test the relationship between Node Segment ID (SID) and MPLS labels, I was just a minor step away from testing BGP-free core with SR-MPLS.

I added two nodes to my lab setup, this time using IOSv as those nodes need nothing more than EBGP support (and IOSv is tiny compared to IOS XE on CSR):

In one of my introductory Segment Routing videos, I made claims along the lines of “Segment Routing totally simplifies the MPLS control plane, replacing LDP and local labels allocated to various prefixes with globally managed labels advertised in IGP”

It took two years for someone to realize the stupidity over-simplification of what I described. Matjaž Strauss sent me this kind summary of my errors:

You’re effectively claiming that SRGB has to be the same across all devices in the network. That’s not true; routers advertise SIDs and must configure label swap operations in case SRGBs don’t match.

Wait, what? What is SRGB and why could it be different across devices in the same network? Also, trust IETF to take a simple idea and complicate it to support vendor whims.

I wanted to write a “SRv6 makes no little sense” blog post for a long while, but there were always more relevant topics to focus on. Fortunately I won’t have to write it anytime soon; Ethan Banks did a fantastic job with SR(x)6 - Snake Oil Or Salvation?. Make sure you read it before attending the next “SRx6 will save the world” vendor presentation.

A while ago I made a statement along the lines of “MPLS segment routing is the best thing that happened to MPLS control plane in a decade”. Obviously some MPLS-focused engineers disagree with that and a few years ago I decided to write a lengthy blog post explaining the differences between using MPLS SR with IGP (or BGP) versus more traditional IGP+LDP approach.

Obviously, I wasn’t making any progress on that front, so the only way forward was to record a short video on the topic which didn’t work well either because the end-result was a set of three videos (available with free or paid ipSpace.net subscription).

• Principles of MPLS-based transport core;
• Drawbacks of MPLS label distribution with LDP;
• MPLS label distribution in Segment Routing

I got some interesting feedback from one of my readers on Segment Routing with IPv6 extension headers:

Some people position SRv6 as the universal underlay and overlay due to its capabilities for network programming by means of feature+locator SRH separation.

Stupid me replied “SRv6 is NOT an overlay solution but a source routing solution.”

One of my readers listened to a podcast where a $vendor described how they found another use case for source routing IPv6 segment routing (SR): 5G networks… and wondered whether SR made a comeback or is about to.

To figure out what segment routing is, watch the webinar we did with Jeff Tantsura a while ago.

I don’t know nearly enough about mobile networks to have an opinion, however…