[c-nsp] Growing BGP tables

[Joe Maimon]

David J. Hughes wrote:

>>For the record there were only two people
>>that attached cases to:
>>    
>>
>
>
>That's incredible.  I can't believe that so few people would see the 
>benefit in this.  I know one of those attachments was mine.
>
>
>
>  
>
This is something discussed a while back, how to deal with those who 
insert more specifics, right?
This was also mentioned as neccessary to avoid the loophole in Team 
Cymru bogons, correct?
Also mentioned as a way to minimize potential ipv6 table size with 
geographic/ISP consolidation?

I am sure this should be of interest to many. However, I have no 
first-hand interest in this at the moment. It is something that 
interests me because it will mean that the routers I run bgp on in 5 
years wont need a Gig of ram just for the tables.

Others may have more specific immediate term goals they wish to make 
possible.

>>What about if we just had a per neighbor filter that
>>would filter out more specific prefixes as they come in.
>>Once the more specific is filtered then it's gone until
>>you do a soft clear to get it back.
>>    
>>
>
>
>I think this breaks the semantics that we all rely upon too much.  
>Having a specific prefix disappear from some other bloke's network 
>because I remove a supernet isn't really a nice situation to be in.  
>Particularly as I can't do the soft reset for him.
>  
>
Now I am going out on a limb here, for I am hardly a BGP expert, but 
since those who believe they may be viewed as madmen have already 
posted, the way is now clear for those like me, who surely are.

The problem is more that you do not wish the neighbors to propogate the 
more specifics. Let them keep them, as not best.
You could have a global BGP switch or neighbor switch or route map 
statement that amounts to

do-not-advertise-more-specifics ?
   same-as-path
   same-med
    ...
  <cr>

neighbor X.X.X.X remote-as YYYY do-not-advertise-more-specifics ?
                                                         same-as-path
                                                         same-med
                                                         same-something
                                                            ...
                                                         <cr>

Perhaps also needed it a statement like this

do-not-accept-more-specifics

agani per neighbor, global or set in a route-map.

When the neighbor's peer drops the least specific, the decision process 
on the neighbor will run and THAT is when the more specific will get 
advertised to its peers and show up on almost everybodies tables.

This will allow Sites to do traffic engineering to their hearts content.

True this will do little to solve BGP hijacking problems, but I do not 
think encouraging people to announce routes as prevention for that sort 
of thing is desirable.

A local solution to a global problem. Now it is only your peers who 
carry your more specific routes.

>However, going out into theoretical realms here, the main problem is 
>the RIB / FIB consumption right?  Would there be a chance that the 
>removed prefixes could be stored in another are of RAM in a compact 
>manner and tagged with the prefix that caused them to be filtered.  If 
>the non-filtered prefix is removed then the filtered prefixed could be 
>reinstated.  This would allow the current semantics to remain while 
>still giving us some of the benefits we are looking for.
>
>Once again, not knowing anything about the internals of IOS's BGP 
>implementation etc, would something like that be possible or am I 
>barking mad.
>
>
>David
>...
>
>_______________________________________________
>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/
>
>
>  
>