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

Re: [GROW] AS_Path prepend BCP

[Jakob Heitz (jheitz)]

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

[Greg Skinner]

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

Re: [GROW] AS_Path prepend BCP

[john heasley]

Tue, Aug 04, 2020 at 03:36:18PM -0700, Greg Skinner:
> 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).

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?

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

Re: [GROW] AS_Path prepend BCP

[Greg Skinner]

> On Jul 26, 2020, at 12:28 PM, David Farmer  wrote:
> 
> 
> 
> On Sun, Jul 26, 2020 at 2:10 PM Randy Bush  > 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 
 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


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

Re: [GROW] AS_Path prepend BCP

[Michael Still]

On Sun, Aug 2, 2020 at 6: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
>
> 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).
>>
>> 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 ?
>
> 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 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
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow



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

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

Re: [GROW] AS_Path prepend BCP

[Robert Raszuk]

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

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.
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] AS_Path prepend BCP

[Greg Skinner]

Comments inline

> On Jul 26, 2020, at 12:50 PM, Robert Raszuk  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

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

Re: [GROW] AS_Path prepend BCP

[Jakob Heitz (jheitz)]

I have worked on more than one BGP implementation, but not all of them, of 
course.
On memory requirements for as-paths:
Attribute sets are shared among stored routes.
That means if two stored routes have the same attribute sets, the attribute set 
is stored only once.
As-paths are shared among attribute sets.
That means if two stored attribute sets have the same as-path, then the as-path 
is stored only once.
Storing them in the control plane is not a big problem.

However, as-paths can be sent in netflow.
Netflow is generated in the forwarding plane.
AS-paths are not stored in expensive fast memory on the forwarding plane, but 
still,
using memory on the forwarding plane has greater impact than on the control 
plane.

An as-path consists of AS_SEQUENCEs (and other elements). An AS_SEQUENCE can 
contain
a maximum of 255 ASNs. If the as-path is longer, then multiple AS_SEQUENCEs are
required. The code to parse them and create them is not often exercised and
is a potential for bugs in fresh code. The older implementations have these bugs
well and truly shaken out of them.

Regards,
Jakob.

From: GROW  On Behalf Of Michael McBride
Sent: Sunday, July 26, 2020 11:42 AM
To: grow@ietf.org
Subject: [GROW] AS_Path prepend BCP

Hello wg,

We have submitted 
https://datatracker.ietf.org/doc/draft-mcbride-grow-as-path-prepend/ which is 
intended to be a bcp in the use of AS_Path prepend based on work of Doug 
Madory. As we state in the intro: AS_Path prepending is discussed in Use of BGP 
Large Communities [RFC8195] and this document provides additional, and 
specific, guidance to operators on how to be a good internet citizen with the 
proper use of AS_Path prepend.

We would encourage feedback on this document.

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

Re: [GROW] AS_Path prepend BCP

[Hongwei Li]

In reality, economic cost (as Martijn pointed out), easy to remember and
use, what you get is what you see, human brains like to walk shortcut, etc,
affect which attribute to use.
Prepending as_path has been demonstrated as the way most operators choose.
It will be very good that we can have best practice.
To make the best practice widely used, it had better provide alternative
practical ways for the don'ts.

BR,
Hongwei

On Mon, Jul 27, 2020 at 5:58 AM Martijn Schmidt  wrote:

> On 7/27/20 1:16 AM, Randy Bush wrote:
> >> That being said, selective more specific prefix announcements are the
> >> bane of my existence when attempting to keep traffic local in the less
> >> mainstream regions of the world. When a given network has some local
> >> transit/peer and some backhauled transit/peer to which it sends a
> >> different set of more specifics, resolving routing hairpins can become
> >> extremely time consuming since we have to convince the team running
> >> that network to adjust their routing policy - as opposed to
> >> unilaterally assigning a higher LocalPref to the announcement which
> >> may have a longer AS-path but doesn't take a scenic route through
> >> $cheap_transit/peering_region.
> > i am probably misreading, but on the surface this seems to be a routing
> > policy problem in the "local transit/peer."  perhaps a diagramatic
> > example would help.
> >
> > randy
> In certain regions of the world it's common for networks to buy all
> their transit in a foreign country, and then backhaul it to the end user
> population over a submarine cable. Some of those submarine cables are
> relatively short (in the order of 1300km to a regional interconnection
> hub) and others are relatively long (in the order of 8500km to one of
> the mainstream interconnection hubs). Usually the transit backhauled
> over the short cable is from a tier-2 network with local peerings, and
> the transit backhauled over the long cable is from a global tier-1
> network that only peers other tier-1 providers.
>
> You can guess that, all announcements being equal, the nearby tier-2
> transit will take a lot more traffic than the far away tier-1 transit.
> Because the main cost of buying transit is in the submarine cable costs
> for these networks, they will do their best to implement traffic
> engineering with the goal of maximizing utilization on all links they
> have - and that load distribution is often achieved through selective
> more specific prefix announcements, rather than prepending.
>
> This would not be a major issue if both transits were equal in terms of
> peering policy and geographical distance, but the reality is that this
> frequently results in certain prefixes only being available through a
> distant tier-1 transit no matter how much LocalPref you throw at it. And
> that's quite detrimental to the service quality when one has built a PoP
> in the regional interconnection hub at the other end of that
> aforementioned 1300km cable with the purpose of running multiplayer
> videogame services for the wider region so that there's sufficient
> playerbase to start a match at all times of the day. By the way, this
> type of traffic is real-time with reaction speeds measured in
> milliseconds - it can't be cached and served through a CDN.
>
> Best regards,
> Martijn
> ___
> 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

[Martijn Schmidt]

On 7/27/20 1:16 AM, Randy Bush wrote:
>> That being said, selective more specific prefix announcements are the
>> bane of my existence when attempting to keep traffic local in the less
>> mainstream regions of the world. When a given network has some local
>> transit/peer and some backhauled transit/peer to which it sends a
>> different set of more specifics, resolving routing hairpins can become
>> extremely time consuming since we have to convince the team running
>> that network to adjust their routing policy - as opposed to
>> unilaterally assigning a higher LocalPref to the announcement which
>> may have a longer AS-path but doesn't take a scenic route through
>> $cheap_transit/peering_region.
> i am probably misreading, but on the surface this seems to be a routing
> policy problem in the "local transit/peer."  perhaps a diagramatic
> example would help.
>
> randy
In certain regions of the world it's common for networks to buy all 
their transit in a foreign country, and then backhaul it to the end user 
population over a submarine cable. Some of those submarine cables are 
relatively short (in the order of 1300km to a regional interconnection 
hub) and others are relatively long (in the order of 8500km to one of 
the mainstream interconnection hubs). Usually the transit backhauled 
over the short cable is from a tier-2 network with local peerings, and 
the transit backhauled over the long cable is from a global tier-1 
network that only peers other tier-1 providers.

You can guess that, all announcements being equal, the nearby tier-2 
transit will take a lot more traffic than the far away tier-1 transit. 
Because the main cost of buying transit is in the submarine cable costs 
for these networks, they will do their best to implement traffic 
engineering with the goal of maximizing utilization on all links they 
have - and that load distribution is often achieved through selective 
more specific prefix announcements, rather than prepending.

This would not be a major issue if both transits were equal in terms of 
peering policy and geographical distance, but the reality is that this 
frequently results in certain prefixes only being available through a 
distant tier-1 transit no matter how much LocalPref you throw at it. And 
that's quite detrimental to the service quality when one has built a PoP 
in the regional interconnection hub at the other end of that 
aforementioned 1300km cable with the purpose of running multiplayer 
videogame services for the wider region so that there's sufficient 
playerbase to start a match at all times of the day. By the way, this 
type of traffic is real-time with reaction speeds measured in 
milliseconds - it can't be cached and served through a CDN.

Best regards,
Martijn
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] AS_Path prepend BCP

[Randy Bush]

> That being said, selective more specific prefix announcements are the
> bane of my existence when attempting to keep traffic local in the less
> mainstream regions of the world. When a given network has some local
> transit/peer and some backhauled transit/peer to which it sends a
> different set of more specifics, resolving routing hairpins can become
> extremely time consuming since we have to convince the team running
> that network to adjust their routing policy - as opposed to
> unilaterally assigning a higher LocalPref to the announcement which
> may have a longer AS-path but doesn't take a scenic route through
> $cheap_transit/peering_region.

i am probably misreading, but on the surface this seems to be a routing
policy problem in the "local transit/peer."  perhaps a diagramatic
example would help.

randy

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

Re: [GROW] AS_Path prepend BCP

[Martijn Schmidt]

I agree with most of these sentiments, especially the part about making a 
statement in the BCP that prepending is not bad in and of itself, it just has 
to be applied with care and never more than actually needed to achieve the 
intended outcome.

That being said, selective more specific prefix announcements are the bane of 
my existence when attempting to keep traffic local in the less mainstream 
regions of the world. When a given network has some local transit/peer and some 
backhauled transit/peer to which it sends a different set of more specifics, 
resolving routing hairpins can become extremely time consuming since we have to 
convince the team running that network to adjust their routing policy - as 
opposed to unilaterally assigning a higher LocalPref to the announcement which 
may have a longer AS-path but doesn't take a scenic route through 
$cheap_transit/peering_region.

So please, let's not start recommending the use of selective more specific 
prefix announcements to operators - I'd rather have the longer AS-paths. ;)

Best regards,
Martijn Schmidt


From: GROW  on behalf of Randy Bush 
Sent: 26 July 2020 21:10
To: Michael McBride 
Cc: grow@ietf.org 
Subject: Re: [GROW] AS_Path prepend BCP

nice to see something starting in this space

no need to attribute nationality to bad practice examples

too much concentration on bad examples and not enough on why each of the
recommended practices is good

neglects to mention alternative TE such as longer prefix announcement

randy

___
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

[Harvey]

Hi Mike,
I would like to join you guys to work on this.
I work for HPE Networking.
Please let me know next actions, meetings, etc.

Thanks,

Hongwei Li

> On Jul 26, 2020, at 6:38 PM, Michael McBride  
> wrote:
> 
> Thank you all for the helpful comments. We will update the draft over the 
> next few weeks and send to you for further review. If anyone cares to join us 
> as an author please let us know.
> 
> And yes Robert, perhaps we can eventually conclude that if you do prepending 
> then do X but that we discourage prepending by instead doing Y.
> 
> mike
> 
> -Original Message-
> From: Nick Hilliard  
> Sent: Sunday, July 26, 2020 1:59 PM
> To: Michael McBride 
> Cc: grow@ietf.org
> Subject: Re: [GROW] AS_Path prepend BCP
> 
> Michael McBride wrote on 26/07/2020 19:42:
>> We have submitted
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
>> tracker.ietf.org%2Fdoc%2Fdraft-mcbride-grow-as-path-prepend%2Fdat
>> a=02%7C01%7Cmichael.mcbride%40futurewei.com%7C23a5d643a0804b71ff1908d8
>> 31a6c523%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6373139396290344
>> 10sdata=IpTVh2AVylhnMb94MROGNtVMxuguov16bpXBHwdvT%2Fs%3Drese
>> rved=0 which is intended to be a bcp in the use of AS_Path prepend 
>> based on work of Doug Madory. As we state in the intro: AS_Path 
>> prepending is discussed in Use of BGP Large Communities [RFC8195] and 
>> this document provides additional, and specific, guidance to operators 
>> on how to be a good internet citizen with the proper use of AS_Path 
>> prepend.
>> 
>> We would encourage feedback on this document.
> 
> Good start - but needs work!
> 
> some suggestions:
> 
> - it would be useful to have a histogram or table of the frequency of 
> unique-aspath lengths (i.e. with all prepending flattened).  This would help 
> contextualise the best practice recommendation.
> 
> - +1 on randy's comments about de-nationalising and providing examples of why 
> recommended good practice is good practice.
> 
> - a BCP should be as relevant and fresh in 10 years time as it is today, so 
> imagine it's 2030 and you're reading the draft:  plenty of things in it need 
> to be made insensitive to time context.  E.g. 95.47.142.0/23 might be held by 
> a Guatamalan company in 10 years time, AS174 might be assigned to 
> NTTCogentCentury and AS6939 might be Hurricane Equinix.  You never know.
> 
> - it would be useful to give advice on how to measure the effectiveness of 
> prepending in terms of remote global visibility.
> 
> 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

Re: [GROW] AS_Path prepend BCP

[Michael McBride]

Thank you all for the helpful comments. We will update the draft over the next 
few weeks and send to you for further review. If anyone cares to join us as an 
author please let us know.

And yes Robert, perhaps we can eventually conclude that if you do prepending 
then do X but that we discourage prepending by instead doing Y.

mike

-Original Message-
From: Nick Hilliard  
Sent: Sunday, July 26, 2020 1:59 PM
To: Michael McBride 
Cc: grow@ietf.org
Subject: Re: [GROW] AS_Path prepend BCP

Michael McBride wrote on 26/07/2020 19:42:
> We have submitted
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-mcbride-grow-as-path-prepend%2Fdat
> a=02%7C01%7Cmichael.mcbride%40futurewei.com%7C23a5d643a0804b71ff1908d8
> 31a6c523%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6373139396290344
> 10sdata=IpTVh2AVylhnMb94MROGNtVMxuguov16bpXBHwdvT%2Fs%3Drese
> rved=0 which is intended to be a bcp in the use of AS_Path prepend 
> based on work of Doug Madory. As we state in the intro: AS_Path 
> prepending is discussed in Use of BGP Large Communities [RFC8195] and 
> this document provides additional, and specific, guidance to operators 
> on how to be a good internet citizen with the proper use of AS_Path 
> prepend.
> 
> We would encourage feedback on this document.

Good start - but needs work!

some suggestions:

- it would be useful to have a histogram or table of the frequency of 
unique-aspath lengths (i.e. with all prepending flattened).  This would help 
contextualise the best practice recommendation.

- +1 on randy's comments about de-nationalising and providing examples of why 
recommended good practice is good practice.

- a BCP should be as relevant and fresh in 10 years time as it is today, so 
imagine it's 2030 and you're reading the draft:  plenty of things in it need to 
be made insensitive to time context.  E.g. 95.47.142.0/23 might be held by a 
Guatamalan company in 10 years time, AS174 might be assigned to 
NTTCogentCentury and AS6939 might be Hurricane Equinix.  You never know.

- it would be useful to give advice on how to measure the effectiveness of 
prepending in terms of remote global visibility.

Nick

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

Re: [GROW] AS_Path prepend BCP

[Nick Hilliard]

Michael McBride wrote on 26/07/2020 19:42:
We have submitted 
https://datatracker.ietf.org/doc/draft-mcbride-grow-as-path-prepend/ 
which is intended to be a bcp in the use of AS_Path prepend based on 
work of Doug Madory. As we state in the intro: AS_Path prepending is 
discussed in Use of BGP Large Communities [RFC8195] and this document 
provides additional, and specific, guidance to operators on how to be a 
good internet citizen with the proper use of AS_Path prepend.


We would encourage feedback on this document.


Good start - but needs work!

some suggestions:

- it would be useful to have a histogram or table of the frequency of 
unique-aspath lengths (i.e. with all prepending flattened).  This would 
help contextualise the best practice recommendation.


- +1 on randy's comments about de-nationalising and providing examples 
of why recommended good practice is good practice.


- a BCP should be as relevant and fresh in 10 years time as it is today, 
so imagine it's 2030 and you're reading the draft:  plenty of things in 
it need to be made insensitive to time context.  E.g. 95.47.142.0/23 
might be held by a Guatamalan company in 10 years time, AS174 might be 
assigned to NTTCogentCentury and AS6939 might be Hurricane Equinix.  You 
never know.


- it would be useful to give advice on how to measure the effectiveness 
of prepending in terms of remote global visibility.


Nick

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

Re: [GROW] AS_Path prepend BCP

[Robert Raszuk]

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.

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

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.
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] AS_Path prepend BCP

[David Farmer]

On Sun, Jul 26, 2020 at 2:10 PM Randy Bush  wrote:

> nice to see something starting in this space
>
+1


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


> too much concentration on bad examples and not enough on why each of the
> recommended practices is good
>
> neglects to mention alternative TE such as longer prefix announcement
>
> randy
>
-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] AS_Path prepend BCP

[Randy Bush]

nice to see something starting in this space

no need to attribute nationality to bad practice examples

too much concentration on bad examples and not enough on why each of the
recommended practices is good

neglects to mention alternative TE such as longer prefix announcement

randy

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

[GROW] AS_Path prepend BCP

[Michael McBride]

Hello wg,

We have submitted 
https://datatracker.ietf.org/doc/draft-mcbride-grow-as-path-prepend/ which is 
intended to be a bcp in the use of AS_Path prepend based on work of Doug 
Madory. As we state in the intro: AS_Path prepending is discussed in Use of BGP 
Large Communities [RFC8195] and this document provides additional, and 
specific, guidance to operators on how to be a good internet citizen with the 
proper use of AS_Path prepend.

We would encourage feedback on this document.

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