 |
 |
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 <[log in to unmask]> On Behalf Of > Richard Laager > Sent: Thursday, May 11, 2023 11:27 AM > To: [log in to unmask] > 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