well-known Anycast prefixes

Thu Mar 21 16:30:04 UTC 2019

On Thu, Mar 21, 2019 at 06:59:18PM +0300, Frank Habicht wrote:
> On 20/03/2019 21:05, James Shank wrote:
> > I'm not clear on the use cases, though.  What are the imagined use cases?
> > 
> > It might make sense to solve 'a method to request hot potato routing'
> > as a separate problem.  (Along the lines of Damian's point.)
> 
> my personal reason/motivation is this:
> Years ago I noticed that my traffic to the "I" DNS root server was
> traversing 4 continents. That's from Tanzania, East Africa.
> Not having a local instance (back then), we naturally sent the traffic
> to an upstream. That upstream happens to be in that club of those who
> don't have transit providers (which probably doesn't really matter, but
> means a "global" network).

Luckily there are other root servers too! :)

> My Theory :
> So just because one I-root instance was hosted at a customer (or
> customer's customer), that got higher local-pref and now packets take
> the long way from Africa via Europe, NorthAmerica to Asia and that
> customer in Thailand. While closer I-root instances would obviously be
> along the way, just not from a paying customer, "only" from peering.
> 
> I don't know whether or not to blame that "carrier" for intentionally(?)
> carrying the traffic that far - presumably the $ they got for that from
> the I-root host in Thailand was worth it, and not enough customers
> complained enough about the latency?
> 
> But I think it would be worthwhile to give them an option and produce a
> mechanism of knowing what's anycasted.
> 
> Maybe (thinking of it) a solution for really well-known prefixes
> available at many instances/locations (like DNS root) would be to have
> their fixed set of direct transits at all the "global" nodes and
> everywhere else to tell peers to not advertise this to upstreams.

In all instances of what you mention you need cooperation from the
network which is routing in a (from your perspective) suboptimal way.

Either the customer of that upstream should use BGP communities to
localize the announcement, or the upstream themselves need to change
their routing policy to set 'same LOCAL_PREF everywhere' for some
prefixes. Of course any input channel into routing policy can be a
vector of abuse.

Even if you equalize the LOCAL_PREF attribute across your network edge,
you still have other tie breakers such as AS_PATH length. It is not
clear to me how a list of well-known anycast addresses, in practise,
would help swing the pendulum. In all cases you need cooperation from a
lot of networks, and the outcome is not clearly defined because we don't
have a true inter-domain 'shortest latency path' metric.

Kind regards,

Job