On Wed, Apr 10, 2002 at 07:44:31AM +0800, Adrian Chadd wrote:
I don't exactly anticipate this ever happening. My observation is that the scaling will happen in the router area, i.e. as more and more smaller blocks get announced out of the class A/class B space, the ability of routers to hold more routes will tend to relax the typical filtering policies as time goes on. In other words, by the time we might encounter a problem, it'll no longer be a problem.
Back when routers had small (relatively) small CPUs and (relatively) small amounts of RAM I'd say that the filtering (and other nice things such as flap dampening) was coined to stop these poor little routers from dying.
But nowdays, routers have lots of CPU and lots of RAM. Somehow people equate this to "can hold/munge larger routing tables".
Speak for yourself. I think routers are hidiously under equipped with CPU and RAM, and that which you can upgrade is still sold by the vendors at insane prices the like of which you can only find in the blissful stupor of ignorant customers. There are two areas which limit the number of routes you can support. The first is the longest prefix match lookup system, which must do an increased amount of work on every packet. This has largely been eliminated in "modern" routers, through the use of specialized hardware and/or the use of an mtrie based FIB (like CEF) which uses a fixed size forwarding table and makes all lookups nearly equal in cost regardless of the number of routes (the only thing that could make this situation more difficult is more address space, like IPv6). The second is the routing protocols the the infrastructure necessary to support them. This is where you start bloating your memory usage and convergence time, which is DIRECTLY related to, you guessed it, both the lack of RAM and CPU resources, and the oh so crappy code that the vendors write. This is the area that "filter nazi's" (hi Randy) care about, not because more routes is really harmful to the internet, but because it impacts the memory usage and convergence times of their networks. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)