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