Dear Francois, On Thu, May 17, 2018 at 10:14:19AM +0000, Francois Devienne wrote:
The examples you mention confirm the issues are mainly due to poorly configured networks where routes are leaked out although they shouldn’t be. Adequate routers are able to filter out prefixes based on attributes like communities, which we set by default.
Question: is your implementation setting NO_EXPORT by default, or some other communities? Not all BGP "Optimizers" set NO_EXPORT by default... in that context I am not sure it is fair to say "the network is poorly configured" - when an "optimizer" doesn't set NO_EXPORT it is the "optimizer" that is comes with poor defaults. And there is another challenge: NO_EXPORT does not always work correctly. Software defects happen, and are unpredictable. All major routing platforms have seen bugs where for one reason or another NO_EXPORT does not (or no longer) work correctly. Heavy reliance on NO_EXPORT can be a weakness in network architecture.
There actually is a reason for operating BGP optimizers. The BGP protocol, while robust and scalable, doesn't know anything about link capacity, doesn’t apply performance analytics and can easily drive links into saturation, introducing packet loss. Also, it is not aware of commercial agreements like CDR, generating costs that could be prevented. It also, of course, ignores the performance of available paths. All of the above actually impacts customer traffic and business performance. Since a few years we see our Customers take more care of quality and capacity management… and stop relying on BGP « blindly ».
You are correct that there is a need (and a market) for BGP optimizers. BGP is terrible for routing around problematic parts of the topology if we look at metrics such as latency or packetloss. In my opinion, what the "optimizer" vendors _should_ have done (years ago), is go to IETF to the IDR working group and help standardize a safe and robust way to extend the BGP protocol to allow for better traffic engineering. Think along the lines what flowspec is for firewalls, perhaps there should be a "traffic engineering spec (tespec)" for routers. This should happen in a different Subsequent AFI to avoid the extremely risky behaviour we now see in the Unicast SAFI. I have no problem with software that automatically interacts with routers to manipulate LOCALPREF, there is no issue if software supresses more-specifics, prepends of the own ASN is no issue either, but what _is_ an issue is any software that generates fake routes and distributes those fake routes in the IPv4/IPv6 Unicast AFI/SAFI on boxes connected to the BGP DFZ. To phrase and summarize the isuse, using the terminology you provided: The "optimized" paths MUST NEVER be distributed in the same AFI/SAFI as the "natural" paths. Overloading the "natural" AFI/SAFI with fake generated more-specifics, which only exist for the purpose of outbound traffic engineering (even with communities) is a very dangerous thing. Yes, this will be a bit of work, but that is the cost of doing business.
(I’m a product engineer at Border 6 - Expereo, a BGP optimization software company.)
I appreciate your outreach in this public forum and the disclosure. Kind regards, Job