Underlying causes for an expanding Internet Routing Table

In the previous post I considered the expansion of the Internet Routing Table. What is driving this trend and will it get better or worse? Obviously, the Internet is getting bigger. Is this enough to explain the size? Is the Routing table as efficiently optimised as possible?

The extremes of the routing table are as follows:

• 1 address range per AS. Every independent Autonomous System would only advertise a single block. This is largely impossible to achieve with the Internet today. In order to achieve this, BGP would need a native Traffic Engineering mechanism and each AS would require a sufficiently large block of addresses to cater for current and future needs. IPv6 is the hope for the latter. There are some thoughts around the former (SCTP, LISP and others). This would reduce the Internet Routing Table to approximately 10% of its current size (35,600 ASes active).
• Optimally aggregated – if we  took all prefixes that matched in AS Path (to preserve traffic transit policies – discussed below) and aggregated them, we could reduce the routing table by 38.2%. This would mean aggregating over address holes (without violating allocations) and crossing consecutive allocations per AS – essentially nothing would change in the way that the Internet routes today but there would be a sizeable reduction.
• BGP routing table that matches allocations by RIRs. This would neither aggregate over consecutive allocations nor deaggregate to longer prefixes. This is approximately 20% smaller than the current Internet Routing Table and 20% larger than the optimally aggregated. If an ISP were allocated 10/8 and 11/8, it would neither aggregate to 10/7 or deaggregate to longer prefixes.
• The Internet Routing table – the current jumble of (mostly) deaggregrations, aggregrations and omissions.

So, if the Internet is approximately 40% larger than optimal and 20% larger than allocated, why?

The following causes of an expanded routing table are considered significant:

• Multi-homing
• Traffic Engineering
• Fragmented allocation
• Poor configuration

In the next post, I will consider Multi-homing and Traffic engineering. These are legitimate causes of de-aggregation and add the largest number of deaggregated prefixes to the table.

This is part of a series of posts – The Lisp Papers.