[ixpmanager] IRR updating issue with BGPQ3

[Richard Laager]

On 2023-07-04 04:56, Douglas Fischer via ixpmanager wrote:
> The more usual (and relaxed) syntax is AS65123::AS-CUSTOMERS, or 
> AS-JOHNDOENET
> But the mor strict (and more correct, in my opinion) syntax is RADB:: 
> AS65123::AS-CUSTOMERS or RADB::AS-JOHNDOENET
...
> the ASN operator is saying to the world:
> "The AS-SET that defines the cone of prefixes that can be announced by 
> our network is this one. And you should be considered true just the 
> information in the RADB IRR."

Is that what it means, or does it mean "... And you should only look for 
/this object/ in the RADB IRR."? That's how I understood it. And I think 
that's probably the /only/ realistic way to interpret it. Otherwise, you 
literally cannot have cross-IRR relationships. In such a model, what is 
an international ISP supposed to do? Or even an ISP that uses ARIN but 
sells transit to someone that uses ALTDB or RADB.


On 2023-07-04 04:58, Nick Hilliard via ixpmanager wrote:
>> But the mor strict (and more correct, in my opinion) syntax is RADB:: 
>> AS65123::AS-CUSTOMERS or RADB::AS-JOHNDOENET
>
> currently unsupported due to lack of support with underlying tools. 

This is supported in bgpq4, which works fine with IXP Manager if you 
have this trivial patch, which is in bgpq4 1.10 (and 1.11): 
https://github.com/bgp/bgpq4/pull/90


On 2023-07-04 05:10, Barry O'Donovan (INEX) via ixpmanager wrote:
> If you're suggesting we auto-update the AS-SET from PeeringDB after 
> initial onboarding, then that makes me very uneasy and certainly 
> violates the principle of least surprise. The relationship is between 
> IX and member directly, not via PeeringDB.

> There may also be scope to allow a member to opt in and say 'PeeringDB 
> is the source of truth for my network info, pull from there and 
> update'. I'm not sure how comfortable I am with this as an IX operator 
> - would need to think it through. 

Consider this from the point of view of a network that connects to many 
IXPs. If IXPs pull detail X from PeeringDB, then the network only needs 
to update it once, rather than once per IXP. Duplicating the as-set to 
each IXP (e.g. into IXP Manager) is more-or-less only tenable because it 
basically never changes.

Consider how your position would work if the IRR entries themselves had 
to be provided to each IXP. That would be a nightmare!

To argue the other side a bit... There are disadvantages to pulling 
things from PeeringDB. One is that if the information in PeeringDB is 
wrong, the IXP operator cannot fix it. The participant has to.

I've had conflicting input as to whether MICE should import email 
addresses from PeeringDB (forcibly, overwriting what we have). On the 
one hand, this relieves maintenance burden from us. On the other hand, 
it will reduce the quality of our data where participants do not care so 
much about updating PeeringDB.

We ultimately decided /not/ to import email addresses. But some of that 
was also that PeeringDB doesn't make email addresses public, and we do, 
so it's questionable if we should be taking from PeeringDB and then 
publicizing them--as opposed to publicizing the (yes, typically the 
same) email addresses that were given to us directly.


> I think there was talk on this list of one IX writing their own 
> scripts to do this. 
We are doing this at MICE, as are some others, I think.

In my case, the script I wrote pulls the as-set(s), max prefixes, and 
peering policy from PeeringDB. If the as-set name(s) changed, it 
triggers an IRR cache update for that AS in IXP Manager immediately. If 
there is interest, I can provide that script off-list, on-list, or 
whatever. It's not currently in a /public/ GitHub project, but I could 
split some of this stuff out from our private repo if there's interest.

-- 
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.inex.ie/pipermail/ixpmanager/attachments/20230704/ba2177cd/attachment.htm>