Hi Robert, What I don't mean to say is that deaggregation is always stupid, quite the contrary - it has its places where it can be a useful tool. You've just described one such use case, but I know of many more. Reasons why I have personally deaggregated prefixes include circumventing silly LocalPref designs of large incumbent telcos that have multiple "classes" of downstream customers, or forcefully localizing traffic in regions where AS-path length has no meaningful relation to actual physical distance traversed, and so on.
The specific case I want to document here is technical harm being done as a side effect of traffic engineering with more specific routes for commercial reasons. In certain regions of the world (e.g. not EU/NA, and generally not AP either) it's common for a sufficiently large eyeball telco to have to pick up some of their upstream transit over a submarine path, which means that the backhaul often becomes an order of more expensive than the transit service itself. Therefore, those eyeball telcos have an incentive to use as much capacity per link as possible without saturating it, as opposed to what you'd do if the upstream were just a crossconnect away e.g. simply connect as much capacity as reasonable. Of course normal internet routing doesn't work that way, a heavily peered local tier-2 operator will generally attract a lot more traffic than a restrictively peered tier-1 operator from EU/NA. But you don't want to put all your eggs in one basket either, so to consume some extra traffic on the underutilized links to justify the cost of that submarine capacity the downstream eyeball telco announces some more specific routes to the tier-1 operator which it backhauls from EU/NA - et voila, the traffic is balanced and life is good from a commercial and service availability perspective. But that's when the trouble starts from a latency technical perspective, because now locally hosted content is always forced to take the path through EU/NA since the more specific prefix is simply not available locally even though the overarching supernet might be perfectly visible without ever leaving the region in which the prefixes were originated. Anyway, TLDR: I don't want a nickname for this problem which is derogatory, because that helps nobody. Would you continue to read a guide where the first thing that happens is your being insulted? But, I do agree with Job that a non-technical nickname which illustrates the problem without insulting the party that made an honest mistake could help a lot in explaining to a management team why a certain routing policy should probably be reconsidered. Best regards, Martijn On 11/3/19 9:28 PM, Robert Raszuk wrote: Folks, Allow me to express a bit of a different view - this time from enterprise perspective. Actually announcing more specifics of the block one owns has real service advantages. So in itself it is actually a good thing ! What is bad for Internet is propagating those more specific routes beyond the point that they make any difference any longer. There was proposal to aggregate those at dynamic points where sending them no longer brings any service/routing advantages, but apparently at that time no one cared much: https://www.ietf.org/archive/id/draft-marques-idr-aggregate-00.txt - - - See assume I own /19 for a global network. I can't possibly announce that block via all of my 20 ISP peerings globally as top requirement is not to keep the Internet BGP table tiny, but rather to offer best service to customers. Further more imagine I offer various services based on geo location. For customers in Japan I want them to go to Japan DMZ and not float to any other location just because his ISP is one AS hop away from NY and two AS hops away from Osaka or Tokyo ISPs I peer with. So if I would attract such service to US I would need to carry it back to Tokyo over global WAN - disaster. See even /24 is a very coarse limit one has to deal with. I may have few gateways for a given service per site not 255. And each service has completely different service requirements from the network characteristic. If I have 8 ISPs there It is very clear (at least to some) that basic BGP best path routing is suboptimal.. For years folks have been using SLA based routing to steer packets over non necessarily BGP best path between Internet endpoints. The more fine are the announcements the better egress path selection can be achieved. So the Internet is no longer used to reach A & B. It is used to reach A & B in most optimal way for a given application. Let's therefore keep those points in mind while blindly bashing "deaggregation" and calling names those who do it :). I bet no one is doing that just for fun. Enterprises are doing it to provide the best level of service. ISPs do it to serve the needs of their customers. It is feasible to enhance BGP to aggregate when it no longer makes sense to carry more specific prefixes - let's rethink this. Thx, R. On Sun, Nov 3, 2019 at 8:41 PM Nick Hilliard <[email protected]<mailto:[email protected]>> wrote: Gert Doering wrote on 03/11/2019 19:15: > On Sun, Nov 03, 2019 at 03:10:29PM +0000, Martijn Schmidt wrote: >>> Maybe "BGP Deaggregation Slopping" as a working title? >> Or "Scenic BGP Deaggregation", or "BGP Globetrotting", or "BGP >> Castaways". If anything a connotation with the sea and/or submarine >> cables would be appropriate, I think! > > "BGP vandalism" "Noxious Routing"? Nick _______________________________________________ GROW mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/grow
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
