Hello Robert, I really like the way you describe the situation. And this one is a very important phrase:
"What is bad for Internet is propagating those more specific routes beyond the point that they make any difference any longer. " I recognize that your draft if more complicated than what I expected (sorry, my fault), but anyhow at the beginning I though: "this is so true: after the AS_PATH reaches length X or more, then it does not look necessary to propagate more specific routes". I might be wrong but I can not think in any single situation. Hope your draft move forward. Alejandro, On 11/3/19 2: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 <n...@foobar.org > <mailto:n...@foobar.org>> 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 > GROW@ietf.org <mailto:GROW@ietf.org> > https://www.ietf.org/mailman/listinfo/grow > > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow
pEpkey.asc
Description: application/pgp-keys
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
