On Improving the Efficiency and Manageability of NotVia

1. On Improving the Efficiency and Manageability of NotVia Ang Li†, Pierre Francois‡, and Xiaowei Yang† †UCIrvine ‡ Université catholique de Louvain CoNext 2007 12/13/07 New York

2. Outline • Introduction • Background on IP Fast Reroute • Problem statement • Our solutions • Evaluation • Conclusion

3. 2095 856 700 260 233 1295 639 548 587 366 846 902 1893 1176 Routing Convergence Causes Packet Losses Convergence! (sub-second) X

4. 2095 856 700 SV NY SV NY SV NV 260 233 1295 639 548 587 366 846 902 1893 1176 IP Fast Reroute Reduces Packet Losses X Failure detected! (≈10ms)

5. Considered IPFRR Techniques • Loop-Free Alternates (LFA) • Lightweight • Problem: no full protection coverage • NotVia address (NotVia) • Used when LFA does not apply • Full coverage • Overhead

6. 2095 856 700 SV NY 260 233 1295 639 548 587 366 846 902 1893 DV NVDV->KA 1176 IPFRR with NotVia Address NVDV->KA X • Announce the NotVia address • Each router computes a nexthop for the address • When failure happens, encapsulate • packets with the address

7. Problem Statement • NotVia’s overhead • Memory overhead • Computational overhead • Not management-friendly • Operators do not know the protection paths • Details in the paper

8. 2095 856 700 260 233 1295 639 548 587 366 846 902 1893 1176 Memory Overhead • Extra FIB entries # of extra entries = # of unidirectional links unprotected by LFA

9. Computational Overhead • Computational overhead • Extra SPT computations • Each router needs to compute one SPT for each NotVia entry • Up to 20ms for one SPT in a Tier-1 ISP • Up to 20s in a topology with 1000+ links • NotVia entries updated to the linecards • It may result in… • Protection restoration time t2 can be long • Resources are consumed when needed by other more urgent processes

10. Outline • Introduction • Our solutions • Evaluation • Conclusion

11. Contributions • We make NotVia more practical • NotVia aggregation to reduce memory overhead • Prioritized computation to reduce computational overhead • rNotVia algorithm to obtain protection path information (in the paper) • Simple & local techniques

12. 2095 856 700 260 233 1295 639 548 587 366 846 902 1893 1176 1. NotVia Aggregation Observation: very often, nexthop(NV)= normal nexthop(NV’s originator) NVDV->KA

13. How can we Reduce Overhead? • NotVia aggregation • Assign the NotVia addresses from the originator’s prefix • Do nothing when the nexthops are the same • Install more specific entries only when nexthops are different • For instance, 10.0.0.0/8 for Kansas City 10.0.0.1 for NVDV->KA • Aggregation saves • FIB memory on linecards • Processing: less entries to be managed by the RIB and FIB processes

14. 2095 856 700 260 233 1295 639 548 587 366 846 902 1893 1176 2. Prioritized NotVia Computation Problem: how can a router first compute the necessary NotVia entries? NVDV->KA

15. Prioritize NotVia Computations • Compute closer NotVia addresses first • Observation: protection paths are close to the not-via link • Prioritization reduces the time to restore NotVia protection • Because the protection is restored after all necessary NotVia entries are generated

16. Outline • Introduction • Our solutions • Evaluation • Conclusion

17. Data sets and Methodology • Topologies • 5 real ISP topologies • Real configured metrics • From small ones to a Tier-1 ISP (with over 400 nodes) • Synthesized topologies from BRITE • Customized simulator • Most results not related with simulator implementation

18. Effectiveness of Aggregation 140+ nodes, 400+ links

19. Effectiveness of Prioritization

20. Outline • Introduction • Our solutions • Evaluation • Conclusion

21. Conclusion • NotVia provides full coverage, but… • Introduces memory and computational overhead • Not management-friendly • We optimized it with simple techniques • NotVia aggregation • Prioritization • rNotVia • Evaluation on real topologies suggests they are effective

22. Thank you! • Questions?

23. rNotVia Efficiency

24. S D S D IPFRR with Loop-Free Alternate 1 R 5 1 • Two modes of LFA • Destination based: router R is S’ LFA w.r.t. destination D • S can reroute packets destined to D through R when link S→T fails • R will not forward the packets back to S • Link based: router R is S’ LFA w.r.t. link S→T • S can reroute any packet through R when link S→T fails • R will not forward the packets back to S • Similar scheme for node protection • LFA serves as the baseline solution of IPFRR • Easy for a router to find its LFAs • No encapsulation / packet header modification • However, LFAs may not always be available 1 1 S T D

25. rNotVia’s Applicability • rNotVia might be used to compute NotVia entries • Can further reduce # of NotVia entries! • In reality: rNotVia is heavier than current optimized SPT computation • One rNotVia(rSPT) == one normal SPT • SPT could be significantly optimized by only computing the incremental part (iSPT) • For rNotVia the optimization gain is marginal • rNotVia is only used for management • Running in low priority • When the network is stable • For reporting purposes

26. How the Distance is Measured? • IGP distance v.s. Hop distance • Hop distance is better • High link cost within PoP • Close in terms of hop count • One SPT to get hop distance • Pre-computed in low priority

27. 2095 856 700 260 233 1295 639 548 587 366 846 902 1893 1176 How does rNotVia work? XXX: no black color X X X X X

28. How Long does it take to restore NotVia protection? • Results after a link failure • Restoration time defined as the time when the last • necessary entry is computed

29. Partial NotVia Aggregation • “I don’t want the NotVia addresses to mess up with my normal addresses!” • Solution: announce a new dedicated prefix – “NotVia prefix” • Assign NotVia addresses from the NotVia prefix • Do nothing when the nexthops are the same • Always install an entry for each NotVia prefix • Assign nexthop(NotVia prefix) to be nexthop(originator) • No extra computation • Partial aggregation saves: • Memory: # of L > # of N • Computation gain is same

30. 2095 856 700 src dst 260 233 1295 639 548 587 366 846 902 1893 src NVD->K 1176 IPFRR with NotVia address NVD->K X • Announce the NotVia address • Each router computes a nexthop for the address • When failure happens, encapsulate • packets with the address

31. Effectiveness of Prioritization dot: the round at which a necessary entry is computed Node 38’s 92nd round of computation generates a necessary NotVia entry without prioritization (92, 38) Round Number of NotVia Computation Green – with prioritization Red – without prioritization