North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: What is the limit? (was RE: multi-homing fixes)

  • From: steve uurtamo
  • Date: Wed Aug 29 12:36:43 2001

>   Draw two curves, the first y=x/2, the second y=x^2
> Move the value of x for y=1 for the first curve left by 2, 5 or 10
> and it will still be surpassed by the second curve.
> You will even see this for a second curve of y=x*2 or y=x.


>   In short: are you claiming that the caeteris paribus assumption
> in comparing Moore's Law to global routing table size is clearly false?   
> It would be nice to see even a partial proof of such a claim.
> From anyone.

sorry to get pedantic here, but i'd be happy to.

when there is a fixed, finite, upper bound on the curve's growth
(because, as you well know, there is a fixed, finite, upper bound
on the number of prefixes that could be announced [say, in ipv4]),
it may assume exponential behavior at the beginning of its growth,
but it won't continue to be exponential until it reaches its
maximum.  what happens is that there will be an inflection point,
and a tailing off of the approach to the limit point.  which is
quite easy to get ahead of technologically.

the difference with moore's law is that the fixed, finite, upper
bound on the route table curve's growth is already technologically
FEASIBLE to handle, in it's ENTIRETY.

so your example functions above just don't cut it.  there is no
infinite amount of prefix space that we need to worry about.  it's
very finite, and currently (ipv4) not even terribly large (if people
allowed even /24's instead of /19's (say), and EVERYBODY split ALL of
their address space down to /24 announcements, we'd still only have on
the order of 2^24 ~ 10^8 prefixes, which is quite reasonable).

i mean, is anyone really trying to argue that it's difficult
computationally to update 10^8 entries at the rate that BGP
updates occur?

arguments along the lines of, "nobody should do anything until we
can guarantee that we can handle multihoming every host on the net"
are really just inappropriate rationales for enforcing restrictive
filtering policies.

i'll say it again: a /24 content provider might need to multihome
for good reachability to all of its clients, whereas a /16 provider
might need to multihome for reachability to remote locations (along
with reliability), and the /24 might very likely be attached to a
much larger sized pipe than the /16.

prefix length != need for multihoming.  so filtering on it is a
pretty ham-handed way to keep prefix table size down.