At the time we rolled RPKI out we were something of an early adopter. Our greatest fear was we would be inundated with faults caused by routes being dropped because they failed the RPKI checks. From memory there were around 5000 bad routes in the full internet table at that time. 

Our initial rollout was dropping invalid routes from our external neighbours, so this meant peering exchanges, NREN peers, and transit. We only recently started dropping invalids from customers. We applied the same policies to both commodity and NREN peers. 

Over the first three months of our deployment we had only a couple faults caused by rejecting routes. Since then we've not had any faults.

The one take-away from this experience is the difficulties debugging a fault where we're rejecting a route. Unlike a route where we're taking a suboptimal path which you can see in your route table, a route that fails its ROA checks is simply missing. Working out where in your network you're rejecting it can be hard. On our Juniper MX platform this means walking around all the boxes with external peering sessions and checking the hidden routes. For our first fault we worked out another New Zealand based provider should have been announcing the missing route and accused them of not announcing it to REANNZ. Once we figured out it was us rejecting the route we had a chat with them about ROA's and the fault was quickly fixed. 

So I think the lesson here is that your support staff need to be aware of RPKI and the challenges it can cause.  

Thanks,

Dylan Hall

Senior Network Engineer

REANNZ Ltd