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]