On Mon, 2 Apr 2001, Travis Pugh wrote:
Performance of a routing protocol is not a function of just the CPU avaliable.
Performance of a routing protocol is a function of the CPU avaliable and the network characteristics.
Granted, but are you saying that the 15 minutes it takes one of my BGP sessions to reload has no relevance to the crusty, old processor doing route calculations on 104,000 routes? Multiply the CPU available by 5, and then look for bottlenecks. Seems sane to me. Also seems a hell of a lot easier than trying to redesign the network characteristics in 1 year and implement them ... IPv6 anyone?
It might not, it might be more of a function of the CPU on the other end. It might be more limited by the bandwidth. Even if it's totally CPU limited on your end: multiply your CPU by 5 and you have gained somewhat less then a factor of 5 improvement. Replace the internet with a highly aggregated IPv6 network which uses transport level multihoming and you gain a factor of 1000 improvement at core routers (and 100,000x further from the core where you no longer need to be default-free) and still have the oppturnity for a further 5x by going to a state-of-the-art CPU (providing that your cpu speed reasoning is valid). Incremental performance improvements in router performance is a good thing, but it's no where near the level needed to ensure sustainability. If going to a 5x faster CPU would really help real-world performance that much, the high-end router vendors would have already done it at the prices they charge they can afford to be bleeding-edge cpu wise. Easier yes, in the short term, but after you've implimented your state of the art CPU to scale any further you need to invent working quantum computers and install seperate OC3s to carry routing updates to continue scaling. When you consider that, IPv6 doesn't sound bad after all.