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

[Matthias Waehlisch <[e-mail]>]

On Sat, 14 Jan 2017, Nick Hilliard wrote:

> Matthias Waehlisch wrote:
> >   I think there are two cases: (1) RS client peers only with route 
> > server, (2) RS client peers additionally with other BGP speakers that 
> > don't peer with the RS.
> > 
> >   In case (1) (and assuming that the RS selects the best path on behalf 
> > of the client), the IXP provisioning system needs to provide all knobs 
> > to implement potential policies -- as you mentioned below. Should be s 
> > side note.
> > 
> >   In case (2), route-server-rpki-light would be still helpful.
> 
> Case (1) is not an ietf problem.
> 
> Case (2) is already documented in
> draft-ietf-sidr-origin-validation-signaling, which proposes a generic
> BGP signaling mechanism, i.e. nothing particularly to do with route
> servers.  In fact, if the -sidr- draft progresses, it should probably be
> mentioned somewhere that the proposed mechanism is likely to cause
> unexpected behaviour on route servers unless add-path tx is enabled on
> the route server.
> 
  the current discussion makes clear that documentation of 
origin-validation-signaling in IXP context is needed, either in 
sidr-origin-validation-signaling or in a separate document such as 
route-server-rpki-light. Personally, I tend to a separate doc 
(informational or best practice).



Cheers
  matthias

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