Segment routing: Less state, less capability. IP/MPLS RSVP-TE: More state, more capability

The Important

  • Segment routing (for MPLS) supports explicit routes with LESS STATE than IP/MPLS RSVP-TE, but WITHOUT* bandwidth reservation signaling
  • IP/MPLS with RSVP-TE supports explicit routes, with MORE STATE than Segment Routing (for MPLS), but WITH bandwidth reservation signaling

Segment routing: Less state, less capability. IP/MPLS RSVP-TE: More state, more capability.

*Not withstanding “” and management interfaces, which will be discussed below.


Two of the big levers in networks that impact performance, as experienced by the network user / application, are:

  • Path selection (routes)
  • Per hop-behaviors (PHBs)

Is it possible to support the desired outcomes of a SP, Enterprise, or other entity by using path selection alone? That is ultimately a question for network operators to answer, but Segment Routing (SR) is a tool that is optimized for exploring that question.

Whenever you are learning about SRg, one of the first things you are likely to hear is something along the lines of “Segment routing is better because it has less state and is more scalable than IP/MPLS RSVP-TE.” State (information) and scalability are two ideas that are often associated together by network professionals.

With my proclivity to view networking through an information lens, whenever someone says to me something uses less state, I generally think to myself “I wonder what it cannot do.”

This comes from the Information beliefs I have, which I am working on documenting:

To bring the conversation back to something more concrete:

No alt text provided for this image

To simplify, the above table does not consider IPv4 strict/loose source routing, IPv6, Diffserv, or BGP.

Segment routing can either push a single global label and have the packet follow the IGP shortest path/least cost route, or it can specify the explicit route. Functionality similar to MPLS LDP and similar but different to MPLS RSVP-TE, in one approach to networking, and with only extensions to routing protocols (which is believed to reduce the likelihood of synchronization problems between routing protocols and MPLS label distribution protocols).

How is this different than IP/MPLS RSVP-TE. Firstly, because SR uses global labels, a network operator has to make sure the global labels are configured the same way on each router, otherwise loops may form in the network. So that is a bit of upfront planning overhead you have with SR (let’s call it added operational complexity). WRT the central focus of this article, SR does not perform bandwidth reservation, so it is an explicit routing (optional), no bandwidth reservation paradigm, vs IP/MPLS RSVP-TE which is an explicit routing, with bandwidth reservation paradigm.

As you might imagine, there are going to be operators who go “great, segment routing is the future, all sounds good, can we please have bandwidth reservation with that.” Only one way to achieve that, add more information.

Add more information in the form of:

If SR ultimately evolves so that it can signal bandwidth reservation or a SR controller can, will that make SR redundant with IP/MPLS? No, because it provides two modes of operation, and one which is not provided optimally today. IP/MPLS RSVP-TE does support zero bandwidth LSPs, but the protocol design bears the burden of BW reservation functionality, and per-hop LSP state. If a network operator just wants to manage the network using path selection, then IP/MPLS RSVP-TE has more complexity and more state than is needed for that function, both in the initial setup, and also in network recovery. If every network operator wanted all or most LSPs to have a bandwidth reservation, then this point would be moot.

An information function should only have the necessary state. No less, no more. Everything as simple as possible, but no simpler.

SR MPLS is, today, more optimized for explicit routing without bandwidth reservation than IP/MPLS RSVP-TE. IP/MPLS RSVP-TE supports, today, bandwidth reservation signaling.

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