Performance metrics used in commercial BGP route optimizers

Tue Jul 16 18:24:11 UTC 2019

All of the same tragedy can happen without BGP optimizers, and does. 

BGP optimizers only harm the global Internet when route filters don't do their job. (Un)Fortunately, many other things also harm the global Internet when route filters don't do their job. Things other than BGP optimizers harm the global Internet more frequently via the same vector (lack of proper route filters). 

A given set of bugs are unlikely to affect both Optimizer edge egress filters and upstream ingress filters. If so, the Internet as a whole has much graver things to worry about. 

----- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

----- Original Message -----

From: "Job Snijders" <job at instituut.net> 
To: "Mike Hammett" <nanog at ics-il.net> 
Cc: "Töma Gavrichenkov" <ximaera at gmail.com>, "NANOG" <nanog at nanog.org> 
Sent: Tuesday, July 16, 2019 12:41:13 PM 
Subject: Re: Performance metrics used in commercial BGP route optimizers 

On Tue, Jul 16, 2019 at 3:33 PM Mike Hammett < 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. 

<blockquote>

The argument against route optimizers (assuming appropriate ingress\egress filters) is a religious one and should be treated as such. 
</blockquote>

The argument against "BGP optimizers" is that we *cannot* assume appropriate ingress or egress filters. It appears to me like fallacy to suggest a line of reasoning ala "if you do things correctly, things won't go wrong". Clearly we've observed many times over that things *do* go wrong. 

Some examples: almost every year one of the major BGP vendors has a serious bug related to the functionality to NO_EXPORT in some release. Also, routinely we observe there are software defects that cause a device to behave different (read 'leak') than how the operator had explicitly configured the device. These are facts, not religious statements. 

Perhaps in a bug-free world there is room for dangerous activities, but there is no such thing as bug-free. And I haven't even covered the human error angle. We must robustly architect our networks to mitigate or dampen the negative effects of issues at all layers of the stack. 

I consider it wholly inappropriate to write-off the countless hours spend dealing with fallout from "BGP optimizers" and the significant financial damages we've sustained as "religious arguments". 

Kind regards, 

Job 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190716/a2d311da/attachment.html>