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
|