Global Routing Operations J. Snijders
Internet-Draft J. Heasley
Intended status: Informational NTT
Expires: September 13, 2017 M. Schmidt
i3D.net
March 12, 2017

Usage of BGP Large Communities
draft-ietf-grow-large-communities-usage-03

Abstract

Examples and inspiration for operators for the use of BGP Large Communities.

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 http://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 September 13, 2017.

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

BGP Large Communities [RFC8092] provide a mechanism to signal opaque information between Autonomous Systems. This document presents examples of how operators might utilise BGP Large Communities to achieve various goals. This document draws from experience of operational communities such as NANOG and NLNOG.

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 Autonomous System (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 the above can be summarized as "ASN:Function:Parameter".

Field mapping
RFC 8092 this document
Global Administrator ASN
Local Data Part 1 Function
Local Data Part 2 Parameter

A mapping table on the usage of fields in BGP Large Communities between [RFC8092] and this document.

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

        AS 65551
            |
            ^
            |
        AS 64497
          /  \
         ^    \
        /      ^
   AS 64498     \
       |        | 
       `<->- AS 64499

Throughout the document a topology of four Autonomous Systems is used to illustrate the usage of Communities in the following configuration:

The opaque nature of BGP Large Communities allows for rapid deployment of new features or changes to products. Operators are encouraged to publicly publish and maintain documentation of the purpose of each BGP Large Community, both informational and action, that they support or 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 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 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 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 itself, but any Autonomous System could benefit from receiving these communities.

2.2. Action Communities

Action Communities are added as a label to request non-default treatment of a route within an AS. The operator of that AS defines routing policy which, based upon the communities, adjusts route attributes such as its propagation characteristics, the LOCAL_PREF (local preference), the next-hop, or the number of AS_PATH prepends to be added upon reception or propagation.

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

In general, the intended audience of Action Communities are transit providers taking action on behalf of a customer or the Global Administrator itself, but any AS could take action if they chose 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. Its presence is an indicator that the GA may have performed the action and that an AS in the AS_PATH requested it.

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 thereof.

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 numeric country identifier.

Information: ISO 3166-1
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 documentation for Informational Communities deployed by AS 64497 to describe the location where a route was imported using ISO 3166-1 numeric identifiers.

3.1.2. 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) for macro geographical (continental) regions, geographical sub-regions, or selected economic and other groupings.

Information: UNSD Regions
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 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.

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.

Information: Relation
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 documentation for Informational Communities deployed by AS 64497 to describe the relation to the ASN from which the route was learned.

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 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 engineering functions to AS 64498. One such BGP 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 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.

Action: ASN NO_EXPORT
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 documentation for Action Communities deployed by AS 64497 to expose a BGP traffic engineering function which selectively prevents the propagation of routes to the neighboring ASN specified in the Parameter field.

4.1.2. 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 thereby making it available in the country specified by the BGP Large Community.

Action: NO_EXPORT in Region
BGP Large Community Description
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 documentation for Action Communities deployed by AS 64497 to expose a BGP traffic engineering function which selectively prevents the propagation of routes to all EBGP neighbors in the geographical region specified in the Parameter field.

4.2. Selective AS_PATH Prepending

As part of an agreement between AS 64497 and AS 64498, AS 64497 might expose BGP traffic engineering functions to AS 64498. One such BGP 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 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 upon propagation of the route. Additional AS_PATH Prepending functions might also be defined to support multiples of prepending, that is two, three or more prepends of AS 64497.

Action: Prepend to ASN
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 documentation for Action Communities deployed by AS 64497 to expose a BGP traffic engineering function which selectively prepends the AS_PATH with AS 64497 when propagating the route to the specified EBGP neighbor.

4.2.2. 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 upon propagation of the route to all EBGP neighbors in that region.

Action: Prepend in Region
BGP Large Community Description
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 United States of America

Example documentation for Action Communities deployed by AS 64497 to expose a BGP traffic engineering function which 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.

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 functions to AS 64498. One such BGP 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 therefore is not propagated to EBGP neighbors.

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

Action: Preference Function Identifiers
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.

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 Autonomous System.

Action: Global LOCAL_PREF Manipulation
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 documentation for Action Communities deployed by AS 64497 to expose a BGP traffic engineering function which allows a BGP neighbor to globally manipulate the LOCAL_PREF attribute for the route within AS 64497.

4.3.2. Location Based Manipulation of LOCAL_PREF

AS 64497 could place one of the previously defined Preference Function Identifiers in the Function field and use an ISO 3166-1 numeric country 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.

Action: Regional LOCAL_PREF Manipulation
BGP Large Community Description
64497:9:528 Assign LOCAL_PREF for a customer backup route on BGP speakers in the Netherlands
64497:10:392 Assign LOCAL_PREF for a peering route on BGP speakers in Japan
64497:12:840 Assign LOCAL_PREF for a fallback route on BGP speakers in United States of America

Example documentation for Action Communities deployed by AS 64497 to expose a BGP traffic engineering function which allows a BGP neighbor to selectively manipulate the LOCAL_PREF attribute within AS 64497 in the geographical region specified in the Parameter field.

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. Therefore, Operators should take special care when using Action Communities that decrease the LOCAL_PREF value, and therefore 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 decisions are described as "BGP Wedgies" in [RFC4264].

5. Security Considerations

Network operators should note the recommendations in Section 11 of BGP Operations and Security [RFC7454].

6. IANA Considerations

None.

7. Acknowledgments

The authors would like to gratefully acknowledge the insightful comments, contributions, critique and support from Adam Chappell, Jonathan Stewart, and Will Hargrave.

8. Normative References

[RFC1997] Chandra, R., Traina, P. and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996.
[RFC4264] Griffin, T. and G. Huston, "BGP Wedgies", RFC 4264, DOI 10.17487/RFC4264, November 2005.
[RFC7454] Durand, J., Pepelnjak, I. and G. Doering, "BGP Operations and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, February 2015.
[RFC8092] Heitz, J., Snijders, J., Patel, K., Bagdonas, I. and N. Hilliard, "BGP Large Communities Attribute", RFC 8092, DOI 10.17487/RFC8092, February 2017.

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 EMail: martijnschmidt@i3d.net