 with the eventual access to the three cities. From our perspective, whatever must go to one of these cities must be channeled toward the route that goes to Chicago. Our aggregation of the routes to one common city serves that purpose. The problem and the solution obvi- ously scale up. We should also be able to aggregate our Chicago routes with routes that are destined for other cities, such as Cleveland. In the CIDR case, the incoming packet header, which carries the destination address, does not carry any specific information that could help determine the length of the longest matching prefix. As a result, the search must be conducted not only in the space of all prefix lengths, but also in the space of all prefixes of a given length. From the mathematical algorithm standpoint, this makes it harder to satisfy the LPM requirement than a best match. Performance is becoming a bigger issue with the size of the routing tables and the ever-increasing wire speeds. The BGP table contained 133,000 entries used by routers as of this writing. It was esti- mated that the number of entries would hit the 140,000 mark by the end of 2002. From extensively gathered statistics from Telstra,2 it appears that some pieces of network equipment must be able to support between 5,000 to 10,000 route updates per second (based on new route advertisements from other routers) by early 2003 before becoming a bottleneck on the network's performance. Lightreading provides an example of a test enjoying wide-scale acceptance from the industry. In March 2001, Lightreading formulated a benchmark test for core router updates. 3 Systems designers usually want their designs to be rated as performing well in this benchmark, for instance at 8,000 updates per second. All this points to the same direction. Actually, the industry estimates that limitations of the BGP will probably be the first reason why a bottleneck will appear. The bottleneck will most likely occur before TCAMs run out of updating steam. In any event, Figure 13.3 shows the tendency of 