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