Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

[Marco Marzetti <[e-mail]>]

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 <[e-mail]> 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