[ixpmanager] IRR updating issue with BGPQ3

[Barry O'Donovan (INEX)]

Hi Douglas,

Douglas Fischer via ixpmanager wrote on 04/07/2023 10:56:
> And what about using the AS-SET object declared in PeeringDB?

IXP Manager allows the IX operation to use whatever the member tells 
them to use. Normally this is covered off by an application form / 
onboarding.

IXP Manager will also pull this information from Peering DB as a helper 
when creating a member.

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 be a useful idea in an 'audit' function that shows what's 
different between PeeringDB and the IX but at the end of the day, the 
member tells the IX what's appropriate to use for that particular 
network/IX connection. The IX operator sanity checks it of course.

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.

I think there was talk on this list of one IX writing their own scripts 
to do this.

> 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

We've spent at lot of time at our IX getting networks to register 
route[6]: objects correctly. For us, that mostly meant RIPE. But we have 
larger global networks that ask us to pull IRR info from multiple 
sources (e.g. RIPE, ARIN and APNIC). These are three RIRs so good 
sources of truth - not sure of the syntax here allows more that one 
IRRdb? And we don't want to go and tell them: nope, please use RADB / 
other and merge these.

But even if the syntax supports it, the ability to specify IRR 
source(s), AS number and AS-SET is fully supported in IXP Manager.

  - Barry

> On the first syntax 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."
> 
> On the first syntax 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."
> 
> 
> 
> Em seg., 3 de jul. de 2023 às 19:24, Nick Hilliard via ixpmanager 
> <ixpmanager at inex.ie <mailto:ixpmanager at inex.ie>> escreveu:
> 
>     Paul Emmons wrote on 03/07/2023 22:56:
>>     Agreed, but here is a deeper issue that is happening that I can
>>     show using actual participants.   Member uses ARIN as their IRR -
>>     very high quality IRR and that member doesn't have any down
>>     streams. Member B provides downstream to A but Member B just uses
>>     their AUTNUM and not an AS-SET for Member A.  Member B has their
>>     AS-SET as RADB (not the worst but they do refuse to remove proxy
>>     routes that don't exist).  Member A's prefixes are filtered out of
>>     Member B's announcements in the route servers.  (Member A still
>>     has connectivity on the exchange.  But what happens if Member A's
>>     IX circuit goes down or if Member A isn't on the exchange?
>>
>>     It is probably more of an issue of training member B not to use
>>     AUTNUMs for down streams.  Maybe some form of reporting would be
>>     helpful.  (I always start at the IX looking glass).
> 
>     yep, getting this sort of thing right takes work and engagement with
>     IX participants.  Birdseye is designed to make it easy to catch this
>     sort of misconfig and it's a good idea to take a peek through what
>     prefixes are being rejected to see if the irrdb policy can be
>     tweaked to make it better.
> 
>     Also, pulling data from several sources is troublesome.  At least
>     IRRD4 means it's no longer non-deterministic, although there are
>     still plenty of failure modes.
> 
>     Nick
>     _______________________________________________
>     INEX IXP Manager mailing list
>     ixpmanager at inex.ie <mailto:ixpmanager at inex.ie>
>     Unsubscribe or change options here:
>     https://www.inex.ie/mailman/listinfo/ixpmanager
> 
> 
> 
> -- 
> Douglas Fernando Fischer
> Engº de Controle e Automação
> 
> 
> _______________________________________________
> INEX IXP Manager mailing list
> ixpmanager at inex.ie
> Unsubscribe or change options here: https://www.inex.ie/mailman/listinfo/ixpmanager
> 


-- 

Kind regards,
Barry O'Donovan
INEX Operations

https://www.inex.ie/support/
+353 1 531 3339