[28714] in North American Network Operators' Group
RE: CIDR Report
daemon@ATHENA.MIT.EDU (Roeland M.J. Meyer)
Sun May 14 06:07:54 2000
Reply-To: <rmeyer@mhsc.com>
From: "Roeland M.J. Meyer" <rmeyer@mhsc.com>
To: "'Owen DeLong'" <owen@dixon.delong.sj.ca.us>
Cc: <nanog@merit.edu>
Date: Sun, 14 May 2000 03:03:40 -0700
Message-ID: <003301bfbd8b$ae6f5960$eaaf6cc7@PEREGRIN>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <200005132234.PAA19982@irkutsk.delong.sj.ca.us>
Errors-To: owner-nanog-outgoing@merit.edu
> Owen DeLong: Saturday, May 13, 2000 3:35 PM
>=20
> > I actually agree with you here as well. relying on infinite=20
> router table growth is not a scalable strategy. We need=20
> something else.
> >=20
> Just a small technicality here, noone is talking about=20
> infinite routing
> table growth. There are only 4 billion (roughly) possible prefixes
> if you route every node as a /32. While 4 billion is a large number,
> it is far from infinity.
Well, that statement was obviously not intended literally. But, since =
we're=20
throwing around numbers ...
Simply taking addresses only, that comes out to ~16GB. At $100 per 64MB=20
this is about $25,000.00US in RAM, at current retail rates (prices may=20
vary by vendor). It's also about $16,000.00US of EMC disk-space. This=20
means that one full table would cost about $41KUS, just to store it.=20
But, what will this do to performance of such a router that's working=20
in a gig-E environment? The index table to access this puppy would be=20
larger than the prefix table. This could easily double the cost, say =
$82KUS?
Considering that I just paid $98KUS for a Cisco Catalyst 6509, I guess=20
this isn't too bad. However, this is only IPv4 and it is a bunch more =
than
the cost of the average BGP-capable router and every router on the =
backbone=20
would have to be upgraded. This is conservative since I have not yet =
allowed=20
for memory structure overhead. However, code-space would be relatively =
trivial,
even Microsoft wouldn't be able to bloat it enough so anyone else would =
notice.
> If you believe the IPv4 will continue for many years to come, then
> the set of possible routes is very finite.
Yes, RAM and Disk prices are also plummeting daily. By next year, we may =
even=20
be able to afford it. We just have to figure out whose budget it comes =
out of.=20
(How many BGP4 routers are there?)
> Of course, the number for IPv6 is much larger in theory, but when you
> consider that the last 6 octets are reserved for the MAC address
> (essentially), that leaves 80 bits, which is
> 1,208,925,819,614,629,174,706,176. Again, a large number, but,
> far from infinity. When you further consider that on the backbone,
> only the first eight octets are at all likely to be significant
> for routing, you come to 18,446,744,073,709,551,616 prefixes,
> which is still a large number, but even further from infinity.
Let's see here ... that's 18,446,744T 6-byte addresses? That comes=20
out to 110,680,464TB. Whoops! my calculator just slipped into the=20
bankruptcy zone... $172.9TUS, for RAM and $110.0TUS, for DASD. In=20
addition, you'd need something just a hair short of a Cray to=20
process it.
> In my opinion, eventually, we will need to find a way that each
> organizational unit is issued a portable, non-renumberable prefix
> which stays with that organizational unit. Some larger
> organizational units may need additional prefixes, depending on
> the size of the suffix.
>=20
> Generally, it follows that most strategies for aggregating such
> prefixes will tend towards entropy as organizational units change
> their topological relationships with other organizational units.
>=20
> Thus, the only way to preserve aggregation is to make the prefixes
> issued to organizational units a function of their topology, and
> force renumbering. While this is a simple matter for topologies
> which involve only two organizational units as neighbors, it
> becomes n! (n factorial) complex for organizational units which
> have n neighbors. Even with IPv6, I do not believe such a
> prefix numbering scheme is practical.
Like I said, we need to do something different. The reason that I=20
wrote off routing table increases is not the calculus that I just=20
demonstrated, although that is an effector. It is the general concept=20
that there are practical limits to that approach (there be walls, =
there).
In an IPv6 environment, that approach is simply unaffordable, with=20
present tech. Although, it would definitely stop-gap the problem, in=20
an IPv4 environment. Who will volunteer the cost of the first one of=20
these routers? At that cost factor, how long do you think it will=20
take to deploy them?
