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

Abstract

Examples and inspiration for operators on how to use Large BGP Communities.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

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 June 10, 2017.

Copyright Notice

Copyright (c) 2016 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. The Generic Design Pattern
• 2.1. Informational Communities
• 2.2. Action Communities
• 3. Examples of Informational Communities
• 3.1. Location
• 3.1.1. An ISO 3166-1 numeric function
• 3.1.2. An UNSD region function
• 3.2. Relation
• 3.3. Combining Informational Communities
• 4. Examples of Action Communities
• 4.1. Selective NO_EXPORT
• 4.1.1. Peer ASN Based Selective NO_EXPORT
• 4.1.2. Location Based Selective NO_EXPORT
• 4.2. Selective AS_PATH Prepending
• 4.2.1. Peer ASN Based Selective AS_PATH Prepending
• 4.2.2. Location Based Selective AS_PATH Prepending
• 4.3. Region-Specific LOCAL_PREFERENCE
• 5. Security Considerations
• 6. IANA Considerations
• 7. Acknowledgements
• 8. Normative References
• Authors' Addresses

1. Introduction

Large BGP Communities [I-D.ietf-idr-large-community] provide a mechanism to signal opaque information between Autonomous Systems. This document presents a set of examples on how Large BGP Communities could be implemented by an operator to achieve various goals. This document draws from experience in Operational Communities such as NANOG and NLNOG.

The opaque nature of Large BGP Communities allows for rapid deployment of new features or changes to the product. Operators are encouraged to publicly publish an up to date version of their routing policy in which they document what each Large BGP Community means.

2. The Generic Design Pattern

Large BGP Communities are composed of a 4-octet Global Administrator field followed by two 4-octet Local Data fields. The design pattern described in this document uses a "ASN:Function:Parameter"-approach to fill the three fields.

In deployments of both BGP Communities [RFC1997] and Large BGP Communities, two categories of Communities are recognised:

• Informational Communities
• Action Communities

For each context ideas are provided regarding the contents of each of the three fields in Large BGP Communities.

        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:

2.1. Informational Communities

Informational Communites serve as markers regarding the origin of the route announcement, the relation with the EBGP neighbor or for instance the intended propagation audience. Informational Communities also assist in network operations such as debugging.

The Global Administrator field is set to the ASN which is marking the routes with the Informational Communities. As an example: on a route which AS 64497 announces to AS 64498, AS 64497 might add the Large BGP Community 64497:100:31 to signal to AS 64498 that the route was learned in the Netherlands.

In general the intended audience of Informational Communities are downstream networks, but any adjacent Autonomous System could benefit from receiving these communities.

2.2. Action Communities

Action Communities are attached to routes to request non-default behaviour in an adjacent Autonomous System. For instance, Action Communities are used to change the route's propagation characteristics, the route's LOCAL_PREF value or the amount of AS_PATH prepends that should be added when exporting or importing a route.

The Global Administrator field is set to the ASN which is expected to perform a non-default action upon receiving the route. For instance, if AS 64499 would want to request AS 64497 to lower the LOCAL_PREFERENCE below the default, AS 64499 could tag the route with 64497:20:50.

In general the intended audience of Action Communities is an upstream provider.

3. Examples of Informational Communities

3.1. Location

AS 64497 can inform its downstream networks about the geographical entity where AS 64497 learned a route by marking the route with Large BGP Communities following one or a combination of the following schemes.

3.1.1. An ISO 3166-1 numeric function

AS 64497 could assign a value of 1 to the first Local Data field to designate the function of the parameter in the second Local Data field as ISO-3166-1 numeric country identifiers.