| Internet-Draft | Anycastcomm | July 2022 |
| Wilhelm & Kuenzler | Expires 25 January 2023 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 25 January 2023.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [RFC1997] 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 [RFC2119] 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 often choose to export their prefixes carrying anycast traffic with the well-know NO_EXPORT BGP community [RFC1997] set to control the distribution of their routes. Therefore the ANYCAST BGP community will likely often be used in conjunction with NO_EXPORT.¶
Accepting and honoring the ANYCAST community, or ignoring it, is a choice that is made by each operator. This community MAY be used in all bilateral and multilateral BGP deployment scenarios. The decision to honor or ignore the ANYCAST community is to be made according to the operator's routing policy. The community SHOULD be ignored, if it is received by a network that is not using it.¶
Internet Exchange Point (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 only advertise these prefixes to locally connected peers.¶
Networks employing iBGP Route Reflectors (RRs) [RFC4456] and wishing to leverage the ANYCAST community for traffic engineering may wish to consider BGP Optimal Route Reflection (BGP ORR) [RFC9107] and/or BGP Add-Path [RFC7911] 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.¶
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, and Warren Kumari.¶