Behind the scenes of tech: Segment Routing, or the art of simplifying to achieve greater robustness

2026.03.05_TECHHUB SR
By Tristan Trenchand, Network Engineer

1. Why upgrade our core network?

1.1. The context

In a world where Internet traffic doubles almost every three years, performance and resilience are no longer mere objectives – they are prerequisites. And this is precisely the central role played by Internet exchange points (IXPs).

At France-IX, our ambition is clear: to guarantee our customers ever more reliable, fluid and transparent connectivity.

1.2. Our starting point

When we introduced a platform such as the Nokia 7750-SR, we had two ambitions:

  • To have a platform capable of absorbing traffic growth for several years,
  • To prepare for the arrival of new network engineering technologies.

After several years of operating peering LANs emulated using VPLS technology, we began work on introducing Segment Routing (SR). After several months of testing and validation, we migrated our core network to this forwarding technology.

2. SR, what is it?

Segment Routing (SR) is an IP packet forwarding technology that has been standardised for several years by the IETF (Internet Engineering Task Force). Based on the principle of Source Routing, it allows the source of the traffic to define the path that the packets will take, without any state being stored in the intermediate routers.

In other words: routing information travels within the packet itself.

2.1. An open, widely adopted technology

Although initially developed (and still mainly promoted) by Cisco, this technology is widely available and implemented by network equipment suppliers as well as in various open-source implementations: Cisco (IOS XE, IOS-XR, NX-OS); Juniper (JunOS); Nokia (SR-OS, SR Linux); Arista (EOS); FRRouting, etc.

The idea behind Segment Routing is to enable better control of the path taken by a data flow, while simplifying all the mechanisms used by the network.

With SR, within an operator's perimeter, it is the source router that defines the path that packets will follow. Once this path has been defined, it will be encoded in the packet headers in the form of forwarding instructions that each node on the path will be responsible for executing.

This is the primary strength of Segment Routing: no state is required within the network because all the information relating to packet routing is contained in the packets themselves.

2.2. Segments, rather than complex protocols

For those who associate the term ‘segment’ with unpleasant memories of geometry, rest assured, that is not what we are talking about here J.

We are talking about forwarding instructions. In concrete terms, these are additional headers that will be read and executed as packets progress through the network.

In SR terminology, each of these instructions is called a segment and is identified numerically by a Segment ID (SID).

The power of Segment Routing lies in the fact that each ‘instruction’ can actually represent several functions:

  • A topological function: representing a node in the network that you want to cross/reach, or a specific link that you want to use.
  • A logical function: for example, traversing a firewall service before reaching a destination. More broadly, it is the choice of a service that one wishes to use, which is encouraged by the advent of cloud-type virtual architectures.

These segments can be stacked—this is referred to as a stack—to build specific paths tailored to traffic needs or network policy constraints.

2.3. SR Data Planes: SR-MPLS ou SRv6 ?

Segment Routing currently exists in two different forms:

  • SR-MPLS, based on MPLS labels
  • SRv6, based on dedicated IPv6 headers (Segment Routing Header – SRH).

In our case, the choice was obvious: France-IX already operates a robust MPLS backbone; SR-MPLS can be integrated without any major hardware changes, while simplifying signalling.

Conversely, SRv6 may require hardware changes and is therefore less suitable for existing MPLS networks.

In this article, we will not dwell on SRv6, but please note that such a variant exists and that most of the following will also apply to IPv6 (with its specific protocol features, of course).

2.4. Why Segment-Routing: a reminder about MPLS

2.4.1. SR: towards MPLS, but better?

Segment Routing is positioned as an evolution of MPLS and its now well-known operation. MPLS works very well... but at the cost of high complexity and state volume. With MPLS, each router dynamically assigns labels to IP prefixes and announces them to its neighbours, which in practical terms means thousands of labels to maintain on large networks! This is where SR-MPLS changes the game.

Is the previous sentence not obvious? Yes, you're entitled to want a little reminder J !

2.4.2. Reminders about MPLS and parallels with Segment-Routing

MPLS (or Multi Protocol Label Switching) is a standardised forwarding technology (RFC 3031) based on label switching. The idea is to build a switching table using labels associated with each known IP prefix in the network and to route packets according to this switching table rather than according to their specific IP address. When it was first created, this approach offered many advantages, including faster processing times for IP packets by router ASICs and the ability to carry protocols other than IP.

These advantages still hold true today and are no different with Segment Routing.

To function, MPLS required at least two protocols: a routing protocol and a protocol for announcing labels to be used. This is because the entire switching table is dynamic!

Among the protocols capable of announcing MPLS labels, the most widely used today is LDP.

The operation is simple:

  • Each router allocates labels to each of the routes it considers eligible and announces them (via LDP) to its neighbours.
  • Each router builds its switching table by selecting, for each route, the label allocated by the router considered to be the Next-Hop in the routing table (built by the routing protocol listed above).

Let's imagine a simple network architecture with two PE routers (PE1 and PE2, Provider Edge, or ‘entry routers’) and three core routers (P1, P2, P3).

schéma 2.4.2 EN

In practical terms, this has worked well for many years and still works very well today. But we can do better!

You are probably wondering what the point is of involving several protocols. You may also have noticed that using dynamic (and therefore unpredictable) labels, which change with each hop, is perhaps not very intuitive or memory-efficient.

(Example: 100 routers in a network, each allocating 1 different label to the other 99 routers... 9,900 labels to store.)

Well... you're right, and others have noticed this too.

It is precisely these issues that Segment Routing addresses.

Less protocol, unique labels (well, almost).

More intuitive, clearer, simpler.

2.5. SR-MPLS: Segment-Routing simplifies everything

Now that we understand how MPLS works, let's take a closer look at the changes brought about by Segment Routing.

2.5.1. How MPLS works ‘classically’, what SR brings

One of the main changes brought about by SR is protocol simplification, eliminating the need to use a dedicated label distribution protocol: let's use the routing protocol directly! The two most widely used routing protocols (IS-IS & OSPF) support the distribution of labels used by SR.

Furthermore, the solution to the problem of dynamic labels is fairly intuitive: manually assign a label value to each router, which it will then announce to the others itself. Thus, one label = one router!

2.5.2. What results?

As an illustration, I suggest we use the previous topology.

Let's look at it from the perspective of the router on the right, PE2.

The operator (= you) manually configures a label value on the equipment, which we will arbitrarily set to 16002. This step must be repeated on all nodes in the network with a label that is unique to each node (which we will refer to as SID-PE1, SID-P2, etc. for the rest of this example).

PE2 will announce this to the routers in the network using its routing protocol and special extensions developed for SR.

Note:

Without going into too much detail about how an IGP protocol such as IS-IS or OSPF works, let's just say that they operate by propagating information about each router: a router will formalise all the data concerning it in a specific structure and send it to its neighbours, who will relay it to their neighbours, and so on.

This way, we end up with a path identical to the one in the previous example, but with one less protocol to configure and far fewer labels to store.

schéma 2.5.2

This new way of operating MPLS brings, in addition to the many advantages already mentioned, great flexibility and the possibility of implementing even more advanced techniques: traffic engineering and high availability.

3. Advanced features & use cases

Among these advanced techniques, the most popular are Traffic Engineering (SR-TE), Network Slicing (using Flex-Algo) and traffic protection (TI-LFA) features (more acronyms, great!).

We will discuss traffic protection features in more detail in the next section. For now, I will briefly describe Traffic Engineering features using an example. As for Network Slicing, I suggest we save that for a future article.

3.1. SR-TE : Simplified Traffic Engineering

Remember, you configured a static label with a unique value of 16002 on PE2, but you also did the same on all the other routers (we can refer to them as SID-PE1, SID-P3, and so on).

Let's return to the previous topology, slightly modified:

schéma 3.1

Consider that links in ORANGE will never be preferred by the routing protocol (higher metrics).

If I only place label 16002 in my headers, the traffic will go to PE2. Now, remember that these SR-MPLS labels (also called SIDs, or transfer instructions, etc.) can be stacked.

What happens if, just before label 16002, I add the label SID-P4? The traffic will go through P4 before going through PE2, even if the routing protocol does not agree.

If we consider this technique on the scale of a large network, take into account the infinite possibilities of paths (modulo the technical capabilities of each platform/ASIC), and note that it requires virtually no additional signalling or state reservation on the routers (a significant improvement in resource utilisation), we can gain a good understanding of the power of Segment Routing for directing traffic.

3.1. TI-LFA: instant traffic protection

Let's now move on to Segment Routing's other key feature, its traffic protection mechanism called TI-LFA, which stands for Topology Independent Loop Free Alternate.

I will spare you the details of the algorithm behind TI-LFA, but it is important here to have some information about so-called ‘LFA’ technologies.

In the event of a link or node failure, it is the default role of the routing protocol to detect this and recalculate new routes to carry traffic. Historically, this process could take a few seconds (which is possibly still the case today on very large networks). This results in a service interruption (even partial) while the calculation is being performed. Not really optimal, you might say.

With LFA techniques, there are two major principles.

The first is to pre-calculate an alternative path in case the nominal path fails. Of course, we want this path to be loop-free in order to properly protect traffic.

The second is to install this alternative path in the routers' Forwarding Information Base (FIB) in order to further accelerate its adoption.

🧠 To describe these two principles, the term ‘Make Before Break’ approach is often used in literature – the solution is prepared before the failure occurs.

There are different versions of ‘LFA’ techniques, each designed as an improvement on the previous one. TI-LFA is the latest and will certainly remain so.

The great advantage of TI-LFA over its two big sisters (IP LFA and Remote-LFA, from which it nevertheless borrows some algorithmic elements) is its ability to offer alternative paths without depending on the network topology, and therefore to offer solutions in 100% of possible failure cases.

This capability comes directly from the use of Segment Routing, which allows as many paths as desired to be used by stacking headers. It just goes to show that everything is connected ☺️.

schéma 3.2

⏱️ Key points:

With TI-LFA:

  • a backup path is pre-calculated;
  • and installed in the FIB for near-instantaneous failover.

This mechanism provides topology-independent protection by leveraging Segment Routing capabilities.

3.2.1. SR-TE et TI-LFA at France-IX

As you might expect, all of the technologies presented here are currently deployed at France-IX!

With the recent deployment of SR & TI-LFA on our infrastructure, the overall quality of our services has been improved.

tableau 3.2.1 EN

3.3. Segment-Routing at France-IX, what changes

The deployment of SR-MPLS and TI-LFA on our backbone has resulted in:

  • a major simplification of internal protocols,
  • accelerated network convergence,
  • better control of inter-PoP traffic,
  • and an infrastructure that is more resilient to unforeseen events.

These developments are part of an ongoing process to modernise our foundations in order to accommodate the services of tomorrow, such as EVPN, cloud interconnection and advanced automation.

4. Conclusion

Segment Routing is not just a technical evolution; it is a paradigm shift.

By simplifying traffic control while improving visibility and resilience, it is establishing itself as the foundation for next-generation architectures.

At France-IX, we have opted for a simpler, more readable and more agile backbone – to build, together, a more robust and open Internet.

Stay tuned! Other TechHub articles will soon explore SR-TE, EVPN (Ethernet VPN) and many others in detail. Let us know what you would like to hear more about!

5. Futher reading

Segment-Routing: https://www.segment-routing.net

Techniques de L’ingénieur : https://www.techniques-ingenieur.fr/base-documentaire/technologies-de-l-information-th9/routage-transport-et-diffusion-dans-les-reseaux-42289210/segment-routing-te7594/

Useful RFCs:

  • RFC 8402 (SR Architecture)
  • RFC 9256 (SR Policy Architecture)
  • RFC 8667 (ISIS Extensions for SR)
  • TI-LFA (draft)

Let's carry out your project together !

Start now