I think for a provider that starts dropping invalids, it would make its life easier (*) to know in advance for what prefixes to skip processing (monitor traffic, contact owner, etc).
(*): Assuming providers have test prefixes to spare and these get increased over time... Job Snijders wrote on 10/2/2020 16:42: > Why do we suspect there are many of them? And whether they are beacons > or not, why treat them any different? Wouldn’t that defeat the > purpose? :-) > > Kind regards, > > Job Tony Barber wrote on 10/2/2020 16:40: > An agreed community value to signify test invalid prefixes would help. Maybe > a ripe doc (399 or 706) could be updated? > Maybe a discussion point for next meeting. > > > Tony I had something else in my mind, something to be originated from the validation software, after it has been somehow stamped in the RIR's db. -- Tassos > >> On 10 Feb 2020, at 11:00, [email protected] wrote: >> >> Send routing-wg mailing list submissions to >> [email protected] >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.ripe.net/mailman/listinfo/routing-wg >> or, via email, send a message with subject or body 'help' to >> [email protected] >> >> You can reach the person managing the list at >> [email protected] >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of routing-wg digest..." >> >> >> Today's Topics: >> >> 1. RPKI: Forthnet drops invalids (Tassos Chatzithomaoglou) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Mon, 10 Feb 2020 12:25:08 +0200 >> From: Tassos Chatzithomaoglou <[email protected]> >> To: RIPE Routing Working Group <[email protected]> >> Subject: [routing-wg] RPKI: Forthnet drops invalids >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset="utf-8" >> >> Hi to everyone, >> >> I would like to inform you that it's been almost one month since >> Forthnet started dropping invalid prefixes on all peering/transit links, >> either national or international. It's important to note that during >> this month we haven't received any complaints. >> >> Having monitored the invalid prefixes for more than a year and >> experimenting with routing them across different links, we decided that >> it was time to move to the next phase and start dropping prefixes that >> are declared as invalid in the RPKI ecosystem. >> >> Two were the main reasons that helped us take the drop decision: a) >> during the last year our volume of invalid prefixes traffic decreased >> from ~1% of total traffic to less than 0,2%, b) we updated our prefix >> validation policy by including a whitelist (until we evaluate SLURM) in >> order to bypass issues quickly if/when they arise. >> >> Note #1: in the context of the above actions we have noticed that >> invalid prefixes used for testing purposes have recently begun to grow >> (each large provider creates one?). This may lead to incorrect >> conclusions in the future (at least in terms of prefixes, since i don't >> expect traffic from those). Maybe these invalid prefixes should have >> some extra "attributes" in order to be recognized more easily while >> troubleshooting. >> >> Note #2: In order to increase adoption of a similar policy, maybe MANRS >> should be updated to promote dropping invalids. If i'm not mistaken, >> their current action is about creating ROAs only. >> >> -- >> Tassos >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> <https://lists.ripe.net/ripe/mail/archives/routing-wg/attachments/20200210/719edec3/attachment-0001.html> >> >> End of routing-wg Digest, Vol 102, Issue 3 >> ****************************************** >
