[41109] in North American Network Operators' Group
Re: What is the limit? (was RE: multi-homing fixes)
daemon@ATHENA.MIT.EDU (Vadim Antonov)
Wed Aug 29 19:08:46 2001
Date: Wed, 29 Aug 2001 16:08:11 -0700 (PDT)
From: Vadim Antonov <avg@exigengroup.com>
To: "Sean M. Doran" <smd@clock.org>
Cc: nanog@merit.edu
In-Reply-To: <20010829154440.58EF8C790C@cesium.clock.org>
Message-ID: <Pine.LNX.4.10.10108291554550.19622-100000@arch.exigengroup.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Errors-To: owner-nanog-outgoing@merit.edu
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
