ipfrr kvalbein

IP fast reroutesolutions and challenges : 

IP fast reroute solutions and challenges Amund Kvalbein

Outline: 

Outline Motivation for fast IP recovery What do we want? Current solutions What are the challenges?

Do we need proactive IP recovery?: 

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?: 

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: 

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): 

Interface specific routing (FIR/FIFR) Infer failures from packet flight Interface specific FIB Repair to egress

FIR/FIFR strengths: 

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: 

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: 

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: 

Not-via strengths 100% coverage Easy support for multicast traffic Due to repair to next-next hop Easy support for SRLGs …

Not-via weaknesses: 

Not-via weaknesses Relies on tunnelling Heavy processing MTU issues Suboptimal backup path lengths Due to repair to next-next hop

Multiple Routing Configurations: 

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: 

MRC strengths 100% coverage Better control over recovery paths Recovered traffic routed independently Easy support for SRLGs

MRC weaknesses: 

MRC weaknesses Needs a topology identifier Packet marking, or Tunnelling Multicast not trivially solved Number of topologies not bounded

IP redundant trees: 

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: 

Key design difference Where is recovered traffic sent Next-next hop (Not-via) Egress router (FIR andamp; MRC) This has consequences for MC support Traffic Engineering

Combining MRC and Not-via: 

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: 

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: 

Groups Intra-domain and other network environments Mike (Scribe) Tarik Audun Srihari Inter-domain Georgios (Scribe) Rudiger Amund Pierre Framework andamp; Metrics James (Scribe) Michael Josh Stein Marian