On Wed, 29 Aug 2001, Sean M. Doran wrote:

| I think there is real promise in SMP though. There are many SMP | applications that scale near linearly, and I think properly designed | routing can be one of them. If a linear SMP solution can be found | then there is at least one way to scale the routing infrastructure | to near infinate size simply for $$$'s.

So like I have to hop on a plane, but the Russian guy wakes up really soon, and this is very much his field... :-)

You won't like the answers though, 'cause they're consistent with mine. Oh well.

Hmm. Actually, routing info processing parallelizes fairly well. Computationally heavy things like policy evaluations and BGP protocol engines are generally done on per-peer basis, so you can do it on a bunch of processors in parallel; the path comparison (aka best route selection) is done on per-prefix basis (i.e. the best path for each prefix is generally independent from all other prefixes) - so it can be segmented by address blocks (i.e. one processor does path selection for 0/2, the second for 1/2, the third for 2/2, the fourth for 3/2; etc; you got the idea :) That said, implementing heavily parallel routing software in practice is quite hard. Even non-parallelized routing code is not easy to do right, as was convincingly demonstrated by OFRV. The approach I advocated when starting Pluris was to dramatically reduce topological complexity of networks instead by having only one large (internally redundant) IP router per POP instead of clusters of smallish boxes. I still think this is the best approach, because it improves not only exterior routing performance (smaller iBGP meshes) but also interior routing. Like, Keep It Simple :) --vadim