Segment Routing: The Journey Back Home

In December 1995, the IETF published RFC 1883, Internet Protocol Version 6. A reasonably modest size document, clearly articulating a focus on expanded addressing, IPv4 header format simplification, improved support for options, flow labeling, authentication & privacy. As the years went on, a good number of people started to see IPv6 as the basis of the next-generation Internet Architecture, with true end to end: no network address translation etc. In February 1997, the IETF published the informational RFC, 2105, Cisco Systems’ Tag Switching Architecture overview, as the industry scrambled for increased performance (and eventually traffic engineering) to support an exploding Internet. Over the years that followed, MPLS emerged, and the idea of a label, that had the semantics placed on it by a control plane, took off as an interesting idea. IPv4 was patched with bandaids, is still widely used today, though IPv6 is definitely growing, and the last 20 years of Service Provider routing, at least, has been dominated by IP/MPLS. 

Which brings us to Segment Routing (SR), the current hot topic in networking, and the presumed future of Service Provider routing, at least. The three most commonly stated benefits of SR are:

  • Elimination of IP/MPLS control plane protocols such as LDP & RSVP-TE
  • Step-function improvement in scalability, seen as critical when 5G picks up
  • An end-to-end approach to IT architectures: from server to server, from server to handset, etc.

Get rid of LDP & RSVP-TE and you are halfway to getting rid of MPLS. The industry calls this SR MPLS. Replace the MPLS forwarding plane with IPv6, and you’ve removed MPLS altogether. The industry calls this SRv6. IPv6 without segment routing would also remove MPLS completely. All of a sudden, it is 1995 again.

SR MPLS and SRv6 maybe a better lunch than IP/MPLS, but they are not a free lunch. Segments are advertised by routing protocols, so routing protocols need to be changed. If you look at the IETF segment routing document tracker, you will see a few other things engineers may need to consider.

Most SR deployments today are SR MPLS. A few are SRv6 based, including those found at this link. SR MPLS is a popular choice because many SP networks are IP/MPLS based today, and SR MPLS is viewed as being an easier migration than going straight to SRv6. Not only in terms of the forwarding plane but as many IP/MPLS networks are based on IPv4, a move to SRv6 is also a move to IPv6. That move from IPv4 to IPv6 has still not happened at all SPs. 

The exact timing of SRv6 being more dominant than SR MPLS is not something I am going to even attempt to forecast, well not in a public forum anyway 🙂 That change will take care of itself over time as the industry moves through standards work, the compelling reasons to move to IPv6 take hold, etc. For the sake of argument, let’s assume it happens, one day. If it does, what is the takeaway?

At the beginning of this article, I made the statement “the idea of a label, that had the semantics placed on it by a control plane, took off as an interesting idea.” That happened at a time when the industry perceived forwarding plane performance was below where it needed to be in that current moment, and where it would need to be in the future. What preceded label switching, in IP and Ethernet anyway, was a concept referred to as self-describing protocols, i.e. protocols that had specific semantics, either positionally or through something like a type, length, value construct (TLV). As you might have gathered, the MPLS idea is VERY different than what preceded it; intellectually interesting, incredibly versatile as 20 years of dominating the SP routing industry demonstrated, and full of wonderful possibilities, even today. However, it does create additional work, and some might argue complexity, in the control plane. Some have even argued in the past it created challenges with things like OAM (though there were other OAM challenges to be sure). 

In terms of additional work and complexity in the control plane, there are two things to be observed here. One, the new hot area of discussion within SR, is network programming, a sequence of “instructions” to intermediate routers. The proponents of network programming argue that network programming can be done in SRv6 with “No change to SRv6 data plane or control plane”, Cisco Systems. There is a related effort in the IETF called Service Programming, that can be applied to SR MPLS. The second thing to observe is that famous saying from one of the leading stars of the IP/MPLS era, Yakov Rekhter, who more than once said, you cannot eliminate complexity, you can only move it to a different place in the network. While I would not say with confidence that assertion is 100% true, there is a kernel of truth to it, and what SR will do, is move some of the complexity in the control plane today, to the forwarding plane; and for hybrid controller modes, maybe to the controller as well. This would happen at a time when the industry has regained its confidence that the forwarding plane has the performance it needs in the current moment, and perhaps in the future as well.

If traffic was growing at 200% per year, I doubt the industry would be having a discussion about moving more complexity to the forwarding plane. The industry would be fully focused on how to keep up with traffic demand. The nuances of COVID-19 and work from home aside, traffic is not growing at 200% per year, and to date, we have still been able to move network processing units to smaller silicon process, and gain the ability to have more gates on a die; might as well use those gates for something. There will even more gates to be used if there is a decision to cut down on QoS. Which is all to say, timing is everything, nature abhors a vacuum, we as an industry hate unused silicon capacity, and the fight between highly programmable router vendor developed silicon and merchant silicon, is not completely over, even if it has to be conceded, merchant silicon has come a long way.

Self-describing forwarding protocols was where IP & Ethernet began, and the industry is currently tilting back in that direction. The first part of that journey has started, SR MPLS. The ultimate destination is at least SRv6, where MPLS will be replaced by an IPv6 forwarding plane. There is even some work going on that implies segment routing may not be needed in some networks, at least for simple traffic steering. As mentioned before, SR MPLS is today the most common form of SR deployed today, and the journey from IPv4 to IPv6 is one that many networks have put off for decades already, and who knows how much longer they will keep putting it off. Nonetheless, it is interesting to see how the pendulum is swinging back: less control plane protocols, a single forwarding, and ultimately towards self-describing forwarding protocols. While SRv6 still has more forwarding and control plane capability/complexity than a decades ago IPv4 network, it is still a swinging of the pendulum that might fairly be called, The Journey Back Home, if not for IPv4, then ultimately, one day, for IPv6. OTOH, maybe I have just been watching too many Star Trek marathons where the crew has gone in search of Spock, the Undiscovered Country, or something else 🙂

This site uses Akismet to reduce spam. Learn how your comment data is processed.