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@equinix.com [mailto:hardie@equinix.com] Sent: Tuesday, August 28, 2001 4:39 PM To: david.conrad@nominum.com Cc: davids@webmaster.com; nanog@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.)