[c-nsp] Growing BGP tables

[David J. Hughes]

Anything that reduces the consumption of RIB and
FIB resources as a result of de-aggregation etc
would be a very welcome step in the right
direction.  Thanks for looking into this
Rodney.


David
...


On 24/11/2004, at 3:33 AM, Rodney Dunn wrote:

> My point was that you can't do it with BGP
> because you don't have a way to request a
> re-advertisement from a peer when the
> less specific goes away.
>
> There is a possiblity we could keep the
> more specifics out of the RIB which would
> save memory there and in the FIB.
>
> That being said the best that can
> be done currently appears to block
> the routes from going in the RIB.
> We are looking to see how complex that
> would be to do.
>
> Rodney
>
>
> On Tue, Nov 23, 2004 at 11:11:52AM -0600, Brian Feeny wrote:
>>
>>
>> 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
>