1 / 11

Loop protection and IPFRR

Loop protection and IPFRR. Alia Atlas Stewart Bryant Mike Shand. Loop-prevention techniques under discussion. PLSN oFIB Tunnels? There are many cool things you can do with tunnels, but… Ubiquitous tunnelling is coming, but not yet Really need a solution now!

vern
Download Presentation

Loop protection and IPFRR

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Loop protection and IPFRR Alia Atlas Stewart Bryant Mike Shand

  2. Loop-prevention techniques under discussion • PLSN • oFIB • Tunnels? • There are many cool things you can do with tunnels, but… • Ubiquitous tunnelling is coming, but not yet • Really need a solution now! • We won’t consider tunnels for loop-prevention

  3. Applications • Planned operational maintenance for topology changes • including metric changes for TE purposes • Unplanned changes (i.e. failures) • IPFRR • MPLS FRR • I.E. loop free convergence is an IETF matternot just an IPFRR local matter

  4. PLSN characteristics • Around 80% protection • But VERY topology sensitive • On average prevents 50% of current loops • Computed per prefix • Completed in 3 worst case FIB times • 2 without type B • Deals naturally with SRLG • Albeit, with reduced protection • Good correlation with LFA • Partial coverage poor for managed change

  5. oFIB characteristics • 100% protection • Simple computation for single link or node change • SRLG requires computation per failed link (worst case) • Adds optimizing message to obtain sub-second convergence • Worst case if all messages lost is up to network diameter (worst case) FIB times. • Doesn’t build on PLSN • Handles managed changes and single failures completely. • Messages add some implementation complexity

  6. Management application constraints • Really need 100% coverage for management changes • Otherwise they are not benign • SRLG not an issue – because you can always decompose into constituent links • Points to oFIB

  7. IPFRR application constraints • For “basic” IPFFR PLSN fits well • Coverage is correlated • But oFIB is better because it has 100% coverage • Of course, an incomplete IPFRR mechanism means that a longer convergence may be of concern. • For any complete fast reroute method 100% loop prevention is highly desirable.

  8. IPFRR technologies under discussion • “basic” (LFAs) • Not-via

  9. LFA charactersitics • Only 80% (65% to 95%) coverage • Good in highly meshed topologies • Poor in “ring” topologies • Difficult to ensure particular “customers” get good service • Even when so engineered, a single failure may break it for subsequent failures

  10. 100% coverage in all cases Intuitive repair paths Next best path Close to path used after re-convergence Requires tunnels But combining with LFAs reduces the volume of tunnelled traffic in most topologies Only required at protecting nodes, not all nodes on repair path Computational complexity about an order of magnitude worse than normal SPF Not-via typically < 100mS compute Slightly longer for complex SRLGs Requires an extra (private) address per interface Can assign a “group” to a router and allow automatic allocation. Not-via characteristics

  11. Discussion?

More Related