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.
[deleted]
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. s.