Internet DRAFT - draft-ietf-grow-anycast-community
draft-ietf-grow-anycast-community
Global Routing Operations M. Wilhelm
Internet-Draft
Intended status: Informational F. Kuenzler
Expires: 29 May 2024 Init7
26 November 2023
A well-known BGP community to denote prefixes used for Anycast
draft-ietf-grow-anycast-community-03
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 29 May 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wilhelm & Kuenzler Expires 29 May 2024 [Page 1]
Internet-Draft Anycastcomm November 2023
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
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 Internet Exchange Points (IXPs) . . 4
3.4. ANYCAST community and iBGP Route Reflectors . . . . . . . 4
4. Vendor Implementation Recommendations . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
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 29 May 2024 [Page 2]
Internet-Draft Anycastcomm November 2023
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.
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.
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 29 May 2024 [Page 3]
Internet-Draft Anycastcomm November 2023
Operators of anycast services might choose to export their prefixes
carrying anycast traffic with the well-known NO_EXPORT BGP community
[RFC1997] set to control the distribution of their routes. Therefore
the ANYCAST BGP community might be used in conjunction with
NO_EXPORT.
3.2. Network receiving prefixes with ANYCAST community
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.
3.3. ANYCAST community and Internet Exchange Points (IXPs)
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.
3.4. ANYCAST community and iBGP Route Reflectors
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
Wilhelm & Kuenzler Expires 29 May 2024 [Page 4]
Internet-Draft Anycastcomm November 2023
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)
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.
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.
7. References
7.1. Normative References
Wilhelm & Kuenzler Expires 29 May 2024 [Page 5]
Internet-Draft Anycastcomm November 2023
[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>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>.
[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", RFC 7911,
DOI 10.17487/RFC7911, July 2016,
<https://www.rfc-editor.org/info/rfc7911>.
[RFC9107] Raszuk, R., Ed., Decraene, B., Ed., Cassar, C., Aman, E.,
and K. Wang, "BGP Optimal Route Reflection (BGP ORR)",
RFC 9107, DOI 10.17487/RFC9107, August 2021,
<https://www.rfc-editor.org/info/rfc9107>.
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,
Lucas Pardue, Robert Raszuk, Randy Bush, Jeffrey Haas, Warren Kumari,
Florian Streibelt, Klaus Darillion, and Michael Still.
Authors' Addresses
Maximilian Wilhelm
Germany
Phone: +49 176 62 05 94 27
Email: max@sdn.clinic
Fredy Kuenzler
Init7 (Switzerland) Ltd.
Technoparkstrasse 5
CH-8406 Winterthur
Switzerland
Email: kuenzler@init7.net
Wilhelm & Kuenzler Expires 29 May 2024 [Page 6]
