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
On 10 Feb 2020, at 11:00, routing-wg-request@ripe.net wrote:
Send routing-wg mailing list submissions to routing-wg@ripe.net
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 routing-wg-request@ripe.net
You can reach the person managing the list at routing-wg-owner@ripe.net
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 <achatz@forthnet.gr> To: RIPE Routing Working Group <routing-wg@ripe.net> Subject: [routing-wg] RPKI: Forthnet drops invalids Message-ID: <ddadc504-6f58-dd44-09ba-49afcd2072fd@forthnet.gr> 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