Re: [GROW] BGP deaggregation

[Brian Dickson]

On Mon, Nov 4, 2019 at 6:43 AM Christopher Morrow <
christopher.mor...@gmail.com> wrote:

> Where does it no longer make sense to deaggregate? Isn't that a bunch
> related to what problem the initial announcement is trying to solve?
>
>
I just realized this question might not have had an answer, or not the
following answer at least:

Deaggregates should only go "upstream", to transit providers (and their
transit providers).

It might be possible to apply restrictions to achieve this goal, using
mechanisms made available when the "route leaks mitigation" draft gets
adopted (and deployed).

I believe it should be possible to tag the deaggregates differently than
the aggregate itself, to differentially propagate/filter them (and prevent
the deaggregates from going to peers or customers).

Or, it might be something that requires an additional community, maybe add
to the mitigation draft once adopted.

Brian (co-author on the mitigations draft)
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP deaggregation

[Alvaro Retana]

Hi!

Russ evolved the draft with a couple of different names and co-authors.
The last version was this:

https://datatracker.ietf.org/doc/draft-white-grow-overlapping-routes/

…which we presented at grow a couple of years ago.

Alvaro.

On November 20, 2019 at 2:36:23 AM, Jakob Heitz (jheitz) (jhe...@cisco.com)
wrote:

What happened to the original draft?
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP deaggregation

[Jakob Heitz (jheitz)]

What happened to the original draft?

I can think of a high CPU risk in implementation if a covering
route covers thousands of specifics and goes away. Not to
mention the traffic loss as the specifics get readvertised.

Regards,
Jakob.

From: GROW  On Behalf Of Alejandro Acosta
Sent: Monday, November 4, 2019 6:56 PM
To: grow@ietf.org
Subject: Re: [GROW] BGP deaggregation


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 
mailto:n...@foobar.org>> wrote:
Gert Doering wrote on 03/11/2019 19:15:
> On Sun, Nov 03, 2019 at 03:10:29PM +, 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
https://www.ietf.org/mailman/listinfo/grow



___

GROW mailing list

GROW@ietf.org

https://www.ietf.org/mailman/listinfo/grow
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow