On Fri, 18 Oct 2019 at 23:45, Lukas Tribus <lists@ltri.eu> wrote: Hey Lukas,
I'm saying this breaks valid configurations because even with textbook IRR registrations there is a race condition between the IRR registration (not a route-object, but a new AS in the AS-MACRO), the ACL update and the BGP turn-up of a new customer (on AS further down).
I'm not proposing an answer, I'm asking a question. Could it be that the utter disinterest in working BGP filters is consequence of it not actually mattering in turn-ups in typical case? And would the examples be same, if we were not so disinterested in having proper BGP filters in place? If in common case we did ACL, would we evolve different mechanisms to ensure correctness of filtering before fact? Perhaps common API to query state of filters in provider networks? Perhaps maintenance window to turn-up new transit with option to fall back immediately and complain about their configurations?
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. 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. -- ++ytti