IP fast reroute s olutions 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 network environments –Mike (Scribe) –Tarik –Audun –Srihari Inter-domain –Georgios (Scribe) –Rudiger –Amund –Pierre Framework & Metrics –James (Scribe) –Michael –Josh –Stein –Marian