Summary

  • James Bensley told RIPE 93 that recursive AS-SET expansion left his network with a filter problem even after a customer refused to remove nested entries.
  • His separate excl-members Internet-Draft proposes a set-owner control for omitting named ASNs or sets during recursive resolution. The Datatracker record lists one individual version, not an RFC or deployed feature.

The customer could walk

The exchange was blunt. Bensley said his team had asked a customer to clean up its AS-SET and warned that the link could be shut off. The customer had other upstreams and declined. The engineering team was left with the messy expansion; the customer had an exit.

At RIPE 93, Bensley said an AS-SET rooted at AS5405 expanded to about 76,000 ASNs and 1.3 million prefixes. He said recursive entries included networks that were not his upstreams. Peers using the set could not generate the filters they needed for his network.

Those are Bensley’s reported figures from the meeting transcript, not a current RIPE Database count. The transcript gives no collection date or resolver configuration. It does record the specific bind: a route-filter input had grown far beyond the relationships the operator meant to describe.

A name is not a membership audit

RPSL lets an AS-SET list autonomous systems directly or refer to another set. A resolver can follow those references down the tree and collect the resulting members. Hierarchical names help establish who may create a set under a parent. RIPE Database documentation separately says that referenced members do not need to exist when a set object is created. A well-formed name therefore does not certify that every nested member belongs in the operator’s customer cone.

The old incentives did little to close that gap. A customer with several upstreams could refuse cleanup while the network building filters carried the consequence. Threatening disconnection is an expensive bargaining chip when the customer can move traffic elsewhere.

Put the exclusion in the parent set

In April, Bensley published an individual Internet-Draft defining excl-members for AS-SET and route-set objects. The field would let an owner name an ASN or registry-qualified set that a resolver must omit while expanding the parent’s members. The exclusion would follow that branch through nested sets; it would not spill into a sibling branch.

That is a different intervention from asking the customer to repair its own record. The set owner could narrow the expansion it publishes even when a child object stays as it is. In the draft’s examples, the exclusion applies during resolution and can overrule a later inclusion on the same branch.

That control has a price. If an owner excludes the wrong set, a downstream filter can lose routes it was supposed to accept. The draft requires registry-qualified set names to identify which object is being excluded and keeps exclusions local to the branch where they are declared. Those rules make the proposal more precise; they do not demonstrate that a registry or resolver has implemented it.

The fix is still a draft

The IETF Datatracker lists only version 00 of draft-bensley-rpsl-exclude-members, with an informational intended status and an expiry date of 17 October 2026. The related GROW working-group draft for registry-scoped set members is marked expired and archived as of 24 October. Neither record is an RFC, and the RIPE 93 transcript shows no production deployment.

RIPE’s transcript documents the filter-generation dispute, not a route leak or outage. A dated before-and-after resolver trace, with the exact set versions and exclusion rule, would show whether this proposal repairs the reported expansion in practice.

Sources