North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: multi-homing fixes

  • From: Adam Rothschild
  • Date: Fri Aug 24 01:38:13 2001

On Thu, Aug 23, 2001 at 03:23:24PM -0700, Roeland Meyer wrote:
> This gal only has it half right. It isn't the reduced cost of
> circuits, it's it's the uncertainty that that circuit's provider
> will still be in business next month, or that a change in that
> provider's business plans, or M&A activity, will make them abandon
> that circuit altogether [...]

I don't think anyone here is concerned that vZn, SBC, WCOM, Q, etc
will go out of business, or undergo drastic business changes
prohibiting them from continuing to provide us with the TDM, xWDM,
dark fibre, etc services they do now by this time next year.

But yes, customers multihoming is a good thing(tm) for other reasons
outlined.  And putting all your eggs in one basket -- be it a large
and stable telco, or a small DSL aggregator of questionable clue and
financial stability -- is never wise, even if it will save you some
coin.  And at the end of the day, either our IP providers' racks have
power, or they don't; either their cross-connects are live, or they're
cut with a razor blade...

> At $99US for 512MB of PC133 RAM (the point is, RAM is disgustingly
> cheap and getting cheaper), more RAM in the routers is a quick
> answer. Router clusters are another answer, and faster CPUs are yet
> another.

Throwing more RAM and CPU into our routers (assuming for a moment that
they're most certainly all Linux PC's running Zebra) is not the
solution you're looking for; the problem of RIB processing still

Getting a forwarding table requires extracting data from the RIB, and
this is the problem, because RIBs are very large and active, and are
being accessed by lots of reading and writing processes.  RIB
processing is substantial, and is only getting worse.

> If the IETF is being at all effective, that should start now and
> finish sometime next year, so that we can start the 5-year
> technology roll-out cycle.

Roeland, The IETF is eagerly awaiting your solution.  Send code.  See
Tony Li's presentation at the Atlanta NANOG on why this solution of
jamming RAM and CPU into boxes is not a long term viable answer:


In short, state growth at each level must be constrained and must not
outstrip Moore's law, and to be viable in an economic sense, it must
lag behind Moore's law.  Things that cause heartache normally involve
memory bandwidth from CPU to RIB memory when you need to spend a whole
lot of time walking tables as an ever larger percentage of your tables
slosh around like yo yos.

> should either have his lips perma-bonded together, or have the lower
> part of his face covered in duct tape. Maybe then, he can resist the
> urge to chew on his feet.

Hmm, always a good idea.