Scribd
Upload
37 views19 pages

IP Fast Reroute S: Amund Kvalbein

This document discusses IP fast reroute solutions and challenges. It outlines the motivation for proactive IP recovery due to strict delay and availability requirements. Current solutions discussed include interface specific routing, Not-via, and multiple routing configurations. The document compares the strengths and weaknesses of each approach and notes challenges including network dynamics, multicast support, more elegant support for multi-homed prefixes, and effects on traffic. The conclusion is that combining aspects of multiple routing configurations and Not-via may provide a generalized solution that addresses some challenges.

Uploaded by

Nadikattu Ravikishore
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
37 views19 pages

IP Fast Reroute S: Amund Kvalbein

This document discusses IP fast reroute solutions and challenges. It outlines the motivation for proactive IP recovery due to strict delay and availability requirements. Current solutions discussed include interface specific routing, Not-via, and multiple routing configurations. The document compares the strengths and weaknesses of each approach and notes challenges including network dynamics, multicast support, more elegant support for multi-homed prefixes, and effects on traffic. The conclusion is that combining aspects of multiple routing configurations and Not-via may provide a generalized solution that addresses some challenges.

Uploaded by

Nadikattu Ravikishore
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 19

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

You might also like