Partial vs Full tables

Tue Jun 9 15:35:29 UTC 2020

Hello,

   Some time ago we had a similar discussion on this list, in that 
moment I shared a small study we did in LACNIC but we had it only in 
Spanish. Here is the version in English (BGP: To filter or not to filter 
by prefix size. That is the question ):

https://aaaa.acostasite.com/2019/07/bgp-to-filter-or-not-to-filter-by.html

Alejandro,

On 6/4/20 11:00 PM, James Breeden wrote:
> I have been doing a lot of research recently on operating networks 
> with partial tables and a default to the rest of the world. Seems like 
> an easy enough approach for regional networks where you have maybe 
> only 1 upstream transit and some peering.
>
> I come to NANOG to get feedback from others who may be doing this. We 
> have 3 upstream transit providers and PNI and public peers in 2 
> locations. It'd obviously be easy to transition to doing partial 
> routes for just the peers, etc, but I'm not sure where to draw the 
> line on the transit providers. I've thought of straight preferencing 
> one over another. I've thought of using BGP filtering and community 
> magic to basically allow Transit AS + 1 additional AS (Transit direct 
> customer) as specific routes, with summarization to default for the 
> rest. I'm sure there are other thoughts that I haven't had about this 
> as well....
>
> And before I get asked why not just run full tables, I'm looking at 
> regional approaches to being able to use smaller, less powerful 
> routers (or even layer3 switches) to run some areas of the network 
> where we can benefit from summarization and full tables are really 
> overkill.
>
>
> *James W. Breeden*
>
> /Managing Partner/
>
> //
>
> *logo_transparent_background*
>
> *Arenal Group:* Arenal Consulting Group | Acilis Telecom | Pines Media
>
> PO Box 1063 | Smithville, TX 78957
>
> Email: james at arenalgroup.co <mailto:james at arenalgroup.co> | office 
> 512.360.0000 | www.arenalgroup.co <http://www.arenalgroup.co/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200609/9c9da04a/attachment.html>