IP fast reroute s olutions and challenges

1. IP fast reroutesolutions and challenges Amund Kvalbein

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

3. 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

4. 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

5. 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

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

7. FIR/FIFR strengths • No tunnelling, packet marking or other special treatment of repaired traffic • Repair paths almost shortest path • Easy support for MHP

8. 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

9. 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

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

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

12. 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

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

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

15. 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

16. 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

17. 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

18. 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

19. 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 Groups