[ppml] too many variables

[Leo Bicknell]

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 - 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070810/e3897f45/attachment.sig>