nanog mailing list archives

RE: CIDR Report


From: "Roeland M.J. Meyer" <rmeyer () mhsc com>
Date: Sat, 13 May 2000 14:48:56 -0700


Danny McPherson: Saturday, May 13, 2000 1:47 PM

None of these are big enough to justify their own backbone 
operations or to
buy a backbone from someone else, or there wouldn't be a 
problem. Paying scads 
of extortion money is also problematic (cheaper to simply 
burn the IP addresses).

I am NOT advocating tossing all of that out. I am simply 
bringing up a
problem condition. Please, don't shoot the messenger, or 
otherwise get
defensive (return fire is a bitch).

Nope, all of these are reasonable, the ones that aren't are, 
for example, 
where folks have a single connection, or multi-home only to a 
single provider.

Agreed, peering on a single connection is a canard.

However, there is a cause/effect relationship with the latter. They can't multi-home to multiple providers because they 
aren't big enough (can't justify the cost). Which is precisely part of the problem that I am presenting here.

What I am bringing up here is that new, information-age companies, 
as predicted in MegaTrends over 10 years ago, are now starting to
appear. They are very diffused (sparse population, over very large 
areas of the globe) and have connectivity needs which are 
both critical, 
yet very different from click-n-morter customers that the Big8 was 
built up to handle (either classful or classless). The 
current architecture
is not handeling them very well.

The problem is currently in it's infancy, it will get much worse.

I'm not disagreeing with any of this.  Actually, I see 
reliability and 
availability feeding into all these other issues as well.

The reason this is an issue is exactly because they want reliability and availability, HA requirements.

It just that some of the folks advocating portability and 
deaggregation are 
using "route table size doesn't matter anymore" as an 
argument, when it 
absolutely does matter, especially if we plan to make the 
Internet more 
reliable, and less vulnerable.

I actually agree with you here as well. relying on infinite router table growth is not a scalable strategy. We need 
something else.




Current thread: