[ppml] too many variables
vgill at vijaygill.com
Fri Aug 10 18:33:34 UTC 2007
On 8/10/07, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Fri, Aug 10, 2007 at 11:08:26AM -0700, vijay gill
> > 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 you
> > have a network that you can upgrade the RPs on every 18 months, let
> You're mixing problems.
> Even though you may only be able to put in a new route processor
> every 3-5 years doesn't mean the vendor shouldn't have a faster
> version every 18 months, or even sooner. It's the addition of the
> two that's the problem. You're 5 year cycle may come a year before
> the vendors 5 year cycle, putting you on 9 year old gear before you
> refresh next.
The vendor has to qualify, write code for, and support n versions. This IS a
part of the problem. Just blindly swapping out CPUs is non trivial, as any
systems engineer can tell you. The support cost will be passed on to the
Vendor J got it half right. The RP is a separately replaceable
> component based on a commodity motherboard, hooked in with commodity
> ethernet, using the most popular CPU and ram on the market. And
> yes, I understand needing to pay extra for the sheet metal, cooling
> calculations, and other items.
> But, they still cost 10x a PC based on the same components, and are
> upgraded perhaps every 3 years, at best. They don't even take
> advantage of perhaps going from a 2.0Ghz processor to a 2.4, using
> the same motherboard, RAM, disk, etc.
> But I think the point still stands, I bet Vendor J in particular
> could pop out a Core 2 Duo based RP with 8 gig of ram and a 300+
> gig hard drive in under 6 months while holding the price point if
> BGP convergence demanded it, and their customers made it a priority.
> 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.
> Leo Bicknell - bicknell at ufp.org - CCIE 3440
> PGP keys at http://www.ufp.org/~bicknell/
> Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
> You are receiving this message because you are subscribed to the ARIN
> Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member
> Help Desk at info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NANOG