IP fast reroute

solutions and challenges

Amund Kvalbein
Outline

• Motivation for fast IP recovery

• What do we want?
• Current solutions
• What are the challenges?
Do we need proactive IP recovery?
• Yes:
– Strict delay/availability requirements dictate a
proactive solution
– The costs of a re-convergence are too great for
transient failures

• No:
– Re-convergence is fast enough (sub-second)
– If you want FRR, use MPLS
What do we want?
Functional:
• Protect both link and node failures
• 100% coverage (?)
• Easy support for multicast traffic
• LANs, ECMP, asymmetric weights, SRLG, MPLS
• Protect multihomed prefixes if reachable
Operational:
• Smooth network dynamics / plug-and-play
• Easy integration in current routing
• Nice distribution of recovered traffic
Selected IPFRR mechanisms
• Interface specific routing (USC)
• Not-via (Cisco)
• Multiple Routing Configurations
(Simula)
• (IP Redundant Trees (Simula))
All give protection against both link and node failures
Interface specific routing (FIR/FIFR)

• Infer failures from packet flight

• Interface specific FIB
• Repair to egress
FIR/FIFR strengths

• No tunnelling, packet marking or

other special treatment of repaired
traffic
• Repair paths almost shortest path
• Easy support for MHP
FIR/FIFR weaknesses
• Not always 100% coverage
– No strategy for last-hop link failures
– Issue with looping when there are more than one
failure

• Not easy support for multicast traffic

• Little flexibility to control recovered traffic
• Difficulties with SRLGs
Not-via
• Connectionless version of MPLS-FRR
• Create special not-via addresses
• Routing to these addresses is restricted
– Avoid the failed component

• 2|E| addresses needed

• Repair to next-next hop
Not-via strengths

• 100% coverage
• Easy support for multicast traffic
– Due to repair to next-next hop

• Easy support for SRLGs

• …
Not-via weaknesses

• Relies on tunnelling
– Heavy processing
– MTU issues

• Suboptimal backup path lengths

– Due to repair to next-next hop
Multiple Routing Configurations

• Relies on multiple logical topologies

– Builds backup configurations so that all
components are protected

• Recovered traffic is routed in the

backup configurations
• Repairs to the egress node
MRC strengths

• 100% coverage
• Better control over recovery paths
– Recovered traffic routed independently

• Easy support for SRLGs

MRC weaknesses

• Needs a topology identifier

– Packet marking, or
– Tunnelling

• Multicast not trivially solved

• Number of topologies not bounded
IP redundant trees

• New method developed at Simula by

combining RT and MRC
• Fixed number of backup ”topologies”
(two trees)
• Trees are calculated per destination
Key design difference
• Where is recovered traffic sent
– Next-next hop (Not-via)
– Egress router (FIR & MRC)

• This has consequences for

– MC support
– Traffic Engineering
Combining MRC and Not-via

• If tunnelling is used in MRC, then

MRC can be seen as a generalized
version of not-via
– Freedom to repair to egress or next-next
hop
– Not-via: exclude heavily loaded links
Main challenges
• How to handle network dynamics
• MC support
• More elegant support for MHP
• Effects of FRR on traffic (TCP etc)
• Practical issues
– FIB organisation
– Traffic differentiation
Groups
• Intra-domain and other • Framework & Metrics
network environments – James (Scribe)
– Mike (Scribe) – Michael
– Tarik – Josh
– Audun – Stein
– Srihari – Marian
• Inter-domain
– Georgios (Scribe)
– Rudiger
– Amund
– Pierre