Nick, You know the IXPs's world better then me so i take your analysis as valid.
But there's something that i would like to point out. The concept of IXP has changed and we cannot longer consider them as simple LANs run on top of a bunch of switches. Of course there are small entities that fit into the original definition, but there are also *very* large networks that move your packets between distant locations over MPLS. And that's much like what transit networks do. So i can't understand why we should not encourage (in a very strong way) RSs to run RPKI. That doesn't mean the RS MUST drop the prefixes: They should lower the LOCAL_PREF and as Joel has suggested add a prepend (or 2 or 3). Regards On Sat, Jan 14, 2017 at 4:06 PM, Nick Hilliard <[email protected]> wrote: > 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 -- Marco _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
