FWIW, AS3128 uses some homegrown stuff to wrap bgpq4, bgpq4 provides an ability to deal with concern #3 below for recursion [if you choose to accept the caveats]. See https://github.com/bgp/bgpq4#notes-on-sources. It also handles the $REGISTRY::$THING model. This may just be cool info for the time being, but you may find it interesting. For AS3128 peers I've had to provide a way to list sources per peer; look up AS-SUPRANET in RIPE vs ARIN. The one I want is in ARIN so the ordering matters. Yes, I know AS-$number is a better idea and AS-UWSYSNET is also guilty as charged. -Michael
-----Original Message----- From: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> On Behalf Of Richard Laager Sent: Thursday, May 11, 2023 11:27 AM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers
On 2023-05-11 10:30, Chris Wopat wrote:
Can't folks just specify which IRR in their IRR entry if desired? Ie
ARIN::AS1234
1. bgpq3 does not accept that format, at least in my limited testing.
2. IXP Manager would likely need changes to support that, specifically not passing the argument for sources to bgpq3 if a disambiguation was provided.
3. I think the more important fundamental issue is that a transit AS's as-set might need to reference customer ASes/as-sets that are in other registries.
FWIW we only use RADB but are fine if the common IRR's (but not legacy arin) are used.
Also is there any reason at all to use non-ARIN teritory IRR data? Do any MICE participants have anything in RIPE for example?
See #3 above.
For example, someone like Hurricane Electric can't ask all of their customers worldwide to be in ARIN. Given the way this has historically developed, I don't think it's even reasonable to expect that only-RIR registries are used.
-- Richard