Re: [GROW] AS_Path prepend BCP

[Hongwei Li <[e-mail]>]

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 <martijnschmidt=
[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/grow
>