On Tue, Jan 17, 2017 at 12:10 AM, joel jaeggli <[email protected]> wrote: > On 1/15/17 6:35 AM, Marco Marzetti wrote: >> On Sat, Jan 14, 2017 at 9:10 PM, joel jaeggli <[email protected]> wrote: >>> On 1/14/17 3:58 AM, Marco Marzetti wrote: >>>> Joel, >>>> >>>> So you don't want your upstreams to honor RPKI just because they're >>>> 3rd parties between you and the other end? >>> >>> An ixp route-server is not a transit provider, all of the nexthops >>> exposed are in fact peers. So no I do not consider such a device an >>> "upstream" it exists to service the policy needs of the peers on the >>> fabric rather than that of the exchange operator. >>> >> >> You can easily do the same in transit providers by disabling next-hop-self. > > Nope, The router expressing nexthop self retains the available nexthops. > Under no circumstance is the router-server in the forwarding path, were > it, the route-server would be an upstream. >
That;s correct. But is the specific device really relevant? I mean: you send your traffic to another network's forwarding plane. Do you really care about the role of the devices your packets pass through? >> >>> I would expect that a ixp route server that had a state policy of >>> validating rpki would not propagate invalid routes. >>> >>>> In the context of IXPs: instead of peering with the RS you should >>>> setup direct sessions with your partners if you really want to do >>>> prefix/path validation by yourself. > > Consider the case where the invalid route masks an valid but longer path > from being advertised via the route server as the best path. in that > case the validating route-server is facilitating a prefix hijacking > which it would not have, had it discarded the route. You might argue > that this is no worse than not validating, however I think that is a > somewhat dubious point given that the rib on the route-server would show > otherwise. > I argue that the same could happen with transit and we would consider it legit. Why? >>> No, I setup bilateral peering arrangements because they actually load >>> balance to my multiple ports, because the loci of control is >>> unambiguous, because it facilitates greatly build per session prefix >>> filters, and because they converge the control and forwarding path, >>> which has a tendency to fail much more gracefully in the face of l2 >>> failures in distributed exchange fabric designs then does the route-server. >>> >> >> Aren't we saying the same thing? >> Bilateral peering brings more control over what you send and receive. > > we have a similar concurrence respecting the advantages. We appear to > differ on whether the route server offering a feature or not confers a > similar outcome. > >> I just take an additional step and say that RPKI should be part of the >> default decision process of RSs > > To confer the advantage you need to not allow invalid routes into your > best path selection processing. > Again, I really do think that the same logic of transit applies here. Regards -- Marco _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
