Transcript Not-via
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 network environments – – – – • Mike (Scribe) Tarik Audun Srihari Inter-domain – – – – Georgios (Scribe) Rudiger Amund Pierre • Framework & Metrics – – – – – James (Scribe) Michael Josh Stein Marian