I keep seeing/hearing this when RPKI is discussed. While strictly true, the way I've understood this, it will also defeat one of the main purposes of RPKI, namely to be able to defend against certain route hijacking or route leak events, where more-specific routes are propagated and accepted.
In order to defend against that type of events, due to the "longest matching prefix always wins, irrespective of BGP attributes" behaviour (which isn't a trait of BGP but of how our routers look up forwarding entries), you cannot have your router configured to install RPKI- invalid prefixes in your forwarding table.
from draft-ietf-sidr-origin-ops-20.txt Sec 5. Routing Policy Operators should be aware that accepting Invalid announcements, no matter how de-preffed, will often be the equivalent of treating them as fully Valid. Consider having a ROA for AS 42 for prefix 10.0.0.0/ 16-24. A BGP announcement for 10.0.666.0/24 from AS 666 would be Invalid. But if policy is not configured to discard it, then longest match forwarding will send packets to AS 666 no matter the value of local preference. As origin validation will be rolled out incrementally, coverage will be incomplete for a long time. Therefore, routing on NotFound validity state SHOULD be done for a long time. As the transition moves forward, the number of BGP announcements with validation state NotFound should decrease. Hence an operator's policy SHOULD NOT be overly strict, and should prefer Valid announcements, attaching a lower preference to, but still using, NotFound announcements, and dropping or giving a very low preference to Invalid announcements. as you point out, that latter is ill advised, and i have a fix in my edit buffer for the next rev as follows: Merely de-preffing Invalids is ill-advised, see previous paragraph. randy