Subject: [GROW] AS_Path prepend BCP

From: Michael McBride <[email-masked]>
Date: Sun, 26 Jul 2020 18:42:24 +0000

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

---

From: Randy Bush <[email-masked]>
Date: Sun, 26 Jul 2020 12:10:39 -0700

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

---

From: David Farmer <[email-masked]>
Date: Sun, 26 Jul 2020 14:28:29 -0500

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

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 26 Jul 2020 21:50:02 +0200

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.

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 26 Jul 2020 21:59:16 +0100

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

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

---

From: Michael McBride <[email-masked]>
Date: Sun, 26 Jul 2020 22:38:51 +0000

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 <[email-masked]> 
Sent: Sunday, July 26, 2020 1:59 PM
To: Michael McBride <[email-masked]>
Cc: [email-masked]
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%2F&amp;dat
> a=02%7C01%7Cmichael.mcbride%40futurewei.com%7C23a5d643a0804b71ff1908d8
> 31a6c523%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6373139396290344
> 10&amp;sdata=IpTVh2AVylhnMb94MROGNtVMxuguov16bpXBHwdvT%2Fs%3D&amp;rese
> 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.
> 

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

---

From: Harvey <[email-masked]>
Date: Sun, 26 Jul 2020 19:00:13 -0400

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 <[email-masked]> wrote:
> 
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

---

From: Martijn Schmidt <[email-masked]>
Date: Sun, 26 Jul 2020 23:10:19 +0000

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 <[email-masked]> on behalf of Randy Bush <[email-masked]>
Sent: 26 July 2020 21:10
To: Michael McBride <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [GROW] AS_Path prepend BCP

randy

---

From: Randy Bush <[email-masked]>
Date: Sun, 26 Jul 2020 16:16:14 -0700

> 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

---

From: Martijn Schmidt <[email-masked]>
Date: Mon, 27 Jul 2020 09:58:08 +0000

> policy problem in the "local transit/peer."  perhaps a diagramatic
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

---

From: Hongwei Li <[email-masked]>
Date: Mon, 27 Jul 2020 11:41:58 -0400

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

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 27 Jul 2020 20:33:54 +0000

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 <[email-masked]> On Behalf Of Michael McBride
Sent: Sunday, July 26, 2020 11:42 AM
To: [email-masked]
Subject: [GROW] AS_Path prepend BCP

Hello wg,

thanks,
mike