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 1176 902 1295 639 856 1893 587 233260 846 700 548 366 Routing Convergence Causes Packet Losses X Convergence! (sub-second)

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

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. IPFRR with NotVia Address 2095 1176 902 1295 639 856 1893 587 233260 846 700 548 366 NV DV->KA X 1.Announce the NotVia address 2.Each router computes a nexthop for the address 3.When failure happens, encapsulate packets with the address DV NV DV->KA SV NY

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. Memory Overhead Extra FIB entries dstnexthop Kansas C.Denver New YorkDenver …… 2095 1176 902 1295 639 856 1893 587 233260 846 700 548 366 NV D->K Los Angeles …… # 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 t 2 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. 1. NotVia Aggregation 2095 1176 902 1295 639 856 1893 587 233260 846 700 548 366 NV DV->KA Observation: very often, nexthop(NV)= normal nexthop(NV’s originator)

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

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

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. 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. IPFRR with Loop-Free Alternate 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 STD R 1 5 11 1 S 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. How does rNotVia work? 2095 1176 902 1295 639 856 1893 587 233260 846 700 548 366 X X XX X XXX: no black color

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

30. IPFRR with NotVia address 2095 1176 902 1295 639 856 1893 587 233260 846 700 548 366 NV D->K 1.Announce the NotVia address 2.Each router computes a nexthop for the address 3.When failure happens, encapsulate packets with the address src NV D->K src dst X

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