Allow one data source to 'drown out' other data sources

[job]

Allow one data source to 'drown out' other data source. For instance RPKI data supersedes IRR data, by using RPKI data we can combat stale IRR proxy route registrations.

Consider the following:

route: 192.0.2.0/24
origin: AS1
source: NTTCOM

route: 192.0.2.0/24
origin: AS2
source: RPKI

It would be nice if !gAS1 would not return 192.0.2.0/24 because of the existence of the RPKI entry covering 192.0.2.0/24. In operational terms the owner of prefix 192.0.2.0/24 should create a second RPKI ROA if they'd want to allow AS1 to originate the prefix.

Similarly not all IRR sources are equal, the APNIC database contains better data than ALTDB or NTTCOM.

[mahtin]

You are bringing up more than one item.

• RPKI vs IRR
• RPKI priority over IRR
• IRR priority
• Override/masking of data

In the first case, I would highly recommend synthesizing a route object from an RPKI ROA, just so that a whois (or hopefully RDAP) query returns useful information.

In the second and third case, sadly I believe that you will have to leave that choice down to the consumer of the data. While we can all agree that some of the IRR sources are less useful than others (or some similar polite way of saying that), there's still a bias on the part of the consumer that needs to be kept. NTTCOM may choose to prioritize it's data over (lets say) REACH or equivalent. REACH may well decide the complete opposite. Etc etc.

That said, I would see the default for RPKI to override IRR data any day!

In the forth case (overriding or masking of data), you are again proposing a different model than classic IRRs. Just like prioritization, as described above, there maybe a end consumer of data choice required, which means that the existing query methods - yes, I'm talking about the atrocious !gAS65001 syntax, may not suffice.

Martin

PS: I think you meant AS65001 and AS65002 because it would be wrong to use real ASNs in an documentation example. Mind you, I commend you for using 192.0.2.0/24.

[job]

@mahtin the operator of the IRRd instance will be able to decide what data they expose to their consumers (percolated through whatever local policy). NTT may make other choices than RADB. The lack of ability to define policy at the IRRd level is a shortcoming of IRRdv3 that will not be repeated.

[job]

@mahtin Conceptually there will be multiple attachment points to apply policy: (1) when feeding data into the IRRd instance, (2) when exposing data to consumers (either via WHOIS or via API), (3) locally inside the client.

The !g syntax is severely limited in terms of parameters and only serves to cater to legacy clients. Legacy clients in particular are a motivation to have the ability to define policy at the IRRd level, because those legacy clients may be challenging to extend as well. Queries coming in via API is a different story, in an API it'll be easier to expose what data is masked due to local policy or not.

[job]

Additional notes:

All of this only applies to route/route6: objects.

RPKI data sources is expected to refresh every 30 - 60 minutes.

After the RPKI source refreshes, the authoritative database must be scanned and all conflicting objects must be deleted (also send deletes via NRTM, and send notification mails "this was deleted because of conflict with datasource X").

Objects received via NRTM from other mirrors must be marked as ineligible (or some flag in the data model) the moment they conflict with the outcome of the RPKI Origin Validation procedure. It is possible that objects change state back and forth (for instance when a RPKI ROA is deleted).

[job]

another aspect that is worth considering is slipstreaming RPKI as data source into the NTTCOM database so that people automatically get route objects in a well-known database when creating ROAs. We'll need to think about that.

[job]

This issue needs to be rewritten for clarity

[job]

Closed in favor of the description at #197