[c-nsp] Growing BGP tables

[Brian Feeny]

I like this, basically all your doing is getting rid of the redundant  
information which serves no purpose other
than taking up space in the RIB/FIB anyways.  And if someone should  
further deaggregate or make a change,
then the new update is going to run its algorithm against the current  
RIB all over again.


On Nov 22, 2004, at 4:16 PM, David J. Hughes wrote:

>
> Hey Rodney,
>
> How about ...
>
> for each prefix received in update
>   for each more specific prefix in RIB
>     if RIB prefix ge /24 and same next hop as update prefix
>       drop RIB prefix
>   if update prefix ge /24
>     for each less specific prefix in RIB
>       if RIB next hop same as update next hop
>         drop update prefix
>
> something like that would filter during the update and wouldn't  
> require another full copy of the table to be held.  I'm sure you guys  
> could come up with something more efficient but the basic idea would  
> work wouldn't it?
>
>
> David
> ...
>
>
> On 23/11/2004, at 7:59 AM, Rodney Dunn wrote:
>
>> 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.
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
------------------------------------------------------------------------ 
------
Brian Feeny, CCIE #8036, CISSP    	e: signal at shreve.net
Network Engineer           			p: 318.213.4709
ShreveNet Inc.             			f: 318.221.6612