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

Martin, Christian cmartin at gnilink.net
Tue Aug 28 22:21:48 UTC 2001


This is the umpteenth time that this type of thread and its spawn have been
religiously fought out on NANOG.  The camps are split between the doomsayers
(Internet armageddonists), the pragmatists, and the laisez-faire who are
continually walking on sunshine.  Assertions are made, flames are thrown,
people dodge and parry, and the war goes on.  In the end, the armageddonists
fortell the end of the Internet, the pragmatists portend that a solutin must
be found, and the grazers simply don't get it or don't care because there is
revenue on the line in a shrinking market.  What we don't see is any real
data that indicates who is right and who is wrong.  The only empirical data
shows a comparison between routing table growth and Moore's law, which
doesn't amount to a whole hill of beans if there isn't a reasonable frame of
reference to which we can make comparisons.  For example, what is the state
of the Internet routing system today, in terms of memory utilization and
processing load?  Most of my routers spend a majority of their processing
cycles doing a whole lot of nothing (besides crash every so often because of
cosmic radiation and other stellar phenomena), have copious amounts of
memory, and process a couple of thousand updates a day under steady state
(no link flaps internally).  Under extreme circumstances (protocol
implementation bugs, filtering leaks, etc), the routers enter into a state
of hary-cary, but this is rare, and independent (in most cases) of the size
of the table.  So they are not by any means part of the current Moore cycle,
but perhaps a few generations behind.

So, I sit back and evaluate the data available to me and wonder, "Where does
this all break?  At what point does the routing system overheat, and what
steps can be taken to prevent it?"  I see a lot of answers to the latter,
many which I agree with, but some of which I can't make an accurate
judgement until the former is answered.  To offer an analogy, what we are
doing is standing in front of a bridge that says "Maximum Weight - Not Too
Much Or It Might Collapse".  The Armageddonists have formed a picket line in
front of it, the pragmatists are inspecting the beams and footings, and the
grazers are driving their 18-wheelers across, honking their horns, and
swigging their favorite hop-juice.

I think that what we need to do is have a fourth group, call them Internet
Engineers for lack of a better word, come in and determine what the sign
should read.  At the same time, we have a fifth group, call them vendors,
begin design on a new bridge that has known scaling limitations that we can
all agree on.  Finally, we have a sixth group, call them the IETF, come in
and invent a flying car that doesn't need the bridge at all.  

So I plead with you all, lets end this war of baseless claims and move
toward a solution, by first determining at what point we need one, and then
determining what it is.

TTFN,
-chris (who happens to be a pragmatist)

> -----Original Message-----
> From: hardie at equinix.com [mailto:hardie at equinix.com]
> Sent: Tuesday, August 28, 2001 4:39 PM
> To: david.conrad at nominum.com
> Cc: davids at webmaster.com; nanog at merit.edu
> Subject: Re: multi-homing fixes
> 
> 
> 
> drc writes:
> > Micro-allocations and filtering are treating symptoms.  The 
> underlying 
> > disease (rational route announcement policy) 
> 
> 
> I agree with David's analysis of the problem right up to this point;
> from my pespective the underlying disease is the route
> convergence/routing table growth issue.  The route announcement
> policy's rationality has to be judged in the light of this greater
> pathology.  It *is* the real problem, though, and we have to keep it
> in mind to understand that any invocation of market forces, draconian
> filters, or community-mindedness only delays the progress of the
> underlying pathology.  In a sense, they too are symptoms, however
> rational they may appear in today's lights.
> 
> Or as Randy puts, we're playing whack-a-mole here, and we're doing it
> knowing it only buys us time.
> 
> The underlying problem is real, and it will take time to develop a
> real solution.  Encourage your vendors to participate in the
> appropriate working groups, tell them you'll spend money on products
> that fix it, and be ready as an operator to help debug potential
> solutions.  It's important.
> 
> End of pleading....
> 			regards,
> 				Ted
> 
> (Not speaking for Equinix; speaking for David.  No wait, I 
> meant *to* David.)
> 
> 
> 
> 



More information about the NANOG mailing list