Hello,
> > Is this deployed like this in a production transit network? How does > > this network handle a failure like in example 2? How does it > > downstream customers handle the race conditions like in example 1? > > Yes, I've ran BGP prefix-list == firewall filter (same prefix-list > verbatim referred in BGP and Firewall) for all transit customers in > one network for +decade. Few problems were had, the majority of > customers were happy after explaining them logic behind it. But this > was tier2 in Europe, data quality is high in Europe compared to other > markets, so it doesn't communicate much of global state of affairs. I > would not feel comfortable doing something like this in Tier1 for > US+Asia markets. Ok, that is a very different message than what I interpreted from your initial post about this: just enable it, it's free, nothing will happen and your customers won't notice. > But there is also no particular reason why we couldn't get there, if > we as a community decided it is what we want, it would fix not just > unexpected BGP filter outages but also several dos and security > issues, due to killing spoofing. It would give us incentive to do BGP > filtering properly. I agree this is something that should to be discussed, but to get there it's probably a very long road. Just look at the sorry state of BGP filtering itself. And this requires even more precision, automation,carefulness and *process changes*. I just want to emphasize that when I buy IP Transit and my provider does this *without telling me beforehand*, I will be very surprised and very unhappy (as I'm probably discovering this configuration because of a partial outage). Lukas