Deepak Jain wrote:

The problem is where the RIB, or forwarding table is exported to the line cards which frequently have less than 128MB of usable RAM/SRAM/memory storage/etc. This essentially means that the line cards can only directly talk to other line cards for a specified, limited number of routing prefixes. I do not know the algorithms used when the line card is out of memory, but in many cases this memory is not field upgradeable beyond a certain point.

Srinivasan, Vargese, and others have demonstrated / observed that space is not a material problem for the architecture you describe. Rather, it is the time to complete a longest-match (or equivalent) operation for each forwarding event, especially for high(er) interface speeds. Regardless, 128MB is a LOT of table memory, especially when it is virtually unknown to see anything larger than 10-20Mbit CAMs; prior to reduction / expansion / etc, there's scarcely 11B of unique information in an IPv4 route. Adding in some bytes for mysterious 'other stuff', this is easily 4-8MM routes. We'll have to see another knee in route proliferation before this becomes a problem, and space exhaust would most certainly prevent this from happening.

Many smaller networks can and do use PCs for BGP and for forwarding because their total forwarding needs at their core are say sufficiently less than 800mb/s upto which PCs seem to handle. However, the desires and models of these smaller networks don't scale much beyond this level with currently available PC technology.

Agreed... as regards PCs lets remember that history has offered certain commentary on the non-role of PCs (indeed general purpose computers) in network infrastructure... viz. there aren't many GRFs / DDP516Rs / etc. around anymore. I doubt this is an 'interesting problem' for the op or planning community. Regards, Andrew Bender taqua.com