Hi Dan! You highlight a common pitfall in IRR-based prefix filter generation. On Mon, Apr 11, 2022 at 09:56:59AM -0700, Dan Mahoney (Gushi) wrote:
[snip] as-set: AS-PEERS descr: Peer AS Numbers members: AS132251,AS132561,AS132516 source: APNIC
as-set: AS-PEERS descr: swell.network Peers members: AS-HE,AS-NTT source: ARIN
..four separate organizations felt it would be clever to create a vaguely-named AS-PEERS object, each in a different IRR, because the various IRR's all allow this, and don't check for the existence of objects in another. No IRR's require any special names, nor do they block on any generic names. No IRR sends a member warnings when their objects exist in more than one registry with different data.
The RPSL RFCs permit a syntax which helps increase the potential for 'uniqueness' of object names across multiple databases: the trick is to prepend the object with one's ASN. An example: "AS15562:AS-SNIJDERS" This approach is also known as "hierarchical AS-SET naming". IRRd v4.2 instances require this naming approach for newly created objects. Because of this feature the LACNIC IRR data source contains only hierarchically named AS-SETs! Progress might seem slow, but all journeys start with a few small steps. :-) Hierarchical naming does not prevent the existence of duplicate names across IRR databases, but it sure does help!
I haven't tried to query the peeringdb API to see if any of these are used as advertised AS-Sets for public use, or if people just created public objects for their own internal tools. I'm sure this is not the only case of this.
This might be why we can't have nice things.
Patience is the path towards nice things :-) Kind regards, Job