Making Routers Last Longer with ViAggre

1. Hitesh Ballani, Paul Francis, Tuan Cao and Jia Wang Cornell University and AT&T Labs-Research Presented by Gregory Peaker, Zhen Qin Making Routers Last Longer with ViAggre

2. Outline • Motivation • ViAggre design • Allocating aggregation points • Evaluation • Deployment • Discussion

3. Motivation • Large Routing Table  More FIB space on Routers • Rapid future growth IPv4 exhaustion IPv6 deployment

4. Does FIB Size Matter? • Technical concerns Power and Heat dissipation problems • Business concerns Large routing table Less cost-effective networks Price per bit forwarded increases Cost of router memory upgrades ISPs are willing to undergo some pain to extend the life of their routers

5. Virtual Aggregation (ViAggre)

6. ViAggre basic idea

7. ViAggre basic idea

8. ViAggre basic idea

9. ViAggre basic idea

10. ViAggre basic idea

11. Data-Plane paths

12. Data-Plane paths

13. Ingress  Aggregation Point

14. Ingress  Aggregation Point

15. Ingress  Aggregation Point

16. Aggregation PointEgress

17. Aggregation PointEgress

18. Aggregation PointEgress

19. Aggregation PointEgress

20. Allocating aggregation points • A router’s FIB size (Fr): • routes to the real prefixes in the virtual prefixes it is aggregating • routes to all the virtual prefixes • routes to the popular prefixes • LSP mappings for external routers

21. Allocating aggregation points • Traffic stretch: • packets from router i to prefix p belonging to a virtual prefix v are routed through router k • j is the egress-router for a traffic from router k to prefix p • i chooses k as an aggregation point that is closest in terms of IGP metrics, where k is also belonging to virtual prefix v

22. Allocating aggregation points • Definition of can_server • If router i were to aggregate virtual prefix v, which routers can it serve without violating the stretch constraint C. • In accordance with can_server relation while trying to minimize the worst FIB size, an algorithm was proposed to designate all routers are served for a virtual prefix

23. Evaluation • Impact on Traffic • Traffic stretched using different router level path than native path • Increase Router Load

24. Evaluation using ISPs • Tier 1 • Extend life of routers from 2007 to 2018 • 39% increase load on routers • 1.5% of prefixes for 75.5% traffic • 5% of prefixes for 90.2% traffic

25. Evaluation using ISPs • Tier 2 • Apply routing table for their customers • Use default table for all other customers • Negligible traffic stretch (<0.2 msec) • Negligible Increase in Load (<1.5%)

26. Deployment • Can be incrementally deployed • Can be deployed on small scale • Incentive for deployment • No Change to ISP’s routing table • Does not affect routers advertised to neighbors • Does not restrict routing policies • Extra configuration • Could be automated • Vendor support + cheaper routers

27. Deployment

28. Conclusion & Offense • Can be used by ISPs today • 10x reduction in FIB size • Negligible traffic stretch • Negligible load increase • ISPs extend lifetime of routers • A simple and effective first step

29. Discussion & Offense