Add an "administrative suspension" separate from deletes?

[mxsasha]

IRRD has an RPKI and scope filter. These currently make objects entirely invisible, i.e. when an object becomes invalid or out of scope, an NRTM DELETE is generated.

Is that how we want to do things in NRTMv4? It's the only way in NRTMv3, but we could supporting something like "not a real deletion but more of an administrative suspension" in NRTMv4.

One notable use: when doing high availability setups based on NRTM, after a failover, RPKI invalid objects are entirely lost, i.e. they do not return if their RPKI status changes to be (valid,not_found) later. If there is no failover, the objects are restored if the RPKI status changes. This does not feel nice. But maybe NRTM is just the wrong protocol for failover to begin with.

[mxsasha]

Further thinking:

• We should not have separate levels of deletion.
• The draft should mention under "Policy Restrictions" that RPKI invalidity can also be a reason to not include objects. Wording should be pretty generic.
• NRTMv4 should focus on mirroring between deployments and not be extended for full failover setups. Perhaps IRRD needs its own internal mechanism for those.

[job]

I agree with your thinking here https://github.com/mxsasha/nrtmv4/issues/8#issuecomment-995867938

[stkonst]

I agree with (1). If we go one step back, NRTM is just a "transfer" protocol that takes RPSL objects from IRR and pushes them all the way to member's infrastructure. A route object either exists in IRRdb or does not exist, thus the situation is a little bit like "on-off".

I like (2) as well.

Totally agree with (3), NRTMv4 is not a failover protocol. Failover scenarios should be resolved in upper layers.