|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: [ppml] too many variables
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 you
> have a network that you can upgrade the RPs on every 18 months, let me
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.
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 - [email protected] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [email protected], www.tmbg.org
Attachment:
pgp00016.pgp
|