Hi,
I am the chap who did the port of XORP to Microsoft Windows; normally on
the Internet I play a FreeBSD committer role.
Leo Bicknell wrote:
It seems to me an off the shelf PC with a Core 2 Duo processor, 4
gig of memory, and a gigabit ethernet port would be 1-2 orders of
magnitude faster
> > Of course, I think if the RE were an external 2RU PC that they sold
> > for $5,000 (which is still highway robbery) ISP's might upgrade
> > more than once every 10 years
>
> Sounds like an experiment. Anyone have a spare J M40?
Since End of Service for M40s is later this year, you should
On Tue, Aug 14, 2007, Leo Bicknell wrote:
> Of course, I think if the RE were an external 2RU PC that they sold
> for $5,000 (which is still highway robbery) ISP's might upgrade
> more than once every 10 years
Sounds like an experiment. Anyone have a spare J M40?
(*duck*)
Adrian
In a message written on Mon, Aug 13, 2007 at 05:53:00PM -0700, Scott Whyte
wrote:
> Pick a newly released Core 2 Duo. How long will Intel be selling it?
> How does that compare with getting it into your RP design, tested,
> produced, OS support integrated, sold, and stocked in your depots?
Intel
On 8/13/07, Leo Bicknell <[EMAIL PROTECTED]> wrote:
> In a message written on Mon, Aug 13, 2007 at 02:29:14PM +0200, Eliot Lear
> wrote:
> > This assumes "the real problem" is CPU performance, where many have
> > argued that the real problem is memory bandwidth. Memory doesn't track
> > Moore's
On Mon, 13 Aug 2007, Leo Bicknell wrote:
It seems to me an off the shelf PC with a Core 2 Duo processor, 4
gig of memory, and a gigabit ethernet port would be 1-2 orders of
magnitude faster than what's currently in the routers. Optimize
for a multithreaded CPU, add a second and it would converg
John Paul Morrison wrote:
> Can't any network problem can be solved by adding another layer of
> indirection?
>
> Don't all the various nodes in a system simply "disappear" when another
> technology comes along to organize, replace and manage the problem
> differently? With iBGP there's been conf
Leo Bicknell wrote:
Now, once the FIB is computed, can we push it into line cards, is
there enough memory on them, can they do wire rate lookups, etc are
all good questions and all quickly drift into specialized hardware.
There are no easy answers at that step...
I think we're agreeing that
In a message written on Mon, Aug 13, 2007 at 02:29:14PM +0200, Eliot Lear wrote:
> This assumes "the real problem" is CPU performance, where many have
> argued that the real problem is memory bandwidth. Memory doesn't track
> Moore's Law. Besides, Moore's Law isn't a law. What's your Plan B?
Leo Bicknell wrote:
To Bill's original e-mail. Can we count on 2x every 18 months going
forward? No. But betting on 2x every 24 months, and accounting for the
delta between currently shipping and currently available hardware seems
completely reasonable when assessing the real problem.
Th
> And yet people still say the sky is falling with
> respect to routing convergence and FIB size.
> Probably a better comparison BTW, would be with a
Actually, the better comparison is with the power of current processors
used in Juniper and Cisco gear with the current Moore's law power of
com
On Fri, 10 Aug 2007 18:42:23 +
Paul Vixie <[EMAIL PROTECTED]> wrote:
>
> > > ... is that system level (combinatorial) effects would limit
> > > Internet routing long before moore's law could do so.
> >
> > It is an easy derivative/proxy for the system level effect is all.
> > Bandwidth for
L PROTECTED]; nanog@nanog.org
> > Subject: Re: [ppml] too many variables
>
>
> > I guess people are still spectacularly missing the real point. The point
> isn't that the latest generation
> > hardware cpu du jour you can pick up from the local hardware store is
&
> > ... is that system level (combinatorial) effects would limit Internet
> > routing long before moore's law could do so.
>
> It is an easy derivative/proxy for the system level effect is all. Bandwidth
> for updates (inter and intra system) are another choking point but folks
> tend to be even
On 8/10/07, Paul Vixie <[EMAIL PROTECTED]> wrote:
>
> [ vijay]
>
> > I guess people are still spectacularly missing the real point. The
> point
> > isn't that the latest generation hardware cpu du jour you can pick up
> from
> > the local hardware store is doubling processing power every n month
On 8/10/07, Leo Bicknell <[EMAIL PROTECTED]> wrote:
>
> In a message written on Fri, Aug 10, 2007 at 11:08:26AM -0700, vijay gill
> wrote:
> >substantially behind moores observation to be economically viable. I
> >have some small number of route processors in my network and it is a
> >m
[ vijay]
> I guess people are still spectacularly missing the real point. The point
> isn't that the latest generation hardware cpu du jour you can pick up from
> the local hardware store is doubling processing power every n months.
agreed.
> The point is that getting them qualified, tested
In a message written on Fri, Aug 10, 2007 at 11:08:26AM -0700, vijay gill wrote:
>substantially behind moores observation to be economically viable. I
>have some small number of route processors in my network and it is a
>major hassle to get even those few upgraded. In other words, if y
On 8/10/07, John Paul Morrison <[EMAIL PROTECTED]> wrote:
>
> And yet people still say the sky is falling with respect to routing
> convergence and FIB size. Probably a better comparison BTW, would be with a
> Nintendo or Playstation, as they are MIPS and PowerPC based. Even the latest
> route pr
In a message written on Thu, Aug 09, 2007 at 04:21:37PM +, [EMAIL
PROTECTED] wrote:
> (1) there are technology factors we can't predict, e.g.,
> moore's law effects on hardware development
Some of that is predictable though. I'm sitting here looking at a
heavily peered exchange point
On 8/9/07, Randy Bush <[EMAIL PROTECTED]> wrote:
>
> the fib in a heavily peered dfz router does not often converge now. the
> question is when will the router not be able to process the volume of
> churn, i.e. fall behind further and further? as there is non-trivial
> headroom in the algorithms,
Lincoln Dale wrote:
>> I asked this question to a couple of folks:
>>
>> "at the current churn rate/ration, at what size doe the FIB need to
>> be before it will not converge?"
>>
>> and got these answers:
>>
>> - jabber log -
>> a fine question, has been asked many
> I asked this question to a couple of folks:
>
> "at the current churn rate/ration, at what size doe the FIB need to
> be before it will not converge?"
>
> and got these answers:
>
> - jabber log -
> a fine question, has been asked many times, and afaik noone h
>> the fib in a heavily peered dfz router does not often converge now.
> never? or over some predefined period of time?
not often
>> as there is non-trivial headroom in the algorithms,
> the BGP algorithm does not change (BGP-5, BGP-6 etc anyone)
algorithm != protocol
randy
On Thu, 9 Aug 2007, Steve Atkins wrote:
On Aug 9, 2007, at 12:09 PM, Leigh Porter wrote:
Yes a very big unless. Multi-core processors are already available that
would make very large BGP convergence possible. Change the algorithm as
well and perhaps add some multi-threading to it and it
On Thu, Aug 09, 2007 at 08:09:54PM +0100, Leigh Porter wrote:
>
>
> Yes a very big unless. Multi-core processors are already available that
> would make very large BGP convergence possible. Change the algorithm as
> well and perhaps add some multi-threading to it and it's even better.
On Aug 9, 2007, at 3:47 PM, Tony Li wrote:
On Aug 9, 2007, at 12:09 PM, Leigh Porter wrote:
Yes a very big unless. Multi-core processors are already available
that would make very large BGP convergence possible. Change the
algorithm as well and perhaps add some multi-threading to it a
.e. fall behind further and further?
yes. presuming the churn ratio stays the same and:
> as there is non-trivial
> headroom in the algorithms,
the BGP algorithm does not change (BGP-5, BGP-6 etc anyone)
>
> moore's law on the processors, etc. etc.,
On Aug 9, 2007, at 12:09 PM, Leigh Porter wrote:
Yes a very big unless. Multi-core processors are already available
that would make very large BGP convergence possible. Change the
algorithm as well and perhaps add some multi-threading to it and
it's even better.
Anyone have a decent
Yes a very big unless. Multi-core processors are already available that
would make very large BGP convergence possible. Change the algorithm as
well and perhaps add some multi-threading to it and it's even better.
--
Leigh Porter
Patrick Giagnocavo wrote:
On Aug 9, 2007, at 12:21 PM, [
On Aug 9, 2007, at 12:21 PM, [EMAIL PROTECTED] wrote:
so putting a stake in the ground, BGP will stop working @ around
2,500,000 routes - can't converge... regardless of IPv4 or IPv6.
unless the CPU's change or the convergence algorithm changes.
That is a pretty big
the fib in a heavily peered dfz router does not often converge now. the
question is when will the router not be able to process the volume of
churn, i.e. fall behind further and further? as there is non-trivial
headroom in the algorithms, moore's law on the processors, etc. etc.,
your message is
I asked this question to a couple of folks:
"at the current churn rate/ration, at what size doe the FIB need to
be before it will not converge?"
and got these answers:
- jabber log -
a fine question, has been asked many times, and afaik noone has
provided any
33 matches
Mail list logo
