[40875] in North American Network Operators' Group
Re: multi-homing fixes
daemon@ATHENA.MIT.EDU (Majdi S. Abbas)
Fri Aug 24 03:27:59 2001
Date: Fri, 24 Aug 2001 00:27:16 -0700
From: "Majdi S. Abbas" <msa@samurai.sfo.dead-dog.com>
To: Roeland Meyer <rmeyer@mhsc.com>
Cc: "'Adam Rothschild'" <asr@latency.net>, nanog@merit.edu
Message-ID: <20010824002716.A26627@samurai.sfo.dead-dog.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <EA9368A5B1010140ADBF534E4D32C728069E32@condor.mhsc.com>; from rmeyer@mhsc.com on Thu, Aug 23, 2001 at 11:50:38PM -0700
Errors-To: owner-nanog-outgoing@merit.edu
On Thu, Aug 23, 2001 at 11:50:38PM -0700, Roeland Meyer wrote:
> SMP systems and multi-ported RAM is a good enough stop-gap. If I didn't like
> non-deterministic systems, I might suggest Echelon technologies
> (hardware-based neural nets).
Nothing is a good enough stop-gap while things continue to grow at
this rate. Encouraging people to throw an extra hamster onto the wheel
does not solve the problem for long at all, and encourages more waste of
existing resources.
> I've read that and largely agree. The hardware approach was only meant to
> buy time, while the geniuses at the IETF find a better approach. What I
> don't agree on, and am amazed to see, the admission that they don't know at
> what point the convergeince problem becomes intractible. Or even, if it
> does... that sounds more like a fundimental lack of understanding of the
> algorithm itself.
CIDR was only meant to buy time. We've bought our time, and we
still don't have a solution. If it were that easy, people would be doing
it. Buying more time in small increments is not necessarily in our
interests.
Continuing to pile announcements onto this mess, looking for the
prefix that breaks the camel's back, is not a good idea until you -have-
a solution.
> In the mid-80's, I worked on an OCR problem, involving a add-on 80186
> processor card. We used a brute-force solution. It as too slow on the 8 MHz
> CPU. Years later, with the advent of faster hardware, the product was
> released. It's funny that the market timing was just about perfect. It gave
> that company a huge head start, when the market turned hot. It is alright to
> target performance/capacity solutions expected to be present at the time of
> product release (about 5-years from now). In fact, that's about the only way
> I see the problem getting solved.
Precisely -- and this /doesn't work/ if you make the existing problem
worse during those intervening 5 years.
--msa
