On zondag, mei 4, 2003, at 00:01 Europe/Amsterdam, Pedro Roque Marques
wrote:
- "route space depletion" seems to be an argument postulated on the
idea that exterior routing scalability depends mostly on the number of
prefixes carried.
I tend to hold the somehow heretic view that that is not really the
case. imho, exterior routing scaling depends much more on the number
of distinct topologic information that is carried (i.e. distinct BGP
path attributes).
I would also argue that
contrary to the pre-CIDR years, todays networking equipment is
"shorter" on CPU than on memory.
Two sides of the same coin: not just because you can optimize for one
at the expense of the other, but mainly because the memory doesn't just
sit there inertly, it holds information that must be processed. So all
else being equal, more memory means more information means more
processing means more CPU usage.
Note that topologic information (path attributes) is already the
smallest ammount of information required to express the "problem at
hand".
I don't necessarily agree. BGP could save a lot of overhead by
differentiating between transit networks and leaf networks. For the
latter, there is no need keep much information. It should be possible
to bring this down to just a few bits.
In current internet routing tables, the number of prefixes to distinct
path attributes is usually around [5-10] interval.
Note that this will change for the better in IPv6 as there is no longer
much need to keep the assignments to ISPs artificially small.
Also, in order for your assertion to be correct, it requires the
processing that is unique for each set of path attributes to be at
least five times as expensive as prefix processing. The former is
mostly loop detection and AS path filtering, the latter is obviously
prefix filtering and deleting/inserting prefixes, but also running the
BGP path selection algorithm, which is AFAIK done per-prefix even
though it mostly looks at the path attributes. I'm not making any
claims either way, but I'd like to see some figures here. (Any vendors
in the room?)
Iljitsch van Beijnum