Subject: Re: [Int-area] Re: [RAM] Please be more specific about the problem

From: [email-masked] (Noel Chiappa)
Date: Thu, 22 Mar 2007 15:14:29 -0400 (EDT)

> From: Danny McPherson <[email-masked]>

    > I suspect one way to look at this is to ask what's going to break first?

According to what I'm hearing, it's ISP's wallets.

We can certainly build boxes with bigger/faster memory arrays (we need faster
if stabilization time is to be constant in real-time, while the table itself
keeps getting bigger), but it will cost a small boat of money for a core
router with mega-tables, and the ISP business these days is not exactly one
in which one makes a lot of money (witness the significant number of ISP's
who have had financial difficulties...)

In other words, it doesn't do much good to be able to big mega-big-fast core
routers, if none of the supposed customers have the money to be able to
buy/deploy them.

Reminds me of that old line:

  "An engineer is a person who can do for a dime what any fool can do for a
  dollar."

Translation: Throwing expensive hardware at the problem is not the answer.

	Noel

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: "Pierre Baume" <[email-masked]>
Date: Fri, 23 Mar 2007 01:28:19 +0100

Hi Noel,

> According to what I'm hearing, it's ISP's wallets.
[...]

>         Noel
[...]

  Maybe. Before they get to that point, there certainly would be more
filtering. More specifics would sound like a prime candidate to me,
but then again, I'm not running a tier-1 network. :-}

Pierre.

---

From: Danny McPherson <[email-masked]>
Date: Thu, 22 Mar 2007 20:29:22 -0600

> who have had financial difficulties...)

Indeed, something I know firsthand..

> routers, if none of the supposed customers have the money to be  

I agree with this as well, and anything in this context certainly
wasn't the point of my earlier message.

My point was that there are operational things that can be done
today that have a dramatic impact on the scalability of today's
routing system, and in particular, the service providers that field
the brunt of the load.  In parallel, there are things that can be
done with regard to incremental improvements on routing
protocol and implementation side with existing protocols to
improve upon this as well.

Subsequent to that, or in parallel, actually, intermediate solutions
are fine, so long as a common end goal is identified, and these
intermediate solutions move us closer to that end goal.  Clearly,
the work that Dino & co. are doing has merit.

As for the end goal, I believe a fine target for the Internet area is
to simply subscribe to the end to end argument.

Getting there is of course the challenge, but agreement upon
this fundamental end goal, and accepting that to get there with
an architecture that's capable of decoupling locators and
IDs, thereby helping to address the long-term concerns with
network and routing system scalability, is clearly to the benefit
of all those involved.

Furthermore, an end to end model will get us at least as
far as we are today from an applications perspective, and
middlebox and similar solutions can be accommodated,
so long as the end hosts themselves subscribe to such a
model.

> Translation: Throwing expensive hardware at the problem is not the  

I agree completely.

-danny