Re: [GROW] AS_Path prepend BCP

[Jakob Heitz (jheitz)]

What I'm trying to say here is that just saying "do not prepend" does not help.
The purpose of as-path prepending is to de-prefer a route advertised to
one AS with respect to the same route advertised to another AS.

We need to provide people with alternative methods to de-prefer
a route. For example:

To de-prefer a route at your ISP, use the communities as published
by that ISP. They will not be susceptible to preference attacks once
they leave this ISP.

To de-prefer a route further afield in the internet, as-path prepending
works in some cases, but not all. Usually 1, 2 or 3 prepends work in most
cases. Looking glasses can be used to verify if the prepends are working.

If as-prepending does not work, an alternative is to split the prefix
to the preferred path. That means to advertise multiple more-specific
prefixes that cover the range of the original prefix.

Do we want to make these recommendations?

My example illustrates one case where as-path prepending does not
work to de-prefer a route. It shows a way that large ISPs can help to
make as-path prepending work for this case.

Regards,
Jakob.

From: GROW  On Behalf Of Jakob Heitz (jheitz)
Sent: Wednesday, August 5, 2020 8:50 PM
To: grow@ietf.org
Subject: Re: [GROW] AS_Path prepend BCP

Consider a common problem

[An Ink Drawing]
Tier1-B sets local-preference for its customer to 120
and for its peer to 100.


How does Customer cause Tier1-B to prefer the path:
Content -> Tier1-B -> Tier1-A -> Regular-Provider -> Customer
instead of its default path:
Content -> Tier1-B -> Backup-Provider -> Customer
?

Solution 1
--
Customer advertises split prefixes to Regular-Provider.
Eg., 10.0.2.0/24 and 10.0.3/24 rather than 10.0.2/23.
This works, but causes bigger FIBs for everybody.

Solution 2
--
Customer advertises its routes with communities published by
Tier1-B to lower its local-preference to Backup-Provider.
This requires Backup-Provider to pass communities through
and for Customer to know what Backup-Provider's upstreams are.
It is operationally cumbersome.

Solution 3
--
Tier1-B implements a route-policy like:
if as-path length ge 15 then
  set local-preference 80
endif
Then Customer can add lots of AS prepends that will actually work!!

Regards,
Jakob.

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

Re: [GROW] AS_Path prepend BCP

[Robert Raszuk]

Hi Jakob,

The situation in reality is much more complex then your illustration.

Imagine that in your picture what you call "content" is coming from all
over the world and not one network location. And all of that is coming to
same  /24.

Imagine customer already advertises few /24s (some with short some with
long AS-PATH) so at this point IMHO solution 1 is very good and till we
have a better one becomes IMO best one.

The fact that for backup he will instead of /24s with long AS-PATH
advertise /22 will not make any one's FIB bigger ...

Best,
R.

PS. Of course if someone advertises /22 and we ask to advertise in addition
to this /24s that would be growing RIBs and FIBs everywhere. But that is
not the current situation in many networks.


On Thu, Aug 6, 2020 at 5:50 AM Jakob Heitz (jheitz)  wrote:

> Consider a common problem
>
>
>
> [image: An Ink Drawing]
>
> Tier1-B sets local-preference for its customer to 120
>
> and for its peer to 100.
>
>
>
>
>
> How does Customer cause Tier1-B to prefer the path:
>
> Content -> Tier1-B -> Tier1-A -> Regular-Provider -> Customer
>
> instead of its default path:
>
> Content -> Tier1-B -> Backup-Provider -> Customer
>
> ?
>
>
>
> Solution 1
>
> --
>
> Customer advertises split prefixes to Regular-Provider.
>
> Eg., 10.0.2.0/24 and 10.0.3/24 rather than 10.0.2/23.
>
> This works, but causes bigger FIBs for everybody.
>
>
>
> Solution 2
>
> --
>
> Customer advertises its routes with communities published by
>
> Tier1-B to lower its local-preference to Backup-Provider.
>
> This requires Backup-Provider to pass communities through
>
> and for Customer to know what Backup-Provider's upstreams are.
>
> It is operationally cumbersome.
>
>
>
> Solution 3
>
> --
>
> Tier1-B implements a route-policy like:
>
> if as-path length ge 15 then
>
>   set local-preference 80
>
> endif
>
> Then Customer can add lots of AS prepends that will actually work!!
>
>
>
> Regards,
>
> Jakob.
>
>
> ___
> 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

Re: [GROW] AS_Path prepend BCP

[Robert Raszuk]

Thank you Greg,

I think that clarifies it very well. And I actually fully agree with all
you just said below.

Kind regards,
R.

On Thu, Aug 6, 2020 at 3:46 AM Greg Skinner  wrote:

> Hi Robert,
>
> On Aug 2, 2020, at 3:22 AM, Robert Raszuk  wrote:
>
> Hi Greg,
>
>
>> > Have anyone tried to document that instead of doing AS-PATH prepend
>> across set of upstreams (for whatever valid reason that may be) the
>> preferred entrance should advertise the paths with IGP or EGP origin while
>> the other ASBRs (which would otherwise prepend N times) with INCOMPLETE ?
>> BGP best path should automatically across most implementations do the right
>> path selection.
>>
>> Offhand, I don’t know of anyone who has tried to document this.  But why
>> EGP origin?  EGP is a Historic protocol that is rarely if ever used.  IMO,
>> although this technique could work, it is misleading.
>>
>
> I thought it is not used too but looking at the BGP table it is there:
>
> cto-asr1x-ny1#sh ip bgp detail | count .*EGP.*external, best.*
> Number of lines which match regexp = 826
>
> cto-asr1x-ny1#sh ip bgp detail |  count .*EGP.*
> Number of lines which match regexp = 2345
>
>
> Actually, I meant that EGP protocol speakers (implemented according to RFC
> 904 ) are rarely if ever used
> anymore.  I’m sorry if I was unclear.
>
> Then looking at some vendor's docs I see that they apply it if the
> advertised route was learned via different ASN (many folks run more then
> one AS globally)  bit of surprise as RFC4271 never mentioned such use case.
>
> origin egp—(Optional) BGP origin attribute that indicates that the path
> information originated in another AS.
>
> So one could argue that it is misleading already today :)
>
>
> Agreed.
>
> > If not maybe we should think about a new attribute along the lines of
>> cost community to be more widely used in a transitive manner and to have
>> single meaning to allow to deprefer a prefix originated by given AS across
>> number of ISP uplinks with a numeric value (just like MED or Local Pref are
>> used locally).
>>
>> IMO, this is a better idea.
>
>
> Well sure, but you know the time we take to define it, the time vendors
> take to implement it, the time it takes to deploy it then the time it takes
> for folks to actually start using it we are talking years ...
>
> Sure if we never start we will never get there but in the mean
> time perhaps we could use what's deployed everywhere to trim size of
> AS-PATHs yet get all the benefits of AS-PATH prepends ?
>
>
> Perhaps a better way for me to express my concern is (ideally), any
> mention of "origin egp" in future RFCs should not recommend its use unless
> the Historic EGP protocol is used.  I hope that is more clear.  That would
> at least be consistent with the original, intended use of “origin egp”.
>
> Clearly I am here just trying to probe the WG list on three questions ...
>
> Is it worth to try it - ie. do we have a problem,
> Is this a good idea - ie. do we break anything,
> Should this option be added to draft-mcbride-grow-as-path-prepend as
> something to consider instead of doing N times AS-PATH prepend (often N > 5
> or N> 10 )
>
> See at the end of the day the best thing about this is that anyone can try
> to advertise his paths with different origin even today and it should just
> work - without anyone else doing anything configuration wise in the
> upstream ASNs.
>
> Thx,
> R.
>
>
> I’m thinking along the lines that (excessive) prepending is used because
> there isn’t an alternative that more clearly expresses the intent of the
> operator.  If specifying a new attribute would facilitate that, I would be
> in favor of it.
>
> Regards, Greg
>
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow