Re: [routing-wg] routing-wg Digest, Vol 102, Issue 3
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
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
Why do we suspect there are many of them?
being among the guilty, i take tassos's point.
And whether they are beacons or not, why treat them any different? Wouldn’t that defeat the purpose? :-)
no, the opposite, assuming the purpose is rov deloyment. tassos's point was that prudent providers considering dropping invalids will measure first. and noise from researchers et alia may cause the op to think they will drop useful prefixes. trying to think of how to ameliorate this, it may be a case for your beloved communities. but nothing fancy or complex, please. randy
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, 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
participants (4)
-
Job Snijders -
Randy Bush -
Tassos Chatzithomaoglou -
Tony Barber