Route Filtering at Scale#

Fedor Vompe, Deutsche Telekom; Sebastian Becker, Deutsche Telekom

• Why: Concrete, adoptable tooling for one of the hardest operational BGP problems — generating correct filters for thousands of sessions when the underlying IRR data is rotten. Up-ranks well on the "tooling others can adopt" criterion.
• What: A tier-1's (AS3320) account of why AS-Set documentation in RIR databases remains foundational and systematically overlooked: missing documentation, explosive AS-Set expansion, and cyclic dependencies all break filter generation, and RPKI ROV alone does not replace this layer — bogon filters, community policy, Peerlock, IRR filters, ROV, ASPA, and OTC all work together.
• How: Presents their toolchain, including the Route Query Specification (RQSpec) language and RIPEDiff, which compensate for poor AS-Set quality. Key framing: AS-Sets are fail-closed, so their contents and changes should be monitored — adding/removing a member set silently changes every parent set. Includes a worked route-leak prevention example (AS3320 requiring a customer's AS-DOWNSTREAM set before accepting prefixes).
• Where applicable: Large operators generating customer/peer filters from IRR; the AS-Set hygiene findings apply to anyone consuming IRR data at any scale. Deutsche Telekom's toolchain specifics are theirs, but RQSpec is worth a look.