87 messages in net.nether.puck.cisco-nsp[c-nsp] Growing BGP tables
FromSent OnAttachments
Vincent De KeyzerNov 19, 2004 6:46 am 
Gert DoeringNov 19, 2004 9:01 am 
David J. HughesNov 21, 2004 5:15 pm 
Ryan O'ConnellNov 21, 2004 5:43 pm 
Brian FeenyNov 21, 2004 9:16 pm 
Jon LewisNov 21, 2004 9:49 pm 
Gert DoeringNov 22, 2004 2:55 am 
Ian DickinsonNov 22, 2004 4:11 am 
Neil J. McRaeNov 22, 2004 4:52 am 
Ian DickinsonNov 22, 2004 5:47 am 
David J. HughesNov 22, 2004 6:45 am 
Gert DoeringNov 22, 2004 7:36 am 
Rainer BorromeoNov 22, 2004 8:39 am 
Jared MauchNov 22, 2004 10:19 am 
Gert DoeringNov 22, 2004 11:07 am 
Łukasz BromirskiNov 22, 2004 11:15 am 
Brian FeenyNov 22, 2004 12:04 pm 
Gunther StammwitzNov 22, 2004 1:51 pm 
Jared MauchNov 22, 2004 2:03 pm 
Michael LyngbølNov 22, 2004 2:15 pm 
Gunther StammwitzNov 22, 2004 2:19 pm 
David J. HughesNov 22, 2004 2:44 pm 
Brian FeenyNov 22, 2004 4:48 pm 
David J. HughesNov 22, 2004 4:53 pm 
Rodney DunnNov 22, 2004 4:58 pm 
David J. HughesNov 22, 2004 4:59 pm 
David J. HughesNov 22, 2004 5:17 pm 
Randy BushNov 22, 2004 5:21 pm 
David J. HughesNov 22, 2004 5:31 pm 
Randy BushNov 22, 2004 5:34 pm 
Brian FeenyNov 22, 2004 5:38 pm 
Rodney DunnNov 22, 2004 8:17 pm 
Rodney DunnNov 22, 2004 8:31 pm 
Michael LyngbølNov 23, 2004 2:44 am 
Neil J. McRaeNov 23, 2004 5:10 am 
Neil J. McRaeNov 23, 2004 5:10 am 
Gert DoeringNov 23, 2004 5:24 am 
Michael LyngbølNov 23, 2004 5:29 am 
Neil J. McRaeNov 23, 2004 5:38 am 
Michael LyngbølNov 23, 2004 5:39 am 
Martin RobinsonNov 23, 2004 5:50 am 
Tantsura, JeffNov 23, 2004 5:51 am 
Neil J. McRaeNov 23, 2004 6:42 am 
Ben CrockerNov 23, 2004 6:54 am 
ege iyiogluNov 23, 2004 9:28 am 
Tantsura, JeffNov 23, 2004 10:17 am 
Rodney DunnNov 23, 2004 10:39 am 
Tantsura, JeffNov 23, 2004 11:12 am 
Rodney DunnNov 23, 2004 11:38 am 
Brian FeenyNov 23, 2004 12:11 pm 
Rodney DunnNov 23, 2004 12:33 pm 
Gert DoeringNov 23, 2004 3:01 pm 
David J. HughesNov 23, 2004 4:42 pm 
Rodney DunnNov 23, 2004 7:33 pm 
Brian FeenyNov 23, 2004 7:37 pm 
David J. HughesNov 23, 2004 8:30 pm 
Mihai CHELARUNov 24, 2004 5:07 am 
Gert DoeringNov 24, 2004 7:27 am 
Rodney DunnNov 24, 2004 8:27 am 
David J. HughesNov 24, 2004 6:28 pm 
Krzysztof AdamskiNov 24, 2004 10:33 pm 
Robert BoyleNov 25, 2004 12:48 am 
Bill WichersNov 25, 2004 12:56 am 
Krzysztof AdamskiNov 25, 2004 9:44 am 
Stephen J. WilcoxNov 26, 2004 9:21 am 
Gert DoeringNov 26, 2004 10:03 am 
Stephen J. WilcoxNov 26, 2004 11:09 am 
Gert DoeringNov 26, 2004 11:20 am 
Stephen J. WilcoxNov 27, 2004 6:53 am 
Rodney DunnNov 30, 2004 6:40 pm 
David J. HughesNov 30, 2004 7:26 pm 
Rodney DunnNov 30, 2004 10:30 pm 
Randy BushDec 1, 2004 12:30 am 
David J. HughesDec 1, 2004 12:57 am 
lee....@census.govDec 1, 2004 8:59 am 
Rodney DunnDec 1, 2004 9:18 am 
lee....@census.govDec 1, 2004 11:18 am 
David J. HughesDec 1, 2004 8:40 pm 
Randy BushDec 1, 2004 8:51 pm 
Rodney DunnJan 27, 2005 11:41 am 
Gert DoeringJan 27, 2005 11:45 am 
Rodney DunnJan 27, 2005 11:48 am 
David J. HughesJan 27, 2005 11:42 pm 
Joe MaimonJan 28, 2005 8:28 am 
Jon LewisJan 28, 2005 9:25 am 
Joe MaimonJan 28, 2005 9:52 am 
Jon LewisJan 28, 2005 10:25 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:[c-nsp] Growing BGP tablesActions...
From:Rodney Dunn (rod@cisco.com)
Date:Nov 23, 2004 12:33:17 pm
List:net.nether.puck.cisco-nsp

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 cisc@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: sig@shreve.net Network Engineer p: 318.213.4709 ShreveNet Inc. f: 318.221.6612