[c-nsp] Growing BGP tables

[Brian Feeny]

You just base it on statistics.

As you take in routes, you scan them against all previously taken in  
routes, and if an aggregate exists that shares the
same next hop, you drop the current route.

Sure, if you took in routes from largest to smallest, you would be  
screwed and out of memory, but they will come in at
different sizes, so you will hold a /24, and maybe 4000 routes later  
you will see that /24 is part of a /16 that is learned,
so you drop the /24.  You don't take the entire table in and then  
process it, you scan each route as it comes in against
what has already come in.

Brian

On Nov 22, 2004, at 3:59 PM, Rodney Dunn wrote:

> I'm trying to think through this and how/if
> it could be implemented.
>
> I don't see how you can do it without holding
> a full copy of all updates because you are
> making a decision for one update based on
> matches of all other updates which is
> back to storing a shadow copy.
>
> Rodney
>
>
>
> On Mon, Nov 22, 2004 at 03:48:57PM -0600, Brian Feeny wrote:
>>
>>
>> There are alot of tools like that that would be interesting to have
>> built in.
>> Or one that says "If this /24 has the same next-hop as a larger
>> aggregate, drop the /24",
>> something like that would need to be buffered and pruned during the
>> actual inbound route
>> updates.......It would be interesting to see how much memory could be
>> conserved.  You would
>> not just be reducing BGP RIB, but RIB and FIB as well.
>>
>> Brian
>>
>>
>>
------------------------------------------------------------------------ 
------
Brian Feeny, CCIE #8036, CISSP    	e: signal at shreve.net
Network Engineer           			p: 318.213.4709
ShreveNet Inc.             			f: 318.221.6612