A well-known BGP community to denote prefixes used for Anycast
Cloudflare
Germany
+49 176 62 05 94 27
max@sdn.clinic
Init7 (Switzerland) Ltd.
Technoparkstrasse 5
8406
Winterthur
Switzerland
kuenzler@init7.net
Global Routing Operations
Anycast
BGP
BGP Community
Routing
Traffic Engineering
In theory routing decisions on the Internet and by extension within ISP networks
should always use hot-potato routing to reach any given destination. In reality
operators sometimes choose to not use the hot-potato paths to forward traffic due
to a variety of reasons, mostly motivated by traffic engineering considerations.
For prefixes carrying anycast traffic in virtually all situations it is advisable
to stick to the hot-potato principle. As operators mostly don't know which prefixes
are carrying unicast or anycast traffic, they can't differentiate between them in
their routing policies.
To allow operators to take well informed decisions on which prefixes are carrying
anycast traffic this document proposes a well-known BGP community to denote this property.
The Internet routing system ecosystem has become more and more complex,
and the amount of operators using anycast to announce their services to
the default free zone is significant. Especially for networks operating
internationally, or even across multiple continents, traffic engineering
can be challenging.
In such circumstances it might be preferential to diverge from the
hot-potato principle and not egress traffic from the own AS as fast as possible.
For example operators may choose to backhaul traffic to remote locations within
the own network to be in control of longer parts of the path.
For unicast traffic this is not much of an issue as this will take "just another
path" to the same location, although it may have an impact on the overall latency.
For anycast traffic however this will usually have a much bigger impact
as it most likely will cause the traffic to hit a different location serving
the requests, leading to non-optimal latency and user experience. In case of
anycasted DNS services which are used as part of a load balancing strategy of
a service provider this will most certainly lead to mapping user requests to
a location further away from the users, again leading to non-optimal user
experience.
Service providers could choose to tag their prefixes, with a community
of their choosing, to indicate that a certain prefix is used for anycast,
so operators could take well informed decisions on what kind of traffic
engineering to apply to which prefixes and where to stick to hot-potato
routing.
However, having several different communities for different networks
would make it unnecessarily complex, cumbersome, and error-prone. This
document therefore defines a well-known BGP community
to reduce operational complexities.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to
be interpreted as described in
only when they appear in all upper case. They may also appear in lower
case or mixed case as English words, without normative meaning.
This document defines the use of a new well-known BGP community, ANYCAST.
The semantics of this community allow a network to interpret the
presence of this community as an advisory qualification to always apply
hot-potato routing policies for traffic being sent towards this prefix.
A prefix is considered carrying anycast traffic if the prefix is shared
by devices (generally servers) in multiple locations and is announced in two
or more distinct locations in the topology.
Service providers announcing anycast prefixes SHOULD either announce
their prefixes tagged with the ANYCAST community from all their locations
or at no location at all.
Operators of anycast services might choose to export their prefixes
carrying anycast traffic with the well-known NO_EXPORT BGP community
set to control the distribution of their routes. Therefore the ANYCAST BGP
community might be used in conjunction with NO_EXPORT.
Each network may choose to act on the ANYCAST community, if present,
or ignore it entirely, according to the operator's routing policy. If
an operator chooses to act on this community, they SHOULD consider the
security considerations below before implementing traffic engineering
based on it.
This community MAY be used in all bilateral and multilateral BGP deployment
scenarios.
The community SHOULD be ignored, if it is received by a network that is
not acting on it and SHOULD always be preserved when announcing prefix
to peers.
Networks may be connected to Internet Exchange Points (IXP) from
remote locations. Such remote peerings are generally undesirable for
Anycast routing, which tries to route to the nearest target. If the
information if a peer is connected locally or remotely is available,
then the routing for prefixes with the ANYCAST community can be improved
by preferring ANYCAST prefixes from locally connected peers.
IXP operators providing Route Servers (RS) MAY introduce the possibility
to filter out ANYCAST prefixes which are connected to a remote location,
so connected parties have full control over their routing decisions.
This could for example be accomplished by providing a BGP community
indicating that a peer is connected locally or remotely to the IXP so
the peers could filter routes based on this information, or for a
connected party to tag prefixes announced to the IXP Route Server with
a BGP community asking the IXP RS to, for example, only advertise
ANYCAST prefixes to locally connected peers.
Networks employing iBGP Route Reflectors (RRs) and
wishing to leverage the ANYCAST community for traffic engineering may wish to
consider BGP Optimal Route Reflection (BGP ORR) and/or
BGP Add-Path to propagate the optimum paths inside
their network
Without an explicit configuration directive set by the operator,
network elements SHOULD NOT apply any special handling on prefixes
that are tagged with the ANYCAST community. The operator is expected
to explicitly configure the network element to honor the ANYCAST community
in a way that is compliant with the operator's routing policy.
Vendors MAY provide a shorthand keyword in their configuration
language to reference the well-known ANYCAST community attribute
value. The suggested string to be used is "ANYCAST".
IANA is asked to register ANYCAST in the "BGP Well-known Communities"
registry.
ANYCAST (= TBD)
Due to the very nature of anycast, prefixes will be announced from different
places on the Internet and an interested party will likely be able to figure out
a prefix is being anycast by digging through different looking glasses or route
views. Therefore explicitly denoting that a prefix is used for anycast can not
be considered an information disclosure.
The same is true for prefixes of the same origin ASN which are not marked as
being used for anycast and therefore are most likely to be considered regular
unicast prefixes.
Networks might willfully tag non-anycast prefixes with the ANYCAST community
in the hope to influence routing decisions of these prefixes in other networks.
Operators should therefore consider the potential impact on their traffic
engineering when creating routing policies.
Possible approaches are, including but not limited to, only acting on prefixes
tagged with the ANYCAST community from trusted peers, ASes, or AS paths with a
certain maximum length, and only increasing local-pref after careful consideration.
Key words for use in RFCs to Indicate Requirement Levels
BGP Communities Attribute
BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)
Advertisement of Multiple Paths in BGP
BGP Optimal Route Reflection (BGP ORR)
The authors would like to gratefully acknowledge many people who have
contributed discussions and ideas to the development of this
document. They include Oliver Geiselhardt-Herms, Remco van Mook,
Job Snijders, Stefan Wahl, Andrew Alston, Martin Pels, Jerome Fleury,
Lucas Pardue, Robert Raszuk, Randy Bush, Jeffrey Haas, Warren Kumari,
Florian Streibelt, Klaus Darillion, and Michael Still.