Skip to content

LDP vs. segment routing: The evolution of mpls in modern networking

Introduction 

In the world of networking, there has been a constant evolution of technologies and protocols to improve efficiency and accommodate the growing needs of an ever-expanding digital landscape. Multiprotocol Label Switching (MPLS) has been a key component in this arena, providing efficient traffic engineering and ensuring high-performance networks. Label Distribution Protocol (LDP) was the initial method for label distribution in MPLS networks, but Segment Routing (SR) has emerged as a more modern, flexible, and scalable solution. In this blog post, we'll explore the narrative of LDP and Segment Routing, examining why LDP made sense, why it struggles today, and how Segment Routing has improved on LDP. 

Why LDP Made Sense 

LDP was introduced in the late 1990s as the primary protocol for distributing labels in MPLS networks. It enabled routers to exchange label bindings for routes, making the forwarding process more efficient. The use of a separate protocol instead of piggybacking on the IGP probably made sense in its day because a) IGPs weren't routinely extended with additional information and b) additional protocols were routinely deployed. Both ATM and Frame Relay were widely used and they had separate signalling protocols. 

Why LDP Struggles Today 

As networks grew in size and complexity, LDP began to show its limitations. LDP is very inefficient, deploying locally significant labels. Label 16 on R1 might map to Label 18 on R2 and Label 22 on R3. These label "swap" relationships are elements of state that the devices need to keep track of. 

Modern networks are often designed with multiple redundant paths between pairs of points. This is especially true for Fabric based (CLOS, Fat Tree or Leaf and Spine architectures). Resources that allow for loadbalancing across these equal paths (known as Equal Cost Multipath, ECMP) are also poorly consumed by LDP. 

LDP also requires a separate protocol to be established and maintained. The data exchanged between LDP points must also be synchronised between LDP and IGP tables, which at best, consumes resources and at worst, get out of sync and create devilishly difficult issues to troubleshoot. 

As if these issues weren't enough, trying to force the network to use distinct paths (traffic engineering) for different traffic classes required yet another protocol to be deployed (commonly RSVP-TE), as LDP doesn't have a mechanism to allow the source to specify a path. RSVP-TE is a really clumsy protocol with significant issues. It doesn't support ECMP. It requires traffic to be routed into tunnels that are statically provisioned and permanently deployed, even when transient conditions don't warrant it. Traffic engineering is so clunky, real world network used it only in a subset of situations; where sub-50msec failure handling is required. 

How Segment Routing Improves on LDP 

Segment Routing (SR), by contrast, reuses a protocol that's deployed in all modern networks; the Interior Gateway Protocol. It uses globally significant Prefix Segment IDs (SIDs) that do not require any label operation as the frame traverses the network. As SR uses the IGP there's no requirement for any syncing with the IGP. It's resource efficient, ECMP aware, simple to traffic engineer and best of all, it was really simple to configure and drop in as a replacement to LDP. Best of all, the migration and interoperability in brownfield network is really good. It's supported by all major Service Provider hardware manufacturers (Arista, Cisco, Juniper, Nokia, etc) and is considered current technology (no bleeding edge code deployments required). 

We believe that Segment Routing is the only sane option and would strongly recommend all of our customers use it. If LDP has been deployed, the effort of migrating to Segment Routing is not significant and, perhaps the only challenge is understanding a few basic concepts. We have a wealth of webinar recordings on all things segment routing and encourage you to take a look if that's a concern.