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 _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
