If one border router receives invalid route, but due to RPKI issues mark
it as 'not-found', while some other border router receives a valid route
and mark it as 'valid' (does not matter whether by communities or directly
by local_pref), then internal routers would prefer the valid route,
while if there is no marking they can switch to the invalid.
You are of course right that the presence of a marker can be used to facilitate route decision making, this generally holds true. However I maintain that the most robust design pattern is to fix “the RPKI issue”, rather than uppref valid routes in the other half of the network. (Or accept the fact that one’s routers might select RPKI-invalid routes as best path because a router isn’t aware that the path is RPKI-invalid.)
Modifying the local_pref of routes based on the RPKI validation state introduces issues such as increased potential for BGP churn, but also makes deploying RPKI in medium/large sized networks significantly harder.
Whether a temporary “RPKI issue” (crashing validator) causes an inconsistent state in the overall network, or it being a slow moving multi-month RPKI-ROV deployment where POPs are converted one-by-one, to me it seems there isn’t really a material difference between the two conditions.
Modifying BGP path attributes based on the validation state doesn’t seem the best current practise. It’s too bad there is a ton of documentation out there (outside the BIRD project) that says things like “instead of rejecting, you can downpref invalid routes!” (which from a security point of view because of LPM is futile).
Kind regards,
Job