On Fri, Jul 13, 2018 at 11:19 AM Grant Taylor via NANOG <nanog@nanog.org> wrote:
The reading I did on RPKI / OV yesterday made me think that it is possible to have validated routes preferred over unknown routes which are preferred over invalid routes. So I'd think that you could still have the routes through your core but conditionally advertise the prefixes to customers based on their desires.
you get the option at input (from transit/peering edge say) to evaluate the 'rpki status' of a particular route, then set normal bgp attributes based on that evaluation, so yes you can: valid == localopref 1000 && community-A unknown == localpref 80 && community-B invalid == localpref 1 && community-Z but given: 192.168.0.0/16 - valid 192.168.0.0/17 - unknown 192.168.0.0/24 - invalid your routing system will still forward toward the 192.168.0.0/24 prefix because 'longest prefix match'. Job's plan, I think, is that you reject/drop/do-not-accept the 'invalid' prefix(es) and hope that you follow another / proper path. Perhaps Mark could send along ONLY the valid/unknown routes to his customer, or some mix of the set based on what type of customer: super-sekure-customer - valid only sorta-sekure-customer - valid/unknown wild-wild-west-customer - all it sounded like Mark didn't want to deal with that complexity in his network, until more deployment and more requests from customers like; Customer: "Hey, why did my traffic get hijacked to paY(omlut)pal.com yesterday?" Mark: "because you didn't ask for 'super-sekure-customer config? sorry?" I could have misunderstood either mark or job or you.. of course.
I would appreciate it if someone would be kind enough to explain what I'm misunderstanding. Or better, point me to some better documentation to read myself.
Thank you from the peanut gallery.
-- Grant. . . . unix || die