Cisco and Juniper both have working ORR implementations, although config on the Juniper one is a bit clunky right now. One interesting thing is they also allow feeding topology data via BGP-LS, so BGP is the only protocol you need to run to/from it. Phil -----Original Message----- From: NANOG <nanog-bounces@nanog.org> on behalf of Brandon Ewing <nicotine@warningg.com> Date: Friday, January 13, 2017 at 17:39 To: Justin Krejci <JKrejci@usinternet.com> Cc: <nanog@nanog.org> Subject: Re: BGP Route Reflector - Route Server, Router, etc On Thu, Jan 12, 2017 at 08:32:44PM +0000, Justin Krejci wrote: > What are the pros and cons of one design over another? On list or private off list replies would be great; I'd welcome real world experiences (especially any big gotchas or caveats people learned the hard way) as well as just links to previous discussions, PDFs, slideshows, etc. Heck even a good book suggestion that covers this topic would be appreciated. > One important thing to remember when migrating from full mesh to a RR design is that you are reducing information available to the routers in the ASN. When you had a full mesh, each router could select the best path from all available paths, according to its position in the IGP. In a RR environment, by default, routers only have available to them the best routes from the RR's position in the IGP, which can lead to suboptimal exits being selected. Work is being done to allow RRs to compute metrics from the client's position in the IGP: See https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-13 for more information -- Brandon Ewing (nicotine@warningg.com)