Re: Something observed while doing IRR cleanup (generic name collisions)

[Job Snijders via NANOG <nanog () nanog org>]

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