* James Breeden
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....
We started taking defaults from our transits and filtering most of the DFZ over three years ago. No regrets, it's one of the best decisions we ever made. Vastly reduced both convergence time and CapEx. Transit providers worth their salt typically include BGP communities you can use to selectively accept more-specific routes that you are interested in. You could, for example, accept routes learned by your transits from IX-es in in your geographic vicinity. Here's a PoC where we used communities to filter out all routes except for any routes learned by our primary transit provider anywhere in Scandinavia, while using defaults for everything else: https://www.redpill-linpro.com/sysadvent/2016/12/09/slimming-routing-table.h... (Note that we went away from the RIB->FIB filtering approach described in the post, what we have in production is traditional filtering on the BGP sessions.) Tore