Hi Iljitsch, You wrote, concerning the limitations of DRAM in a Linux server:
> 100 times the entries * 100 times the churn = 10000 times the > processing. I'm afraid that your DRAM isn't going to keep up with that > in a traditional design. > > However, route processing isn't inherently serial. So it should be > possible to make a route processor that has 100 systems-on-a-chip that > all process 1% of the routing table. Of course current BGP isn't > particularly suitable for that, but I don't see a reason why changes > that allow parallel BGP processing can't be made. Still, those CPUs need to communicate with each other and maintain a common RIB, as well as information about each conversation with each BGP neighbour, via DRAM. So I am not sure that adding CPUs would be any better than the Linux server situation of 2 or so fast CPUs with caches with a common DRAM. I am not sure how suitable the BGP implementation would be to 100 CPUs each with their own DRAM and some kind of communications link between them. That sounds even messier. - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
