explosion in the routing table content, which roughly tells us that we have been adding about 50,000 new prefixes every year. In addition to the size of a default-free BGP table, other significant factors that will influence the need for classification performance include all IPv4 routing tables, the number of routing tables that must be consulted in some cases, and the need for all network equipment that also relies on other lookup entries to be able to support the following: Separate routing tables for each VPN. IPv6 routing tables, especially in the case of wireless networks as IPv6 may likely end up being driven by the fact that each third-generation wireless phone could have its own IP address. 2. The BGP table status along with numerous pertinent statistics as well as papers, links, IETF reports, and even tutorials on CIDR and routing can be found at http://bgp.potaroo.net or at Telstra's web site www.telstra.net/ops/bgptable.html. The drawing shown in Figure 13.3 is based on results produced by the BGP Analyzer, which is written and maintained by Telstra's Geoff Huston. Results before April 4, 1997 are interpreted from data provided by Erik-Jan Bos of SURFnet. 3. See "Internet Core Router Test," March 6, 2001, www.lightreading.com/document.asp?doc_id54009.1 In that test suite, one of the interesting issues was to test some routers in a problematic mode of operation called route flapping. This condition occurs in real life when numerous routes are withdrawn from the BGP table (which consequently changes state often) and then are re-adver- tised in a very rapid succession. This route-flapping test required the tested routers to learn and unlearn 200,000 routes over a period of 60 seconds while measuring forwarding performance. The so-called drop-dead requirement to run this test is less than 8,000 per second; however, it goes without saying that higher learning rates will improve how a piece of routing equipment scores. It could be argued that real-life routers usually enjoy a functionality called route damp