<!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8"> </head> <body><div style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;"> <p dir="auto">Hello James (this time while keeping the list in cc),</p> <p dir="auto">On 7 Nov 2022, at 10:01, James Bensley wrote:></p> </div><div class="plaintext" style="white-space: normal;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #5855D5; color: #5855D5;"><p dir="auto">Specifically, I want to discuss adding supported for the "::" source notation in the "members" field of an AS-SET or Route-Set object. […]</p> </blockquote></div> <div class="markdown" style="white-space: normal;"> <p dir="auto">Thanks for bringing this up. I agree with your problem statement - I<br> have been thinking about this before. In theory, you propose a good<br> solution that already seems current practice here and there. However,<br> there is a big catch.</p> <p dir="auto">For context, I am the developer and maintainer of IRRD v4, which is<br> currently used by the NTTCOM, ARIN, LACNIC, TC, IDNIC and LEVEL3<br> authoritative registries along with local deployments that run local<br> mirrors. A few other registries run older versions of IRRD. I am not an<br> IRR operator myself.</p> </div><div class="plaintext" style="white-space: normal;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #5855D5; color: #5855D5;"><p dir="auto">$whois -h whois.radb.net AS-GOOGLE | grep -E "as-set|members" […] <br> The above query to RADB produces the correct information. [...] <br> 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) […]</p> </blockquote></div> <div class="markdown" style="white-space: normal;"> <p dir="auto">Many users do not query AS sets like this, but rather have IRRD do the<br> set resolving, with queries like <code style="padding: 0 0.25em; background-color: #F7F7F7;">!a</code> [1] that returns all unique<br> prefixes originated by all ASes in an AS set. This is much more<br> efficient, and tools like bgpq4 use this feature if available.</p> <p dir="auto">If we adopt your proposal, and the IRR becomes a mix of prefixed<br> (RIPE::AS-DEMO) and non-prefixes AS set names (AS-DEMO), IRRD will<br> interpret prefixed names as the full name, will fail to find any set<br> named RIPE::AS-DEMO, and set resolving will be incomplete. Existing code<br> simply won’t have any understanding of the prefix, and without<br> mitigation, we risk making AS set resolving more broken.</p> <p dir="auto">You could work around this by adding the prefixed and non-prefixed name,<br> but that will produce inconsistent results depending on a prefix-aware<br> set resolver, and risks duplicate records getting out of sync.</p> <p dir="auto">Other than that, the only way I see is to first enable support for this<br> in common AS set resolver code, and only support its use in objects once<br> resolver updates are widely deployed. But that will take quite some<br> time. It’s not terribly complex to add support to IRRD v4, but then we<br> will need all operators to upgrade, and some are still on v2/v3. There<br> will also be custom internal set resolving code in some organisations.</p> <p dir="auto">Sasha</p> <p dir="auto">[1]<br> <a href="https://irrd.readthedocs.io/en/stable/users/queries/whois/#irrd-style-queries">https://irrd.readthedocs.io/en/stable/users/queries/whois/#irrd-style-queries</a></p> </div> </div> </body> </html>