Hello Job, Thank you very much for your reply! I got that no AS can actually filter all the invalids. Yet I was trying to figure out why we couldn't see reasonable amount of withdrawals from AS6939 about invalid prefixes, as they explained how they implement ROV (https://mailman.nanog.org/pipermail/nanog/2020-June/108309.html). Perhaps we need to learn their detailed implementations. Thank you very much! Best wishes, Sun Letong 在2022-11-08 00:11:24,Job Snijders<job@fastly.com>写道：
Dear 孙乐童,
On Mon, Nov 07, 2022 at 08:40:57PM +0800, 孙乐童 wrote:
We learned from Cloudflare's https://isbgpsafeyet.com/ that some ASes have deployed RPKI Origin Validation (ROV). However, we downloaded BGP collection data from RouteViews and RipeRis platforms and found that some ROV-ASes can announce some invalid routes. For example, from RIB data at 2022-10-31 00:00:00, 13 out of 17 ASes which declared to deploy ROV announced invalid routes, and we list the number of related prefixes for each AS below.
[snip]
As a comparison, we count the invalid routes the non-ROV ASes (also declared in https://isbgpsafeyet.com/) announces, as below:
We can see that ROV ASes announced apparently fewer invalid routes compared to the non-ROV ASes, though they did not filter all the invalids.
[snip]
Can anyone help us to correctly interpret this case? Thank you very much.
You ask great questions! I hope an answer to your questions can be found in a message I sent a year ago:
https://mailman.nanog.org/pipermail/nanog/2021-April/213346.html
The summary: in any sufficiently large network, chances are not 100% of all equipment supports RPKI-based BGP Route Origin Validation; in such cases a handful of invalid routes may still percolate through the system. Another contributing factor might be certain types of software upgrades; where ROV temporarily is disabled on one or more devices. Or perhaps an ISP made a handful of exceptions for test/beacon invalid routes to propagate.
Kind regards,
Job