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