Global Routing Operations
Internet Engineering Task Force (IETF)                       J. Snijders
Internet-Draft
Request for Comments: 8195                                    J. Heasley
Intended status:
Category: Informational                                              NTT
Expires: October 21, 2017
ISSN: 2070-1721                                               M. Schmidt
                                                                 i3D.net
                                                          April 19,
                                                               June 2017

                      Use of BGP Large Communities
               draft-ietf-grow-large-communities-usage-07

Abstract

   This document presents examples and inspiration for operator's operator
   application of BGP Large Communities.  Based on operational
   experience with BGP Communties, Communities, this document suggests logical
   categories of BGP Large Communities and demonstrates an orderly
   manner of organizing community values within them to achieve typical
   goals in routing policy.  Any operator can consider using the
   concepts presented as the basis for their own BGP Large Communities
   repertoire.

Status of This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a maximum candidate for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 October 21, 2017.
   http://www.rfc-editor.org/info/rfc8195.

Copyright Notice

   Copyright (c) 2017 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
   (http://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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  The Design Overview . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Informational Communities . . . . . . . . . . . . . . . .   4
     2.2.  Action Communities  . . . . . . . . . . . . . . . . . . .   4
   3.  Examples of Informational Communities . . . . . . . . . . . .   5
     3.1.  Location  . . . . . . . . . . . . . . . . . . . . . . . .   5
       3.1.1.  An ISO 3166-1 Numeric Function  . . . . . . . . . . .   5
       3.1.2.  An  A UN M.49 Region Function . . . . . . . . . . . . . .   5
     3.2.  Relation Function . . . . . . . . . . . . . . . . . . . .   6
     3.3.  Combining Informational Communities . . . . . . . . . . .   6
   4.  Examples of Action Communities  . . . . . . . . . . . . . . .   7
     4.1.  Selective NO_EXPORT . . . . . . . . . . . . . . . . . . .   7
       4.1.1.  ASN Based  ASN-Based Selective NO_EXPORT . . . . . . . . . . . .   7
       4.1.2.  Location Based  Location-Based Selective NO_EXPORT  . . . . . . . . .   7
     4.2.  Selective AS_PATH Prepending  . . . . . . . . . . . . . .   8
       4.2.1.  ASN Based  ASN-Based Selective AS_PATH Prepending  . . . . . . .   8
       4.2.2.  Location Based  Location-Based Selective AS_PATH Prepending . . . . .   9
     4.3.  Manipulation of the LOCAL_PREF Attribute  . . . . . . . .   9
       4.3.1.  Global Manipulation of LOCAL_PREF . . . . . . . . . .  10
       4.3.2.  Region Based  Region-Based Manipulation of LOCAL_PREF . . . . . . .  10
       4.3.3.  Note of Caution for LOCAL_PREF Functions  . . . . . .  11
     4.4.  Route Server Prefix Distribution Control  . . . . . . . .  11
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  13
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     8.1.
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     8.2.
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  13
     8.3.  URIs  .
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   BGP Large Communities [RFC8092] provide a mechanism to signal opaque
   information between and within Autonomous Systems (ASs). (ASes).  In very
   much the same way that [RFC1998] provides a concrete real-world
   application for
   [RFC1997] communities, BGP Communities [RFC1997], this document presents
   examples of how operators might utilize BGP Large Communities to
   achieve various goals.  This document draws on the experience of
   operator communities such as NANOG [1] the North American Network Operators'
   Group (NANOG) <https://www.nanog.org/> and NLNOG [2]. the Netherlands Network
   Operator Group (NLNOG) <https://nlnog.net/>.

2.  The Design Overview

   BGP Large Communities are composed of three 4-octet fields.  The
   first is the Global Administrator (GA) field, whose value is the
   Autonomous System Number (ASN) of the AS that has defined the meaning
   of the remaining two 4-octet fields, known as "Local Data Part 1" and
   "Local Data Part 2".  This document describes an approach where the
   "Local Data Part 1" field contains a function identifier and the
   "Local Data Part 2" contains a parameter value.  Using the canonical
   notation this format can be summarized as "ASN:Function:Parameter".

                 +----------------------+---------------+
                 |       RFC 8092       | this document |
                 +----------------------+---------------+
                 | Global Administrator |      ASN      |
                 |  Local Data Part 1   |    Function   |
                 |  Local Data Part 2   |   Parameter   |
                 +----------------------+---------------+

   A

                          Table 1: Field Mapping

   The table above shows a mapping table on between the use of fields in BGP Large
   Communities between [RFC8092] and this document.

                          Table 1: Field Mapping

   In contemporary deployments of both BGP Communities [RFC1997] and BGP
   Large Communities, Communities [RFC8092], the function of a community can be
   divided into two categories:

   o  Informational Communities

   o  Action Communities

   Throughout the document document, a topology of four ASs ASes is used to
   illustrate the use of communities in the following configuration:

           AS 65551
               |
               ^
               |
           AS 64497
             /  \
            ^    \
           /      ^
      AS 64498     \
          |        |
          `<->- AS 64499
   AS 64497 obtains transit services from (is a customer of) AS 65551, a
   4-octet ASN.  AS 64497 provides transit services to both AS 64498 and
   AS 64499.  AS 64498 and AS 64499 maintain a peering relationship in
   which they only exchange their customer routes.

   The opaque nature of BGP Large Communities allows for rapid
   deployment of new features or changes to their routing policy that
   perform an action.  Operators are encouraged to publicly publish and
   maintain documentation on the purpose of each BGP Large Community,
   both informational Informational and action, Action, that they support or that are visible
   in BGP RIBs.

2.1.  Informational Communities

   Informational Communities are labels for attributes such as the
   origin of the route announcement, the nature of the relation with an
   EBGP neighbor
   External BGP (EBGP) neighbor, or the intended propagation audience.
   Informational Communities can also assist in providing valuable
   information for day-to-day network operations such as debugging or
   capacity planning.

   The Global Administrator field is set to the ASN which labels of the network that
   tags the routes with the Informational Communities.  For example, AS
   64497 might add a community with the GA 64497 to a route accepted
   from an
   IBGP Internal BGP (IBGP) or EBGP neighbor as a means of signaling
   that it was imported in a certain geographical region.

   In general, the intended audiences of Informational Communities are
   downstream networks and the Global Administrator GA itself, but any AS could benefit from
   receiving these communities.

2.2.  Action Communities

   Action Communities are added as a label labels to request that a route be
   treated in a particular way within an AS.  The operator of the AS
   defines a routing policy that adjusts path attributes based on the
   community.  For example, the route's propagation characteristics, the
   LOCAL_PREF (local preference), the next-hop, next hop, or the number of AS_PATH
   prepends to be added when it is received or propagated can be
   changed.

   The Global Administrator field is set to the ASN which that has defined the
   functionality of that BGP Large Community and is the ASN that is
   expected to perform the action.  For example, AS 64499 might label a
   route with a BGP Large Community containing GA 64497 to request that
   AS 64497 perform a pre-defined predefined action on that route.

   In general, the intended audience of Action Communities are transit
   providers taking action on behalf of a customer or the Global
   Administrator GA itself, but
   any AS could take action if they choose and any AS could add an
   Action Community with the GA of a non-adjacent ASN.  However, note
   that an Action Community could also be
   informational. Informational.  Its presence
   is an indicator that the GA may have performed the action and that an
   AS in the AS_PATH requested it.

   Operators are recommended to publish the relative order in which
   Action Communities (both BGP Communities and BGP Large Communities)
   are processed in their routing policy.

3.  Examples of Informational Communities

3.1.  Location

   An AS, AS 64497 in these examples, may inform other networks about
   the geographical region where AS 64497 imported a route by labeling
   it with BGP Large Communities following one of the following schemes
   or a combination of them.

3.1.1.  An ISO 3166-1 Numeric Function

   AS 64497 could assign a value of 1 to the Function field to designate
   the content of the Parameter field as an ISO-3166-1 [3] ISO 3166-1 numeric country identifier.
   identifier <https://www.iso.org/iso-3166-country-codes.html>.

   +---------------------+---------------------------------------------+
   | BGP Large Community | Description                                 |
   +---------------------+---------------------------------------------+
   |     64497:1:528     | Route learned in the Netherlands            |
   |     64497:1:392     | Route learned in Japan                      |
   |     64497:1:840     | Route learned in the United States of       |
   |                     | America                                     |
   +---------------------+---------------------------------------------+

    Example

                    Table 2: Informational: ISO 3166-1

   The table above shows example documentation for Informational
   Communities deployed by AS 64497 to describe the location where a
   route was imported using ISO 3166-1 numeric identifiers.

                     Table 2: Information: ISO 3166-1

3.1.2.  An  A UN M.49 Region Function

   AS 64497 could assign a value of 2 to the Function field to designate
   the content of the Parameter field as the M.49 numeric code published
   by the United Nations Statistics Division (UNSD) [4]
   <https://unstats.un.org/unsd/methodology/m49/> for macro
   geographical macro-geographical
   (continental) regions, geographical sub-regions, or selected economic
   and other groupings.

          +---------------------+-------------------------------+
          | BGP Large Community | Description                   |
          +---------------------+-------------------------------+
          |      64497:2:2      | Route learned in Africa       |
          |      64497:2:9      | Route learned in Oceania      |
          |     64497:2:145     | Route learned in Western Asia |
          |     64497:2:150     | Route learned in Europe       |
          +---------------------+-------------------------------+

    Example

                   Table 3: Informational: UNSD Regions

   The table above shows example documentation for Informational
   Communities deployed by AS 64497 to describe the location where a
   route was imported using M.49 numeric codes published by the United Nations Statistics Division.

                    Table 3: Information: UNSD Regions UNSD.

3.2.  Relation Function

   An AS, AS 64497 in this example, could assign a value of 3 to the
   Function field to designate the content of the Parameter field as a
   number indicating whether the route originated inside its own network
   or was learned externally, and if learned externally, it might
   simultaneously characterize the nature of the relation with that
   specific EBGP neighbor.

      +---------------------+---------------------------------------+
      | BGP Large Community | Description                           |
      +---------------------+---------------------------------------+
      |      64497:3:1      | Route originated internally           |
      |      64497:3:2      | Route learned from a customer         |
      |      64497:3:3      | Route learned from a peering partner  |
      |      64497:3:4      | Route learned from a transit provider |
      +---------------------+---------------------------------------+

    Example

                     Table 4: Informational: Relation

   The table above shows example documentation for Informational
   Communities deployed by AS 64497 to describe the relation to the ASN
   from which the route was learned.

                      Table 4: Information: Relation

3.3.  Combining Informational Communities

   A route may be labeled with multiple Informational Communities.  For
   example, a route learned in the Netherlands from a customer might be
   labeled with communities 64497:1:528, 64497:2:150 64497:2:150, and 64497:3:2 at
   the same time.

4.  Examples of Action Communities

4.1.  Selective NO_EXPORT

   As part of an agreement, often a commercial transit agreement,
   between AS 64497 and AS 64498, AS 64497 might expose BGP traffic traffic-
   engineering functions to AS 64498.  One such BGP traffic engineering traffic-engineering
   function could be selective NO_EXPORT, which is the selective
   filtering of a route learned from one AS, AS 64498, to certain EBGP
   neighbors of the GA, AS 64497.

4.1.1.  ASN Based  ASN-Based Selective NO_EXPORT

   AS 64497 could assign a value of 4 to the Function field to designate
   the content of the Parameter field as a neighboring ASN to which a
   route should not be propagated.

         +---------------------+---------------------------------+
         | BGP Large Community | Description                     |
         +---------------------+---------------------------------+
         |    64497:4:64498    | Do not export route to AS 64498 |
         |    64497:4:64499    | Do not export route to AS 64499 |
         |    64497:4:65551    | Do not export route to AS 65551 |
         +---------------------+---------------------------------+

   Example

                      Table 5: Action: ASN NO_EXPORT

   The table above shows example documentation for Action Communities
   deployed by AS 64497 to expose a BGP traffic engineering traffic-engineering function which
   that selectively prevents the propagation of routes to the
   neighboring ASN specified in the Parameter field.

                      Table 5: Action: ASN NO_EXPORT

4.1.2.  Location Based  Location-Based Selective NO_EXPORT

   AS 64497 could assign a value of 5 to the Function field to designate
   the content of the Parameter field as an ISO 3166-1 numeric country
   identifier within which a labeled route is not propagated to EBGP
   neighbors.  However, this might not prevent one of those EBGP
   neighbors from learning that route in another country and making it
   available in the country specified by the BGP Large Community.

   +-----------------+-------------------------------------------------+
   |    BGP Large    | Description                                     |
   |    Community    |                                                 |
   +-----------------+-------------------------------------------------+
   |   64497:5:528   | Do not export to EBGP neighbors in the          |
   |                 | Netherlands                                     |
   |   64497:5:392   | Do not export to EBGP neighbors in Japan        |
   |   64497:5:840   | Do not export to EBGP neighbors in the United   |
   |                 | States of America                               |
   +-----------------+-------------------------------------------------+

   Example

                   Table 6: Action: NO_EXPORT in Region

   The table above shows example documentation for Action Communities
   deployed by AS 64497 to expose a BGP traffic engineering traffic-engineering function which
   that selectively prevents the propagation of routes to all EBGP
   neighbors in the geographical region specified in the Parameter
   field.

                   Table 6: Action: NO_EXPORT in Region

4.2.  Selective AS_PATH Prepending

   As part of an agreement between AS 64497 and AS 64498, AS 64497 might
   expose BGP traffic engineering traffic-engineering functions to AS 64498.  One such BGP
   traffic engineering
   traffic-engineering function could be selective prepending of the
   AS_PATH with AS 64497 to certain certain EBGP neighbors of AS 64497.

4.2.1.  ASN Based  ASN-Based Selective AS_PATH Prepending

   AS 64497 could assign a value of 6 to the Function field to designate
   the content of the Parameter field as a neighboring ASN to which
   prepending of the AS_PATH with AS 64497 is requested on propagation
   of the route.  Additional AS_PATH prepending functions might also be
   defined to support multiples of prepending, that is is, two, three three, or
   more prepends of AS 64497.

    +---------------------+------------------------------------------+
    | BGP Large Community | Description                              |
    +---------------------+------------------------------------------+
    |    64497:6:64498    | Prepend 64497 once on export to AS 64498 |
    |    64497:6:64499    | Prepend 64497 once on export to AS 64499 |
    |    64497:6:65551    | Prepend 64497 once on export to AS 65551 |
    +---------------------+------------------------------------------+

   Example

                      Table 7: Action: Prepend to ASN

   The table above shows example documentation for Action Communities
   deployed by AS 64497 to expose a BGP traffic engineering traffic-engineering function which
   that selectively prepends the AS_PATH with AS 64497 when propagating
   the route to the specified EBGP neighbor.

                      Table 7: Action: Prepend to ASN

4.2.2.  Location Based  Location-Based Selective AS_PATH Prepending

   AS 64497 could assign a value of 7 to the Function field to designate
   the content of the Parameter field as an ISO 3166-1 numeric country
   identifier to which the prepending of the AS_PATH with AS 64497 is
   requested on propagation of the route to all EBGP neighbors in that
   region.

   +------------------+------------------------------------------------+

   +-----------------+-------------------------------------------------+
   |    BGP Large    | Description                                     |
   |    Community    |                                                 |
   +------------------+------------------------------------------------+
   +-----------------+-------------------------------------------------+
   |   64497:7:528   | Prepend once to EBGP neighbors in the           |
   |                 | Netherlands                                     |
   |   64497:7:392   | Prepend once to EBGP neighbors in Japan         |
   |   64497:7:840   | Prepend once to EBGP neighbors in the United    |
   |                 | States of America                               |
   +------------------+------------------------------------------------+

   Example
   +-----------------+-------------------------------------------------+

                    Table 8: Action: Prepend in Region

   The table above shows example documentation for Action Communities
   deployed by AS 64497 to expose a BGP traffic engineering traffic-engineering function which
   that selectively prepends the AS_PATH with AS 64497 when propagating
   the route to all EBGP neighbors in the geographical region specified
   in the Parameter field.

                    Table 8: Action: Prepend in Region

4.3.  Manipulation of the LOCAL_PREF Attribute

   As part of an agreement between AS 64497 and AS 64498, AS 64497 might
   expose BGP traffic engineering traffic-engineering functions to AS 64498.  One such BGP
   traffic engineering
   traffic-engineering function might allow AS 64498 to manipulate the
   value of the LOCAL_PREF attribute of routes learned from AS 64498
   within AS 64497, even though the LOCAL_PREF attribute is non-
   transitive and is not propagated to EBGP neighbors.

   The LOCAL_PREF value of routes are locally significant within each AS
   and are impossible to list in this document.  Instead, the typical
   LOCAL_PREF values could be classified as a hierarchy hierarchy, and a BGP Large
   Community function exposed could be exposed, allowing an EBGP neighbor to
   affect the LOCAL_PREF value within the specified GA.  The following
   example list defines the classes of routes in the order of descending
   LOCAL_PREF value and assigns a function identifier which that could be used
   in the Function field of a BGP Large Community.

   +----------+--------------------------------------------------------+
   | Function | Preference Class                                       |
   +----------+--------------------------------------------------------+
   |    8     | Normal customer route                                  |
   |    9     | Backup customer route                                  |
   |    10    | Peering route                                          |
   |    11    | Upstream transit route                                 |
   |    12    | Fallback route, to be installed if no other path is    |
   |          | available                                              |
   +----------+--------------------------------------------------------+

             Table 9: Action: Preference Function Identifiers

4.3.1.  Global Manipulation of LOCAL_PREF

   AS 64497 could place one of the previously defined Preference
   Function Identifiers in the Function field and set the value 0 in the
   Parameter field to designate that the LOCAL_PREF associated with that
   function identifier should be applied for that route throughout the
   whole AS.

   +---------------------+---------------------------------------------+
   | BGP Large Community | Description                                 |
   +---------------------+---------------------------------------------+
   |      64497:9:0      | Assign LOCAL_PREF for a customer backup     |
   |                     | route                                       |
   |      64497:10:0     | Assign LOCAL_PREF for a peering route       |
   |      64497:12:0     | Assign LOCAL_PREF for a fallback route      |
   +---------------------+---------------------------------------------+

   Example

             Table 10: Action: Global LOCAL_PREF Manipulation

   The table above shows example documentation for Action Communities
   deployed by AS 64497 to expose a BGP traffic engineering traffic-engineering function which
   that allows a BGP neighbor to globally manipulate the LOCAL_PREF
   attribute for the route within AS 64497.

             Table 10: Action: Global LOCAL_PREF Manipulation

4.3.2.  Region Based  Region-Based Manipulation of LOCAL_PREF

   AS 64497 could place one of the previously defined Preference
   Function Identifiers in the Function field and use an a UN M.49 numeric
   region identifier in the Parameter field to designate the
   geographical region within which the non-default LOCAL_PREF
   associated with that function identifier should be applied to the
   route.  The value of the LOCAL_PREF attribute should not deviate from
   the default for that route class in any region not specified by one
   or more of these Action Communities.

   +--------------+----------------------------------------------------+
   |  BGP Large   | Description                                        |
   |  Community   |                                                    |
   +--------------+----------------------------------------------------+
   |  64497:9:3   | Assign the LOCAL_PREF value equivalent to a        |
   |              | customer backup class route on BGP routers in the  |
   |              | North America region                               |
   |  64497:10:5  | Assign the LOCAL_PREF value equivalent to a        |
   |              | peering class route on BGP routers in the South    |
   |              | America region                                     |
   | 64497:12:142 | Assign the LOCAL_PREF value equivalent to a        |
   |              | fallback class route on BGP routers in the Asia    |
   |              | region                                             |
   +--------------+----------------------------------------------------+

   Example

            Table 11: Action: Regional LOCAL_PREF Manipulation

   The table above shows example documentation for Action Communities
   deployed by AS 64497 to expose a BGP traffic engineering traffic-engineering function which
   that allows a BGP neighbor to selectively manipulate the LOCAL_PREF
   attribute within AS 64497 in the geographical region specified in the
   Parameter field.

            Table 11: Action: Regional LOCAL_PREF Manipulation

4.3.3.  Note of Caution for LOCAL_PREF Functions

   The LOCAL_PREF attribute strongly influences the BGP Decision
   Process, which in turn affects the scope of route propagation.
   Operators should take special care when using Action Communities that
   decrease the LOCAL_PREF value, and the degree of preference, to a
   value below that of another route class.  Some of the unintended BGP
   states that might arise as a result of these traffic engineering traffic-engineering
   decisions are described as "BGP Wedgies" in [RFC4264].

4.4.  Route Server Prefix Distribution Control

   Route Servers servers [RFC7947] use BGP to broker network reachability
   information among their clients.  As not all route server clients may
   wish to interconnect with each other, the route server operator will
   usually implement a mechanism to allow each client to control the
   route server's export routing policy, as described in Section 4.6 of
   [RFC7948].  One widely-used widely used mechanism is a route server specific an adaption of "ASN Based "ASN-Based
   Selective NO_EXPORT" (Section 4.1.1). 4.1.1) that is specific to route
   servers.

   An example BGP Large Communities policy which that enables client-
   controlled prefix distribution for a route server operating as AS
   64497,
   64511 is outlined as follows:

   +-------------------+-----------------------------------------------+
   | BGP Large         | Description                                   |
   | Community         |                                               |
   +-------------------+-----------------------------------------------+
   | 64497:13:peer-as 64511:0:peer-as   | Explicitly prevent announcement of route to   |
   |                   | peer-as                                       |
   | 64497:14:peer-as 64511:1:peer-as   | Explicitly announce route to peer-as          |
   | 64497:13:0 64511:0:0         | Do not announce route to any peers by default |
   | 64497:14:0 64511:1:0         | Announce route to all peers by default        |
   +-------------------+-----------------------------------------------+

        Table 12: Action: Route Server Prefix Distribution Control

   Multiple BGP Large Community values can be used together to implement
   fine-grained route distribution control.  For example, route server
   client AS 64500 might wish to use a route server for interconnecting
   to all other clients except AS 64510. 64509.  In this case, they would label
   all their outbound routes to the route server with 64497:14:0 64511:1:0 (to
   announce to all clients by default) and 64497:13:64510 64511:0:64509 (to prevent
   announcement to AS 64510). 64509).

   Alternatively, route server client AS 64501 may have a selective
   routing policy and may wish to interconnect with only AS 64505 and AS
   64506.  This could be implemented by announcing routes labeled with
   64497:13:0
   64511:0:0 (blocking all distribution by default) and 64497:14:64505,
   64497:14:64506 64511:1:64505,
   64511:1:64506 to instruct the route server to force announcement to
   those two ASNs.

5.  Security Considerations

   Operators should note the recommendations in Section 11 of BGP "BGP
   Operations and Security Security" [RFC7454] and handle BGP Large Communities
   with their ASN in the Global Administrator field similarly.

   In particular and in the same respect as BGP Communities [RFC1997],
   operators should be congnizant cognizant that any Large Community can be carried
   in a BGP UPDATE.  Operators should recognize that BGP neighbors,
   particularly customers and customers of customers, may utilize
   communities defined by other BGP neighbors of the operator.  They may
   wish to send routes with action communities Action Communities and receive routes with informational communities
   Informational Communities to or from these other
   neighbors neighbors, and it is
   beneficial to all to permit this.

6.  IANA Considerations

   None.

   This document does not require any IANA actions.

7.  Acknowledgments

   The authors would like to gratefully acknowledge the insightful
   comments, contributions, critique and support from Adam Chappell,
   Jonathan Stewart, Greg Hankins, Nick Hilliard, Will Hargrave, Randy
   Bush, Shawn Morris, Jay Borkenhagen and Stewart Bryant.

8.  References

8.1.

7.1.  Normative References

   [RFC1997]  Chandra, R., Traina, P., and T. Li, "BGP Communities
              Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
              <http://www.rfc-editor.org/info/rfc1997>.

   [RFC7454]  Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
              and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
              February 2015, <http://www.rfc-editor.org/info/rfc7454>.

   [RFC8092]  Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas,
              I., and N. Hilliard, "BGP Large Communities Attribute",
              RFC 8092, DOI 10.17487/RFC8092, February 2017,
              <http://www.rfc-editor.org/info/rfc8092>.

8.2.

7.2.  Informative References

   [RFC1998]  Chen, E. and T. Bates, "An Application of the BGP
              Community Attribute in Multi-home Routing", RFC 1998,
              DOI 10.17487/RFC1998, August 1996,
              <http://www.rfc-editor.org/info/rfc1998>.

   [RFC4264]  Griffin, T. and G. Huston, "BGP Wedgies", RFC 4264,
              DOI 10.17487/RFC4264, November 2005,
              <http://www.rfc-editor.org/info/rfc4264>.

   [RFC7947]  Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker,
              "Internet Exchange BGP Route Server", RFC 7947,
              DOI 10.17487/RFC7947, September 2016,
              <http://www.rfc-editor.org/info/rfc7947>.

   [RFC7948]  Hilliard, N., Jasinska, E., Raszuk, R., and N. Bakker,
              "Internet Exchange BGP Route Server Operations", RFC 7948,
              DOI 10.17487/RFC7948, September 2016,
              <http://www.rfc-editor.org/info/rfc7948>.

8.3.  URIs

   [1] https://www.nanog.org

   [2] https://nlnog.net

   [3] https://www.iso.org/iso-3166-country-codes.html

   [4] https://unstats.un.org/unsd/methodology/m49/

Acknowledgments

   The authors would like to gratefully acknowledge the insightful
   comments, contributions, critique, and support from Adam Chappell,
   Jonathan Stewart, Greg Hankins, Nick Hilliard, Will Hargrave, Randy
   Bush, Shawn Morris, Jay Borkenhagen, and Stewart Bryant.

Authors' Addresses

   Job Snijders
   NTT Communications
   Theodorus Majofskistraat 100
   Amsterdam  1065 SZ
   The Netherlands

   Email: job@ntt.net

   John Heasley
   NTT Communications
   1111 NW 53rd Drive
   Portland, OR  97210
   United States of America

   Email: heas@shrubbery.net

   Martijn Schmidt
   i3D.net
   Rivium 1e Straat 1
   Capelle aan den IJssel  2909 LE
   NL
   The Netherlands

   Email: martijnschmidt@i3d.net