Global Routing Operations M. Wilhelm
Internet-Draft Cloudflare
Intended status: Informational F. Kuenzler
Expires: 6 January 2023 Init7
5 July 2022
A well-known BGP community to denote prefixes used for Anycast
draft-wilhelm-grow-anycast-community-00
Abstract
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.
Status of This Memo
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 6 January 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wilhelm & Kuenzler Expires 6 January 2023 [Page 1]
Internet-Draft Anycastcomm July 2022
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. The ANYCAST Community . . . . . . . . . . . . . . . . . . . . 3
2.1. Use Together With NO_EXPORT Community . . . . . . . . . . 3
3. Operational Recommendations . . . . . . . . . . . . . . . . . 3
3.1. Network advertising anycast prefixes . . . . . . . . . . 3
3.2. Network receiving prefixes with ANYCAST community . . . . 4
3.3. ANYCAST community and IXP Route Servers . . . . . . . . . 4
4. Vendor Implementation Recommendations . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
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
Wilhelm & Kuenzler Expires 6 January 2023 [Page 2]
Internet-Draft Anycastcomm July 2022
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.
1.1. Requirements Language
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.
2. The ANYCAST Community
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.
2.1. Use Together With NO_EXPORT Community
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.
3. Operational Recommendations
3.1. Network advertising anycast prefixes
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.
Wilhelm & Kuenzler Expires 6 January 2023 [Page 3]
Internet-Draft Anycastcomm July 2022
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.
3.2. Network receiving prefixes with ANYCAST community
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.
3.3. ANYCAST community and IXP Route Servers
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.
4. Vendor Implementation Recommendations
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".
5. IANA Considerations
IANA is asked to register ANYCAST in the "BGP Well-known Communities"
registry.
ANYCAST (= TBD)
Wilhelm & Kuenzler Expires 6 January 2023 [Page 4]
Internet-Draft Anycastcomm July 2022
6. Security Considerations
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.
7. References
7.1. Normative References
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
<https://www.rfc-editor.org/info/rfc1997>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
7.2. Informative References
Acknowledgments
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, and
Lucas Pardue.
Authors' Addresses
Maximilian Wilhelm
Cloudflare
Phone: +49 176 62 05 94 27
Email: max@sdn.clinic
Fredy Kuenzler
Init7 (Switzerland) Ltd.
Technoparkstrasse 5
CH-8406 Winterthur
Switzerland
Wilhelm & Kuenzler Expires 6 January 2023 [Page 5]
Internet-Draft Anycastcomm July 2022
Email: kuenzler@init7.net
Wilhelm & Kuenzler Expires 6 January 2023 [Page 6]