[NLNOG] deploying RPKI based Origin Validation

[Weber, Markus]

Hi Job,

| From my perspective you are almost squacky clean! I see two invalids
| 88.159.27.0/24 (invalid, but covered by valid route 88.159.0.0/16) and
| 94.103.31.0/24 (also covered by valid 94.103.16.0/20). I'm sure there
| are more, but if you drop these two prefixes it shouldn't result in loss
| of connectivity because there are covering valid routes.

>From that perspective - yes, close to clean. But don't surprise and annoy
customerswithout warning them upfront that eventually their or their 
customer's (TE) announcement suddently stop to work ... esp. don't give
your (my) 1st line NOC a very hard time then in the need to explain it to
the customer when he calls in the middle of the night (esp. when simple
IRR filtering often causes headache).


|> Yes, there are some (not just a few) invalids out there, not covered
|> by not-invalid less specifics: https://as286.net/data/ana-invalids.txt
|> (note: not a perfect report, limited to AS286 peer routes, downstream
|> routes excluded, potential wrong altpfx for <12 prefixes [...])

| We should compare notes on how you generate this. I looked today and
| only 2,200 prefixes become unreachable due to misconfigured RPKI ROAs.
| http://instituut.net/~job/rpki-report-2018.07.12.txt - I think the
| majority of invalid more-specifics simply are attempts at
| traffic-engineering and not critical.

Take invalids received from eBGP peers on every PE, note prefix and path.
Take "clean" (without invalids) table of DFZ. For every invalid lookup in
the invalid free DFZ table if there's a valid same or a less specific.
If not, altpfx=NONE and expect connectivity issue.

Your 2200 are more or less the 2277 ones in my list with altpfx=NONE 
Aggregated ~876 ;-) (#of IPs remain the same).


Cheers,
Markus