Performance metrics used in commercial BGP route optimizers

Wed Jul 17 22:16:07 UTC 2019

You can achieve performance based routing using latency/jitter and partial blackhole detection as your metrics without resorting to prefix splitting - adjust local preferences on received routes, don’t install received routes, add static routes, change MPLS label if doing EPE etc. I see very few, if any, use cases for prefix splitting that could not be accommodated for via other mechanisms that do not leave a network in a “locked and loaded” dangerous state.

But it’s a free world and market economy (at least in the NA part of NANOG) so people will use this stuff unfortunately. But take a look at the Twitter link Job supplied earlier where a vendor confirmed they are insecure mode of operation by default. Why??? Being good corporate citizens the model should be secure by default and you can remove the safety if you know what you’re doing (ideally you couldn’t remove the safety at all, but see above comment around free market). Handing people software with the safety removed and assuming they won’t pull the trigger is reckless business conduct IMO. But at the end of the day, it’s all about the almighty dollar and if a customer can be gained where the path is resistance is less giving them an insecure product by default, typically because the customer doesn’t have the technical knowledge to understand what they’re actually doing, then so be it.

Sent from my iPhone

On Jul 17, 2019, at 2:53 PM, Jared Geiger <jared at compuwizz.net<mailto:jared at compuwizz.net>> wrote:

I was attracted to BGP route optimizers for latency/jitter reduction and partial black hole detection scenarios.  Our traffic is low enough in volume that we aren't playing the circuit commit game, but rather optimizing the path to VoIP customers who don't care that provider Y in path X-Y-Z had a fiber cut causing issues with their phone service.

They are a piece of the SDN and automation fun. Hopefully the vendors will devise ways of dealing with traffic load balancing without splitting prefixes.Or maybe RPKI will become more ubiquitous and leaks won't be as painful. Similar to how DNSSEC led many ISPs to remove their DNS redirecting "search services".

On Wed, Jul 17, 2019 at 10:02 AM Michael Still <stillwaxin at gmail.com<mailto:stillwaxin at gmail.com>> wrote:
On Wed, Jul 17, 2019 at 12:38 AM Hank Nussbacher <hank at efes.iucc.ac.il<mailto:hank at efes.iucc.ac.il>> wrote:
>
> On 16/07/2019 20:41, Job Snijders wrote:
>
> On Tue, Jul 16, 2019 at 3:33 PM Mike Hammett <nanog at ics-il.net<mailto:nanog at ics-il.net>> wrote:
>>
>> More like do whatever you want in your own house as long as you don't infringe upon others.
>
>
> That's where the rub is; when using "BGP optimisers" to influence public Internet routing, you cannot guarantee you won't infringe upon others.
>
>>
>> The argument against route optimizers (assuming appropriate ingress\egress filters) is a religious one and should be treated as such.
>
> There is a difference between BGP optimizers and route optimizers.  When was the last time you heard a complain about Akamai screwing up the global routing table over the past 12 years:
>
> https://www.akamai.com/us/en/about/news/press/2007-press/akamai-introduces-advanced-communications-protocol-for-accelerating-dynamic-applications.jsp
>
> https://developer.akamai.com/legacy/learn/Optimization/SureRoute.html
>
> -Hank
>
>

Along these same lines I'd like to point out that nearly all or
possibly even all incidents in recent memory are attributable to a
single product whereas there has been at least one other product on
the market for something like 15+ years that AFAIK has not had a
single incident associated with it (and also does not create more
specific prefixes as part of its operation). So is it really that one
product is spoiling the market for the rest here or are they all bad?

--
[stillwaxin at gmail.com<mailto:stillwaxin at gmail.com> ~]$ cat .signature
cat: .signature: No such file or directory
[stillwaxin at gmail.com<mailto:stillwaxin at gmail.com> ~]$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190717/ea01a7fd/attachment.html>