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
>
>
