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

Outline Motivation ViAggre design Allocating aggregation points Evaluation Deployment Discussion

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

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

Virtual Aggregation (ViAggre)

ViAggre basic idea

Data-Plane paths

Ingress  Aggregation Point

Aggregation Point  Egress

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

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

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

Evaluation Impact on Traffic –Traffic stretched using different router level path than native path Increase Router Load

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

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%)

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

Deployment

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

Discussion & Offense