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
[email protected]
https://www.ietf.org/mailman/listinfo/grow

Reply via email to