Ronald sent me an interesting question: What's the point of having a secondary path set up for a certain LSP, when this LSP also has fast-reroute enabled (for example, with the Junos fast-reroute command)?

The idea of having a pre-established secondary LSP backing up a traffic engineering tunnel was commonly discussed before FRR was widely adopted, but should have quietly faded away by now.

The Problem

Imagine an MPLS TE network without Fast Reroute (FRR) protection. When a core link in the network fails, the Label Switch Router (LSR) upstream of the failed link sends PathErr messages to all head-end LSRs using that link for traffic engineered tunnels (LSPs), causing the tunnels to be torn down immediately.

After losing the MPLS TE tunnels, the head-end LSRs have to wait for the core IGP to stabilize (the changed LSAs/LSPs have to be flooded throughout the network), rerun CSPF to find an alternate path through the network, and request an alternate tunnel with RSVP.

In the meantime, the user traffic could follow LDP-signaled LSPs (if you’re using LDP in your network); in networks using exclusively RSVP to establish LSPs, the user traffic would be dropped.

The Backup Tunnel

Prior to FRR, network operators concerned about potential service disruptions used backup MPLS TE tunnels – head-end LSR would pre-establish a second MPLS TE tunnel to the same tail-end LSR using an alternate path.

I haven’t seen an MPLS TE implementation where you could say “use an alternate path for this tunnel”. In real life, you’d have to use affinity bits, loose source routing or explicit paths to force the second tunnel onto an alternate path. You’d also have to play with tunnel metrics if you wanted the backup tunnel to be idle while the primary tunnel was active.

After the primary tunnel failure, the head-end LSR had an alternate path in its topology database; all it had to do was to switch over to the alternate path (even better, the alternate path could have been pre-installed in the FIB).

Managing manual backup tunnels is obviously a major pain; not surprisingly I haven’t seen them widely deployed.

Fast Reroute

Fast reroute (usually using facility backup defined in RFC 4090) provides a temporary detour around a link or node failure. The tunnel headends get a PathErr notification when the backup path becomes active, but the tunnels are not torn down.

With the traffic flowing over a local detour, the head-end LSRs have enough time to recompute an optimal alternate path, and change the MPLS TE tunnel path with make-before-break RSVP signaling.

Do we still need backup tunnels?

There might be corner cases where the backup tunnels would still be useful. Do you have one? Write a comment!