Marco Marzetti wrote: > Why RPKI can't be part of that? tl;dr: route servers and rpki are an uncomfortable fit.
rpki can be part of that, but it's problematic because the route server is running the routing decision engine on the part of the client. RPKI is a relatively fine-grained tool in the list of things that are taken into account for the best path calculation, which means that there is a genuine difficulty in providing enough fine-grained levers so that the route server can handle this in a way that works well for clients. As others have pointed out, the control mechanisms that rpki allows are much easier to handle on bilateral bgp sessions than multilateral. These problems mostly disappear if the route server and client use add-path, because that shifts the burden of handling the policy application fully to the client. Where add-path is used, there is no requirement to mark routes with communities firstly because no routing policy action has been taken by the route server and secondly because the client can check the ROA themselves. The usual caveats about add-path apply. Stepping back a bit, most organisations who use route servers are sufficiently small that they don't need anything more than highly simplistic exterior routing policies, where almost everything is handled by the default bgp decision process documented in rfc4271, and final tweaks are handled by applying a single med or localpref for all peers or all transits or whatever. This is the category of ASNs that route servers work best for. Once an organisation grows beyond a certain size, it's quite usual to move away from using route servers - and at a later stage still, to move away from using IXPs in favour of PNIs. If an organisation's routing policies are more complicated than most, then route servers are generally unsuitable anyway. RPKI will reduce that boundary of suitability, but not by much. I'd hazard a guess that if an IXP were to provide a primitive facility in their provisioning system to allow clients to specify whether they wanted rpki-invalid or rpki-notfound dropped or used in the decision engine, that would satisfy most route server client organisations' policy requirements. Obviously this is not going to work for all organisations, but adding in more fine-grained controls runs into diminishing returns very quickly indeed, as has been implicitly noted in the ixp industry by the scarcity of generally accepted policy controls outside the usual "redistribute or don't redistribute my prefixes to ASN X" community tags. If AS path validation ever happens, then this probably not work with route servers at all, but that's a different thing, outside the scope of this conversation. Nick _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow