nanog mailing list archives

Re: Performance metrics used in commercial BGP route optimizers


From: Mike Hammett <nanog () ics-il net>
Date: Tue, 16 Jul 2019 13:24:11 -0500 (CDT)

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 () instituut net> 
To: "Mike Hammett" <nanog () ics-il net> 
Cc: "Töma Gavrichenkov" <ximaera () gmail com>, "NANOG" <nanog () 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 () 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 

Current thread: