ARIN Proposal

[Karl Denninger]

> At 11:11 AM 1/23/97 -0600, Karl Denninger wrote:
>
> >HOWEVER, CISCO currently wastes about 50% of that RAM allocation.  This I
> >have *proven* by looking at other implementations and their RAM requirements.
> >Assuming that CISCO tightens up their code (not unreasonable) I would expect
> >to see that usage drop by perhaps 30% during that same time.
>
> Karl,
>
> Can we please dispense with the "cisco is evil, never trust them,
> they can't build boxes worth squat" bashing?
>
> The last thing I had heard, this list was established to discuss
> IP address allocation strategies with regard to ARIN; if you continue
> to derail the discussion here, I certainly wouldn't be surprised to
> see decisions being made with complete disregard to what Karl Denniger
> thinks is important. I don't think you want that, and I would certainly
> appreciate the opportunity to work with you, as opposed to working
> against you.
>
> But what the hell.
>
> - paul

You can be pissed off all you'd like.

The FACT is, when deficient engineering ends up driving public policy it
makes for poor policy.

The FACT is, if this had been addressed back in 1993 we wouldn't have the
wars now that are raging over CIDR blocks and providers being screwed
(funny how it only happens to the smaller companies) on almost a daily
basis -- injuring their businesses -- at the sufferance and whim of
national firms.

The FACT is, that its not even all CISCO's fault!  Lots of it comes down
to a simple "I don't want to pay what it costs" argument.

Look.  I've been at this for a LONG time Paul.  I know how to engineer
networks so they don't fall apart and croak when they have a bad hair day.
I also know that doing so costs real money.  And finally, I know that
published claims, and the number of slots in a box, has NOTHING to do with
its real capacity in the real world.

When I have an "event" with a BGP peer and see my forwarding performance
go in the toilet for 2-3 minutes, I call it unacceptable.  Period.

The fact is that we're not REALLY in route-table-space trouble right now,
and if we're SENSIBLE about how we allocate space to ISPs we NEVER WILL BE.
We're in flap-rate trouble right now, but that's because someone didn't
properly separate functions within their hardware, and allows one to
interfere with the other.

CISCO will either get with the program (and with three years of lead time,
you have no excuse for failing to do so) or you die.  This is how it should
be.  You've got fair warning, an allocation policy that says that ISPs get
/19s won't break the route table bank for several (ie: 3 or more) years, and
that's PLENTY of time to both (1) get hardware which can handle this out
there, and (2) amortize the EXISTING installed equipment to the point that
nobody will go bankrupt buying the new stuff.

My point is that CISCO has ALREADY had three years of time to do this, and
fair notice that it was a problem (in 1993), and has utterly failed to
address the REAL issue in a fashion which is ACTUALLY a fix.

Since that's the case, I now discount any opinion of "doom and gloom" from
anyone who works for your company -- since your firm has proven it can't
deliver, and you've had two engineering cycles to do so.

And by the way, I buy a LOT of your hardware.  For now.

--
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl     | T1's from $600 monthly to FULL DS-3 Service
                             | 99 Analog numbers, 77 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax:   [+1 312 248-9865]     | 2 FULL DS-3 Internet links; 400Mbps B/W Internal