[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IRR AS-SET best practices - AS-SET Clash
The hierarchical as-set strategy has the problem that many fails to parse
it correctly. We use it at NL-IX with the result that their portal believe
we have no peers.
Den 24. jan. 2018 15.50 skrev "Job Snijders" <job at ntt.net>:
On Wed, Jan 24, 2018 at 02:23:48PM +0000, Nick Hilliard wrote:
> Alain Hebert wrote:
> > Any feedback on best practices and "other avenue" about IRR naming?
> Known problem - you're asking for trouble unless you filter IRRDB
> queries by source:
> There isn't a global namespace for as-set names, unless you use
> source: as a database key element.
In addition to the above, one could use "hierarchical" AS-SET names, in
some databases (from the top of my head: APNIC, AfriNIC, RIPE) only the
owner of the ASN can create AS-SETs under that ASN's namespace. But more
importantly: using the ASN in the AS-SET name chances of collision are
reduced. Example: I defined "AS15562:AS-SNIJDERS" in the RIPE database,
instead of "AS-SNIJDERS". Same for "AS2914:AS-GLOBAL" in NTTCOM.
--- thread hijack ---
Coincidentally, I'm working to define something like "AS-SETs in RPKI".
There are a number of downsides to "AS-SETs in IRR": collisions between
databases can exist, it is hard to figure out what AS-SET to use for
what ASN (we rely on service order forms, peeringdb or guessing for
that), and the way the recursion was done can too easily result in
I'd be interested to know what others think about improving feature
parity between IRR and RPKI, and while doing that make the bad aspects
of AS-SETs go away and keep the good parts. Thoughts?
ps. raised the question here too https://mail.lacnic.net/