Subject: Re: [GROW] AS_Path prepend BCP

From: Greg Skinner <[email-masked]>
Date: Sat, 1 Aug 2020 22:53:28 -0700

Comments inline

> On Jul 26, 2020, at 12:50 PM, Robert Raszuk <[email-masked]> wrote:
> 
> All,
> 
> Happy to see this draft ! Have been struggling with explaining some of those issues and lack of such BCPs was sort of implicit prove that it is all fine to prepend at will. 
> 
> Said this it seems clear that putting aside cases of unnecessary use or use by errors AS-PATH prepends we are still facing no Internet wide path de-prefernecing in BGP being commonly used other then mangling AS-PATH. 
> 
> The point is that multihoming is common and if someone needs at least to try to influence entrance to his domain AS-PATH prepend comes as low hanging fruit. 
> 
> Longer prefix will not work when on both ASBRs a /24 is injected.. 
> 
> So let me ask a question here ... 
> 
> 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.

> Anyone see any issue with that ? If that works we could actually start to strongly discourage use of AS-PATH prepending. 
> 
> 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.

> Another question the draft talks about AS-PATH prepends by actual sources ... well suffice to just take a look at Internet tables in few places to see that even some transit operators prepend themselves to the original paths (also already prepended). And yes I do have captures of those. 
> 
> Thx,
> R.

Regards, Greg

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 2 Aug 2020 12:22:22 +0200

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

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 :)

> 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).
>

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 ?

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.

---

From: Michael Still <[email-masked]>
Date: Mon, 3 Aug 2020 10:41:54 -0400

On Sun, Aug 2, 2020 at 6:22 AM Robert Raszuk <[email-masked]> wrote:
> 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.
>
> 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 ?
>
> Clearly I am here just trying to probe the WG list on three questions ....
>
> 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 would not want to use Origin for anything new or out of scope of its
original intention as it's usually overwritten by intermediaries
anyway. My usual recommendation was to set Origin on all EBGP sessions
that were not customers (peering/transit) to E to flatten them out as
some transit networks appear to modify this value in order to attract
more traffic through them.

Something I would ask is what problem exactly is being solved with
prepending and can we attempt to solve this in another fashion, either
with best practices guidance or with a new protocol spec that covers
the use case. Here the problem seems to be not very well defined
because I believe there are multiple use cases for various levels of
prepending. For example one case is to attempt to utilize one path
exclusively and another solely as a backup. Another might be a signal
to indicate that one path may have a different amount of capacity than
another where the lower capacity link still takes traffic. Do we need
to further define these use cases and work to identify clear solutions
for each as part of this WG? Actually solving these problems might be
cart before horse but something to consider is that some things are
immutable in flight and others are not and perhaps an immutable and
authenticated solution would be preferable on today's Internet.

> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

--
[[email-masked] ~]$ cat .signature
cat: .signature: No such file or directory
[[email-masked] ~]$ cat all-opinions-are-my-own
All opinions are my own and do not represent any of my employer.

---

From: Greg Skinner <[email-masked]>
Date: Tue, 4 Aug 2020 15:36:18 -0700

> On Jul 26, 2020, at 12:28 PM, David Farmer <[email-masked]> wrote:
> 
> 
> 
> On Sun, Jul 26, 2020 at 2:10 PM Randy Bush <[email-masked] <mailto:[email-masked]>> wrote:
>  
> no need to attribute nationality to bad practice examples 
> Also, there is no need to attribute the bad examples to anyone, anonymize the bad examples using documentation prefixes and documentation ASNs. We all have made mistakes, I know I wouldn't want mine memorialized forever in an RFC.

OK, fair enough.  But I’m concerned that if there are no references to examples (good or bad), a reader who has little or no experience with this issue will have no basis to compare the different types of prepending.

I’d like to see the approach taken in RFC 7908 <https://tools.ietf.org/html/rfc7908> used here also.  There were several incidents of route leaks cited, but route leaks were also classified according to types identified in the incidents.

Out of curiosity, were people unhappy that 7908 called attention to the organizations involved in the route leak incidents?  Also, arguably, the mistakes called attention to in the AS_Path prepend draft have been “memorialized” because they can be accessed through the Datatracker (provided one knows how to use its history features).

Regards, Greg

---

From: john heasley <[email-masked]>
Date: Tue, 4 Aug 2020 23:08:30 +0000

> Out of curiosity, were people unhappy that 7908 called attention to the organizations involved in the route leak incidents?  Also, arguably, the mistakes called attention to in the AS_Path prepend…

I'm not; be specific.  Allow others to easily find the data for their
own research or verification of conclusions.  Is there value in hiding
our errors?

---

From: Randy Bush <[email-masked]>
Date: Tue, 04 Aug 2020 17:35:26 -0700

> Also, there is no need to attribute the bad examples to anyone,
> anonymize the bad examples using documentation prefixes and
> documentation ASNs. We all have made mistakes, I know I wouldn't want
> mine memorialized forever in an RFC.

7007 :)

---

From: Greg Skinner <[email-masked]>
Date: Wed, 5 Aug 2020 18:46:16 -0700

Hi Robert,

> On Aug 2, 2020, at 3:22 AM, Robert Raszuk <[email-masked]> wrote:
> 
> Hi Greg,
>  

Actually, I meant that EGP protocol speakers (implemented according to RFC 904 <https://www.rfc-editor.org/rfc/rfc904.html>) are rarely if ever used anymore.  I’m sorry if I was unclear.

> So one could argue that it is misleading already today :)

Agreed.

> 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”.

> 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 confi…

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

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 6 Aug 2020 03:49:32 +0000

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.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 6 Aug 2020 10:51:03 +0200

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 <[email-masked]> wrote:

> Actually, I meant that EGP protocol speakers (implemented according to RFC
> 904 <https://www.rfc-editor.org/rfc/rfc904.html>) are rarely if ever used
> anymore.  I’m sorry if I was unclear.
>
> 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”.
>
> 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
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 6 Aug 2020 11:01:53 +0200

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.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 6 Aug 2020 19:30:02 +0000

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 <[email-masked]> On Behalf Of Jakob Heitz (jheitz)
Sent: Wednesday, August 5, 2020 8:50 PM
To: [email-masked]
Subject: Re: [GROW] AS_Path prepend BCP

[An Ink Drawing]

Solution 1
--------------

Solution 2
--------------

Solution 3
--------------

Regards,
Jakob.