[28705] in North American Network Operators' Group
RE: CIDR Report
daemon@ATHENA.MIT.EDU (Roeland M.J. Meyer)
Sat May 13 17:51:17 2000
Reply-To: <rmeyer@mhsc.com>
From: "Roeland M.J. Meyer" <rmeyer@mhsc.com>
To: <danny@tcb.net>, <nanog@nanog.org>
Date: Sat, 13 May 2000 14:48:56 -0700
Message-ID: <002101bfbd25$0a7da7f0$eaaf6cc7@PEREGRIN>
MIME-Version: 1.0
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <200005132047.OAA11928@tcb.net>
Errors-To: owner-nanog-outgoing@merit.edu
> Danny McPherson: Saturday, May 13, 2000 1:47 PM
>=20
> > None of these are big enough to justify their own backbone=20
> operations or to
> > buy a backbone from someone else, or there wouldn't be a=20
> problem. Paying scads=20
> > of extortion money is also problematic (cheaper to simply=20
> burn the IP addresses).
> >
> > I am NOT advocating tossing all of that out. I am simply=20
> bringing up a
> > problem condition. Please, don't shoot the messenger, or=20
> otherwise get
> > defensive (return fire is a bitch).
>=20
> Nope, all of these are reasonable, the ones that aren't are,=20
> for example,=20
> where folks have a single connection, or multi-home only to a=20
> 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,=20
> > as predicted in MegaTrends over 10 years ago, are now starting to
> > appear. They are very diffused (sparse population, over very large=20
> > areas of the globe) and have connectivity needs which are=20
> both critical,=20
> > yet very different from click-n-morter customers that the Big8 was=20
> > built up to handle (either classful or classless). The=20
> current architecture
> > is not handeling them very well.
> >=20
> > The problem is currently in it's infancy, it will get much worse.
>=20
> I'm not disagreeing with any of this. Actually, I see=20
> reliability and=20
> 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=20
> deaggregation are=20
> using "route table size doesn't matter anymore" as an=20
> argument, when it=20
> absolutely does matter, especially if we plan to make the=20
> Internet more=20
> 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.
