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

[Matthias Waehlisch <[e-mail]>]

I don't know if we are losing sight. The argument that RS is doing best 
path selection was stated several times.

However, I still don't buy the argument "route servers and rpki are an 
uncomfortable fit."

I buy the argument that fine-grained policy configuration challenges RS 
operation. And for sure the principle is indepdent of RPKI. In the most 
boring case, the decision results in "Prefer the route received from the 
lowest peer address." Ups, is this the IP address of the peering LAN, 
given by the IXP.

What is specific to RPKI is proxying of security-related meta data 
(i.e., easier deployment of new protocols via RS).

For example, in the case of policy prefer-valid-over-invalid AND there 
is no valid, RS would announce the (invalid) prefix to peer P. P also 
established private peering and receives announcement for the invalid 
prefix. Without deploying RPKI, this BGP speaker could benefit from RS 
meta data, dropping both.



Cheers
  matthias

On Sat, 14 Jan 2017, Nick Hilliard wrote:

> Matthias Waehlisch wrote:
> > the current discussion makes clear that documentation of 
> > origin-validation-signaling in IXP context is needed
> 
> rpki is conceptually no different to any other type of signaling
> mechanism: it's simply another input into the BGP decision engine
> process, just like communities or meds or as-path.
> 
> What we're losing sight of here is that it's the route server which
> calculates the best path for each route using the routing decision
> engine, and then sends a _single_ best path to the client. Conceptually,
> it doesn't matter whether the tie-breaker on the route server is
> communities, meds, as-path or rpki: the point is that the policy
> decision mechanism needs to be configured on the route server itself,
> because the route server is the device which is calculating the best
> path.  If the route server operator doesn't do this, the clients will
> end up with path hiding (see 2.3.1 in rfc7947).  I.e. it's nothing
> specific to rpki.
> 
> This is already extensively documented in rfc7947 and rfc7948.
> 
> Nick
> 


-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Computer Science
.. http://www.cs.fu-berlin.de/~waehl