On Tue, 2023-05-09 1:20 p.m., Richard Laager wrote:
I am specifically interested in feedback on this point. But please, only real-world scenarios, no speculation ("someone might ...").

Background:
In my (limited) experience, the filter generator makes a prefix-list using objects from all the approved IRRs that match the contents of the AS-SET.

In my case, that means route(6) objects from ARIN and RADB are combined to make a prefix-list that's bigger than just ARIN or RADB-sourced objects.

The order has not been relevant, nor specified.

No need for NONAUTH sources, and ARIN has completely retired theirs. 

Cheers,
Jonathan

Jonathan Stewart
Network Engineer
LES.NET - AS18451
Desk: 1-204-666-6191
Mobile: 1-204-990-2120
130 Portage Avenue E
Winnipeg, MB  R3C 0A1
CANADA
Questions:
  1. Should I reorder RADB,ARIN to be ARIN,RADB and similar for RADB,RIPE and RADB,APNIC,ARIN? Tentative: Yes.
  2. Should I drop RIPE-NONAUTH choices? Tentative: If nobody is using it by the end of this, I'll just remove it.
  3. Does anyone know if AFRINIC, APNIC, and LACNIC are authenticated?
  4. Does anyone know if people care about LEVEL3's IRR? Tentative: If nobody is using it by the end of this, I'll just remove it.
  5. How do I set the source per participant? I think what we want is the following, for each participant:
  1. I use RADB's web interface to view the specified as-set. If the "source" of that object is an RIR registry, e.g. ARIN, I set the source in IXP Manager to that RIR source. If the source is RADB, I set the source to $RIR,RADB where $RIR is the RIR that issued the participant's ASN. For example, if someone is in the ARIN region, ARIN. If someone is in the RIPE region, RIPE. The idea is to make it easy for them to move to the RIR registry in the future.
  2. I manually trigger the AS and prefix update and make sure I get results.
  3. If the source is just $RIR, I then change this to $RIR,RADB. I manually trigger the AS and prefix update. If that second update changed nothing, I remove RADB. If that update did change something, then I eyeball it and make a decision. I would be looking to detect the scenario where e.g. the as-set is in the ARIN region but references customer ASes/as-sets that are in RADB; in such a case, I need to allow RADB. In contrast, if the records in RADB appear to be outdated and someone has moved to ARIN, I would want to remove RADB.
If that becomes too tedious, a fallback option is to set everyone to something like ARIN,RIPE,RADB or ARIN,RIPE,LACNIC,APNIC,AFRINIC,RADB. (The order of the RIRs is negotiable. I don't really know much about non-ARIN IRR.)

On 5/9/23 11:25, Jay Hanke wrote:
Here are the current IRR sources. Please note ARIN-NONAUTH is not included.

whois.radb.net RIPE
whois.radb.net RIPE,RIPE-NONAUTH
whois.radb.net RADB
whois.radb.net LACNIC
whois.radb.net AFRINIC
whois.radb.net APNIC
whois.radb.net LEVEL3
whois.radb.net ARIN
whois.radb.net RADB,ARIN
whois.radb.net ALTDB
whois.radb.net RADB,RIPE
whois.radb.net RADB,APNIC,ARIN
whois.radb.net RIPE,ARIN

On Tue, May 9, 2023 at 11:14 AM August Yang <0000001654c01f33-dmarc-request@lists.iphouse.net> wrote:

Could you please clarify which IRR source will be included for filter generation? We currently rely on RADb instead of ARIN for our IRR records, and it would be helpful to confirm if this will be used with the new route servers.

--
Richard


To unsubscribe from the MICE-DISCUSS list, click the following link:
http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1



To unsubscribe from the MICE-DISCUSS list, click the following link:
http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1