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
