Summary

  • In his RIPE 92 original presentation, Sebastian Becker says an AS-SET used to build a provider's customer-cone filter should list that provider and its downstreams. Peers and upstreams belong in separately labelled records.
  • Becker describes a pre-session test: compare the routes a customer says it will announce with the breadth produced by the generated filter. His example of 100 promised prefixes against 10,000 in the route set is illustrative, not a reported incident.

The customer list is not a harmless address book. A transit provider uses it to decide which BGP routes it will accept, and other networks can use the same published relationships to build their own filters. Sebastian Becker, Deutsche Telekom's AS3320 peering manager, told RIPE 92 that an AS-SET must say what kind of relationship it describes before an operator lets it shape a live session.

For a customer-cone set, the membership is the operator's own AS and its downstream ASNs or AS-SETs. A peer or upstream can be documented, Becker said, but in a distinct set with a clear purpose. Mix them into the customer cone and the expansion may include routes the provider never intended to receive from that customer. The record starts as a description; the generated filter turns the description into permission.

The database name alone is another trap. Becker pointed to AS-SETs with the same name in different IRR databases when only one copy is maintained. An operator that sweeps in stale copies can broaden a filter with old relationships. His remedy is prosaic: tell other operators where the set is maintained, document its purpose, and check the resulting filter against the planned relationship.

Becker gave the room a test case, not a claim of a particular outage. A customer says it will announce 100 prefixes; the generated route set grows toward 10,000. Before AS3320 enables the BGP session or accepts that filter, his team runs a test and sends the discrepancy back to the customer. He also wants the AS-SET prepared before the new customer starts sending routes, so valid announcements have a filter waiting. The official talk record identifies Fedor Vompe as his co-presenter; the later numerical survey of AS-SET loops belongs to Vompe's part of the session.

In a 2024 RIPE-list announcement, Becker said AS3320 planned to reject RPKI-invalid origins while accepting unknown ones. Origin checks and customer-cone documentation answer different questions: who may originate a prefix, and which relationship should carry it. A current set of customer-specific filter diffs, accepted routes and correction timestamps would show how often Becker's preflight catches a real mismatch.

The operational decision comes before the first route arrives. A clean relationship record makes automation useful. A sloppy one lets the router enforce somebody's untidy spreadsheet at network speed.

Sources: RIPE 92 primary transcript · official talk page · RIPE NCC biography · Becker's original 2024 announcement.