Hello James (this time while keeping the list in cc),
On 7 Nov 2022, at 10:01, James Bensley wrote:>
Specifically, I want to discuss adding supported for the "::" source notation in the "members" field of an AS-SET or Route-Set object. […]
Thanks for bringing this up. I agree with your problem statement - I
have been thinking about this before. In theory, you propose a good
solution that already seems current practice here and there. However,
there is a big catch.
For context, I am the developer and maintainer of IRRD v4, which is
currently used by the NTTCOM, ARIN, LACNIC, TC, IDNIC and LEVEL3
authoritative registries along with local deployments that run local
mirrors. A few other registries run older versions of IRRD. I am not an
IRR operator myself.
$whois -h whois.radb.net AS-GOOGLE | grep -E "as-set|members" […]
The above query to RADB produces the correct information. [...]
For this reason I ask, what it would take to allow the use of the "::" indicator in the "members" field of an AS-SET and Route-Set so that in my own AS-SET I can specify the correct source for the direct members (my customers) […]
Many users do not query AS sets like this, but rather have IRRD do the
set resolving, with queries like !a [1] that returns all unique
prefixes originated by all ASes in an AS set. This is much more
efficient, and tools like bgpq4 use this feature if available.
If we adopt your proposal, and the IRR becomes a mix of prefixed
(RIPE::AS-DEMO) and non-prefixes AS set names (AS-DEMO), IRRD will
interpret prefixed names as the full name, will fail to find any set
named RIPE::AS-DEMO, and set resolving will be incomplete. Existing code
simply won’t have any understanding of the prefix, and without
mitigation, we risk making AS set resolving more broken.
You could work around this by adding the prefixed and non-prefixed name,
but that will produce inconsistent results depending on a prefix-aware
set resolver, and risks duplicate records getting out of sync.
Other than that, the only way I see is to first enable support for this
in common AS set resolver code, and only support its use in objects once
resolver updates are widely deployed. But that will take quite some
time. It’s not terribly complex to add support to IRRD v4, but then we
will need all operators to upgrade, and some are still on v2/v3. There
will also be custom internal set resolving code in some organisations.
Sasha
[1]
https://irrd.readthedocs.io/en/stable/users/queries/whois/#irrd-style-queries