Print

---

I am specifically interested in feedback on this point. But please, only 
real-world scenarios, no speculation ("someone might ...").

Background:

  * This setting is per-participant.
  * Order is important. When looking for a given IRR object, the first
    source that includes that object will be used.
  * I think we want to prefer RIR-authenticated sources over others.

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 
> <[log in to unmask]> 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