draft-ietf-grow-large-communities-usage-02.txt   draft-ietf-grow-large-communities-usage-03.txt 
Global Routing Operations J. Snijders Global Routing Operations J. Snijders
Internet-Draft J. Heasley Internet-Draft J. Heasley
Intended status: Informational NTT Intended status: Informational NTT
Expires: August 20, 2017 M. Schmidt Expires: September 13, 2017 M. Schmidt
i3D.net i3D.net
February 16, 2017 March 12, 2017
Usage of BGP Large Communities Usage of BGP Large Communities
draft-ietf-grow-large-communities-usage-02 draft-ietf-grow-large-communities-usage-03
Abstract Abstract
Examples and inspiration for operators for the use of BGP Large Examples and inspiration for operators for the use of BGP Large
Communities. 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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 20, 2017. This Internet-Draft will expire on September 13, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Generic Design Pattern . . . . . . . . . . . . . . . . . 3 2. The Design Overview . . . . . . . . . . . . . . . . . . . . . 2
2.1. Informational Communities . . . . . . . . . . . . . . . . 3 2.1. Informational Communities . . . . . . . . . . . . . . . . 4
2.2. Action Communities . . . . . . . . . . . . . . . . . . . 4 2.2. Action Communities . . . . . . . . . . . . . . . . . . . 4
3. Examples of Informational Communities . . . . . . . . . . . . 4 3. Examples of Informational Communities . . . . . . . . . . . . 5
3.1. Location . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Location . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. An ISO 3166-1 numeric function . . . . . . . . . . . 4 3.1.1. An ISO 3166-1 numeric function . . . . . . . . . . . 5
3.1.2. An UNSD region function . . . . . . . . . . . . . . . 5 3.1.2. A UN M.49 Region function . . . . . . . . . . . . . . 5
3.2. Relation . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Relation Function . . . . . . . . . . . . . . . . . . . . 6
3.3. Combining Informational Communities . . . . . . . . . . . 6 3.3. Combining Informational Communities . . . . . . . . . . . 6
4. Examples of Action Communities . . . . . . . . . . . . . . . 6 4. Examples of Action Communities . . . . . . . . . . . . . . . 7
4.1. Selective NO_EXPORT . . . . . . . . . . . . . . . . . . . 6 4.1. Selective NO_EXPORT . . . . . . . . . . . . . . . . . . . 7
4.1.1. Peer ASN Based Selective NO_EXPORT . . . . . . . . . 6 4.1.1. ASN Based Selective NO_EXPORT . . . . . . . . . . . . 7
4.1.2. Location Based Selective NO_EXPORT . . . . . . . . . 7 4.1.2. Location Based Selective NO_EXPORT . . . . . . . . . 7
4.2. Selective AS_PATH Prepending . . . . . . . . . . . . . . 7 4.2. Selective AS_PATH Prepending . . . . . . . . . . . . . . 8
4.2.1. Peer ASN Based Selective AS_PATH Prepending . . . . . 7 4.2.1. ASN Based Selective AS_PATH Prepending . . . . . . . 8
4.2.2. Location Based Selective AS_PATH Prepending . . . . . 8 4.2.2. Location Based Selective AS_PATH Prepending . . . . . 9
4.3. Location based manipulation of LOCAL_PREF . . . . . . . . 8 4.3. Manipulation of the LOCAL_PREF attribute . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4.3.1. Global Manipulation of LOCAL_PREF . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4.3.2. Location Based Manipulation of LOCAL_PREF . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 4.3.3. Note of Caution for LOCAL_PREF Functions . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
BGP Large Communities [RFC8092] provide a mechanism to signal opaque BGP Large Communities [RFC8092] provide a mechanism to signal opaque
information between Autonomous Systems. This document presents a set information between Autonomous Systems. This document presents
of examples of how Large BGP Communities could be employed by an examples of how operators might utilise BGP Large Communities to
operator to achieve various goals. This document draws from achieve various goals. This document draws from experience of
experience in Operational Communities such as NANOG [1] and NLNOG operational communities such as NANOG [1] and NLNOG [2].
[2].
The opaque nature of BGP Large Communities allows for rapid 2. The Design Overview
deployment of new features or changes to the product. Operators are
encouraged to publicly publish and maintain documentation of the
purpose of each Large BGP Community, both informational and action,
that they support or are visible in looking glasses.
2. The Generic Design Pattern 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.
BGP Large Communities are composed of a 4-octet Global Administrator Using the canonical notation the above can be summarized as
field followed by two 4-octet Local Data fields. Large BGP "ASN:Function:Parameter".
Communities are compose three 4-octet fields. The first is the
Global Administrator field, whose value is the ASN of AS that has
defined the meaning of the remaining two 4-octet fields, the Local
Data fields. This document describes an approach defining these
fields as "ASN:Function:Parameter"-approach to fill the three fields.
In deployments of both BGP Communities [RFC1997] and BGP Large +----------------------+---------------+
Communities, two categories of Communities exist: | 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.
Table 1: Field mapping
In contemporary deployments of both BGP Communities [RFC1997] and BGP
Large Communities, the function of a community can be divided into
two categories:
o Informational Communities o Informational Communities
o Action Communities o Action Communities
For each, ideas are provided regarding the contents of each of the
three fields in BGP Large Communities.
Throughout the document a topology of four Autonomous Systems is used Throughout the document a topology of four Autonomous Systems is used
to illustrate the usage of Communities in the following to illustrate the usage of Communities in the following
configuration: configuration:
AS 65551 AS 65551
| |
^ ^
| |
AS 64497 AS 64497
/ \ / \
^ \ ^ \
/ ^ / ^
AS 64498 \ AS 64498 \
| | | |
`<->- AS 64499 `<->- AS 64499
AS 64497 obtains transit services from AS 65551, a 32-bit ASN. AS AS 64497 obtains transit services from (is a customer of) AS 65551, a
64497 provides transit services to both AS 64498 and AS 64499. AS 32-bit ASN. AS 64497 provides transit services to both AS 64498 and
64498 and AS 64499 maintain a peering relationship in which they only AS 64499. AS 64498 and AS 64499 maintain a peering relationship in
exchange their customer routes. which they only exchange their customer routes.
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 2.1. Informational Communities
Informational Communites are labels for attributes such as origin of Informational Communities are labels for attributes such as the
the route announcement, the relation with the EBGP neighbor or for origin of the route announcement, the nature of the relation with an
instance the intended propagation audience. Informational EBGP neighbor or the intended propagation audience. Informational
Communities also assist in network operations such as debugging. 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 is marking the The Global Administrator field is set to the ASN which labels the
routes with the Informational Communities. For example, AS 64497 routes with the Informational Communities. For example, AS 64497
might add a community with the GA 64497 to a route learned from an might add a community with the GA 64497 to a route accepted from an
iBGP or eBGP peer that means that the route was learned from or IBGP or EBGP neighbor as a means of signaling that it was imported in
originated by a device in the Netherlands. a certain geographical region.
In general the intended audience of Informational Communities are In general, the intended audiences of Informational Communities are
downstream networks and the Global Administrator itself, but any downstream networks and the Global Administrator itself, but any
Autonomous System could benefit from receiving these communities. Autonomous System could benefit from receiving these communities.
2.2. Action Communities 2.2. Action Communities
Action Communities are attached to routes to request non-default Action Communities are added as a label to request non-default
behaviour in this, a conferation or an external AS. Action treatment of a route within an AS. The operator of that AS defines
Communities could be used to change the route's propagation routing policy which, based upon the communities, adjusts route
characteristics, the LOCAL_PREFENCE or the number of AS_PATH prepends attributes such as its propagation characteristics, the LOCAL_PREF
to add when exporting or importing a route. (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 is expected to The Global Administrator field is set to the ASN which has defined
perform the action. For instance, AS 64499 might add a Large the functionality of that BGP Large Community and is therefore the
Community with the GA 64497 to signal AS 64497 to perform an action ASN that is expected to perform the action. For instance, AS 64499
upon that route. 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 is an upstream In general, the intended audience of Action Communities are transit
provider, but realistically could be any AS willing to act upon it. 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. Examples of Informational Communities
3.1. Location 3.1. Location
AS 64497 can inform its downstream networks about the geographical An AS, AS 64497 in these examples, may inform other networks about
entity where AS 64497 learned a route by marking the route with BGP the geographical region where AS 64497 imported a route by labeling
Large Communities following one or a combination of the following it with BGP Large Communities following one of the following schemes
schemes. or a combination thereof.
3.1.1. An ISO 3166-1 numeric function 3.1.1. An ISO 3166-1 numeric function
AS 64497 could assign a value of 1 to the first Local Data field to AS 64497 could assign a value of 1 to the Function field to designate
designate the function of the second Local Data field as ISO-3166-1 the content of the Parameter field as an ISO-3166-1 [3] numeric
numeric country identifiers. country identifier.
+---------------------+-------------------------------------------+ +---------------------+---------------------------------------------+
| BGP Large Community | Description | | BGP Large Community | Description |
+---------------------+-------------------------------------------+ +---------------------+---------------------------------------------+
| 64497:1:528 | Route learned in Netherlands | | 64497:1:528 | Route learned in the Netherlands |
| 64497:1:392 | Route learned in Japan | | 64497:1:392 | Route learned in Japan |
| 64497:1:840 | Route learned in United States of America | | 64497:1:840 | Route learned in the United States of |
+---------------------+-------------------------------------------+ | | America |
+---------------------+---------------------------------------------+
Example documentation for AS 64497 using Informational Communities Example documentation for Informational Communities deployed by AS
describing the origin of routes using ISO 3166-1 numeric identifiers. 64497 to describe the location where a route was imported using ISO
3166-1 numeric identifiers.
Table 1: Information: ISO 3166-1 Table 2: Information: ISO 3166-1
3.1.2. An UNSD region function 3.1.2. A UN M.49 Region function
AS 64497 could assign a value of 2 to the first Local Data field to AS 64497 could assign a value of 2 to the Function field to designate
designate the function of the parameter in the second Local Data the content of the Parameter field as the M.49 numeric code published
field as an identifier for the macro geographical (continental) by the United Nations Statistics Division (UNSD) [4] for macro
regions, geographical sub-regions, or selected economic and other geographical (continental) regions, geographical sub-regions, or
groupings following a set of published identifiers by the United selected economic and other groupings.
Nations Statistics Division [3].
+---------------------+-------------------------------+ +---------------------+-------------------------------+
| BGP Large Community | Description | | BGP Large Community | Description |
+---------------------+-------------------------------+ +---------------------+-------------------------------+
| 64497:2:2 | Route learned in Africa | | 64497:2:2 | Route learned in Africa |
| 64497:2:9 | Route learned in Oceania | | 64497:2:9 | Route learned in Oceania |
| 64497:2:145 | Route learned in Western Asia | | 64497:2:145 | Route learned in Western Asia |
| 64497:2:150 | Route learned in Europe | | 64497:2:150 | Route learned in Europe |
+---------------------+-------------------------------+ +---------------------+-------------------------------+
Example documentation for AS 64497 using Informational Communities Example documentation for Informational Communities deployed by AS
describing the origin of routes using numeric identifiers provided by 64497 to describe the location where a route was imported using M.49
the UN Statistics Division. numeric codes published by the United Nations Statistics Division.
Table 2: Information: Regions Table 3: Information: UNSD Regions
3.2. Relation 3.2. Relation Function
AS 64497 could assign a value of 3 to the first Local Data field to An AS, AS 64497 in this example, could assign a value of 3 to the
designate that the second Local Data field contains an identifier Function field to designate the content of the Parameter field as a
showing the relation with the EBGP neighbor from whom the route was number indicating whether the route originated inside its own network
received. 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 | | BGP Large Community | Description |
+---------------------+-----------------------------------------+ +---------------------+---------------------------------------+
| 64497:3:1 | Route learned from a customer | | 64497:3:1 | Route originated internally |
| 64497:3:2 | Route learned from a peering partner | | 64497:3:2 | Route learned from a customer |
| 64497:3:3 | Route learned from an upstream provider | | 64497:3:3 | Route learned from a peering partner |
+---------------------+-----------------------------------------+ | 64497:3:4 | Route learned from a transit provider |
+---------------------+---------------------------------------+
Example documentation for AS 64497 using Informational Communities Example documentation for Informational Communities deployed by AS
describing the relation with the ASN from which the route was 64497 to describe the relation to the ASN from which the route was
received. learned.
Table 3: Information: Relation Table 4: Information: Relation
3.3. Combining Informational Communities 3.3. Combining Informational Communities
Multiple Informational Communities can be tagged on a route, for A route may be labeled with multiple Informational Communities. For
example: a route learned in the Netherlands from a customer can example, a route learned in the Netherlands from a customer might be
contain both 64497:1:528 and 64497:2:150 and 64497:3:1. labeled with communities 64497:1:528, 64497:2:150 and 64497:3:2 at
the same time.
4. Examples of Action Communities 4. Examples of Action Communities
4.1. Selective NO_EXPORT 4.1. Selective NO_EXPORT
As part of the commercial agreement between AS 64497 and AS 64498, AS As part of an agreement, often a commercial transit agreement,
64497 might offer AS 64498 certain BGP Traffic Engineering features between AS 64497 and AS 64498, AS 64497 might expose BGP traffic
such as selectively not export routes learned from 64498 to certain engineering functions to AS 64498. One such BGP traffic engineering
EBGP neighbors of AS 64497. 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. Peer ASN Based Selective NO_EXPORT 4.1.1. ASN Based Selective NO_EXPORT
AS 64497 might assign function identifier 4 to allow preventing AS 64497 could assign a value of 4 to the Function field to designate
propagation of routes to the ASN listed in the second Local Data the content of the Parameter field as a neighboring ASN to which a
field. route should not be propagated.
+---------------------+---------------------------------+ +---------------------+---------------------------------+
| BGP Large Community | Description | | BGP Large Community | Description |
+---------------------+---------------------------------+ +---------------------+---------------------------------+
| 64497:4:2914 | Do not export route to AS 2914 | | 64497:4:64498 | Do not export route to AS 64498 |
| 64497:4:7018 | Do not export route to AS 7018 | | 64497:4:64499 | Do not export route to AS 64499 |
| 64497:4:65551 | Do not export route to AS 65551 | | 64497:4:65551 | Do not export route to AS 65551 |
+---------------------+---------------------------------+ +---------------------+---------------------------------+
Example documentation for AS 64497 offering Action Communities to Example documentation for Action Communities deployed by AS 64497 to
limit propagation of routes based on the Peer ASN described in the expose a BGP traffic engineering function which selectively prevents
third field. the propagation of routes to the neighboring ASN specified in the
Parameter field.
Table 4: Action: Peer ASN NO_EXPORT Table 5: Action: ASN NO_EXPORT
4.1.2. Location Based Selective NO_EXPORT 4.1.2. Location Based Selective NO_EXPORT
AS 64497 might assign function identifier 5 to allow its customers to AS 64497 could assign a value of 5 to the Function field to designate
request selectively not exporting routes on EBGP sessions within a the content of the Parameter field as an ISO 3166-1 numeric country
certain geographical area. This example follows the ISO 3166-1 identifier within which a labeled route is not propagated to EBGP
numeric encoding. 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.
+------------------+------------------------------------------------+ +-----------------+-------------------------------------------------+
| BGP Large | Description | | BGP Large | Description |
| Community | | | Community | |
+------------------+------------------------------------------------+ +-----------------+-------------------------------------------------+
| 64497:5:528 | Do not export to EBGP neighbors in the | | 64497:5:528 | Do not export to EBGP neighbors in the |
| | Netherlands | | | Netherlands |
| 64497:5:392 | Do not export to EBGP neighbors in Japan | | 64497:5:392 | Do not export to EBGP neighbors in Japan |
| 64497:5:840 | Do not export to EBGP neighbors in United | | 64497:5:840 | Do not export to EBGP neighbors in the United |
| | States of America | | | States of America |
+------------------+------------------------------------------------+ +-----------------+-------------------------------------------------+
Example documentation for AS 64497 offering Action Communities to Example documentation for Action Communities deployed by AS 64497 to
trigger NO_EXPORT on routes only when propagating the route to a expose a BGP traffic engineering function which selectively prevents
certain geographical region. the propagation of routes to all EBGP neighbors in the geographical
region specified in the Parameter field.
Table 5: Action: NO_EXPORT in Region Table 6: Action: NO_EXPORT in Region
4.2. Selective AS_PATH Prepending 4.2. Selective AS_PATH Prepending
As part of the commercial agreement between AS 64497 and AS 64498, AS As part of an agreement between AS 64497 and AS 64498, AS 64497 might
64497 might offer AS 64498 certain BGP Traffic Engineering features expose BGP traffic engineering functions to AS 64498. One such BGP
such as selectively prepending the AS_PATH with 64497's ASN to traffic engineering function could be selective prepending of the
certain EBGP neighbors of AS 64497. AS_PATH with AS 64497 to certain certain EBGP neighbors of AS 64497.
4.2.1. Peer ASN Based Selective AS_PATH Prepending 4.2.1. ASN Based Selective AS_PATH Prepending
AS 64497 might assign function identifier 6 to allow prepending the AS 64497 could assign a value of 6 to the Function field to designate
AS_PATH on propagation of routes to the ASN listed in the second the content of the Parameter field as a neighboring ASN to which
Local Data field. 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.
+---------------------+------------------------------------------+ +---------------------+------------------------------------------+
| BGP Large Community | Description | | BGP Large Community | Description |
+---------------------+------------------------------------------+ +---------------------+------------------------------------------+
| 64497:6:2914 | Prepend 64497 once on export to AS 2914 | | 64497:6:64498 | Prepend 64497 once on export to AS 64498 |
| 64497:6:7018 | Prepend 64497 once on export to AS 7018 | | 64497:6:64499 | Prepend 64497 once on export to AS 64499 |
| 64497:6:65551 | Prepend 64497 once on export to AS 65551 | | 64497:6:65551 | Prepend 64497 once on export to AS 65551 |
+---------------------+------------------------------------------+ +---------------------+------------------------------------------+
Example documentation for AS 64497 offering Action Communities to Example documentation for Action Communities deployed by AS 64497 to
trigger prepending of the AS_PATH only when propagating the route to expose a BGP traffic engineering function which selectively prepends
a certain Peer ASN. the AS_PATH with AS 64497 when propagating the route to the specified
EBGP neighbor.
Table 6: Action: Prepend to Peer ASN Table 7: Action: Prepend to ASN
4.2.2. Location Based Selective AS_PATH Prepending 4.2.2. Location Based Selective AS_PATH Prepending
AS 64497 might assign function identifier 7 to allow prepending of AS 64497 could assign a value of 7 to the Function field to designate
the AS_PATH on propagation of routes to on any EBGP neighbor's the content of the Parameter field as an ISO 3166-1 numeric country
interconnection in the geographical entity listed in the second Local identifier to which the prepending of the AS_PATH with AS 64497 is
Data field. This example follows the ISO 3166-1 numeric regions requested upon propagation of the route to all EBGP neighbors in that
codes in the Local Data 2 field. region.
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
| BGP Large | Description | | BGP Large | Description |
| Community | | | Community | |
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
| 64497:7:528 | Prepend once to EBGP neighbors in the | | 64497:7:528 | Prepend once to EBGP neighbors in the |
| | Netherlands | | | Netherlands |
| 64497:7:392 | Prepend once to EBGP neighbors in Japan | | 64497:7:392 | Prepend once to EBGP neighbors in Japan |
| 64497:7:840 | Prepend once to EBGP neighbors in United | | 64497:7:840 | Prepend once to EBGP neighbors in United |
| | States of America | | | States of America |
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
Example documentation for AS 64497 offering Action Communities to Example documentation for Action Communities deployed by AS 64497 to
trigger prepending of the AS_PATH only when propagating the route to expose a BGP traffic engineering function which selectively prepends
a certain geographical region. the AS_PATH with AS 64497 when propagating the route to all EBGP
neighbors in the geographical region specified in the Parameter
field.
Table 7: Action: Prepend in Region Table 8: Action: Prepend in Region
4.3. Location based manipulation of LOCAL_PREF 4.3. Manipulation of the LOCAL_PREF attribute
In some cases, it can be desirable for an autonomous system to allow As part of an agreement between AS 64497 and AS 64498, AS 64497 might
adjacent Autonomous Systems to directly influence the degree of expose BGP traffic engineering functions to AS 64498. One such BGP
preference associated with a route, usually expressed within the traffic engineering function might allow AS 64498 to manipulate the
LOCAL_PREF attribute. 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.
Furthermore, in the case of large networks spanning significant The LOCAL_PREF value of routes are locally significant within each
geography, it is often also useful to be able to extend this Autonomous System and therefore are impossible to list in this
capability and scope its effect to a geographic region. This is a document. Instead, the typical LOCAL_PREF values could be classified
more powerful mechanism than AS_PATH prepending, but since degree of as a hierarchy and a BGP Large Community function exposed allowing an
preference determines BGP route selection and thus onward EBGP neighbor to affect the LOCAL_PREF value within the specified GA.
advertisement, it can also be self-limiting in its scope. 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.
Since the LOCAL_PREF attribute which influences degree of preference +----------+--------------------------------------------------------+
is locally significant within each autonomous system, it is not | Function | Preference Class |
usually practical or useful to compare LOCAL_PREF attribute values +----------+--------------------------------------------------------+
between autonomous systems. Instead it can be useful to classify the | 8 | Normal customer route. |
major types of route likely to exist within an autonomous system's | 9 | Backup customer route. |
routing hierarchy and provide an ability to set one's route to that | 10 | Peering route. |
preference: | 11 | Upstream transit route. |
| 12 | Fallback route, to be installed if no other path is |
| | available. |
+----------+--------------------------------------------------------+
o A qualified customer route. Usually the highest preference. Table 9: Action: Preference Function Identifiers
o A peer, or network-share, route. A co-operating network provider 4.3.1. Global Manipulation of LOCAL_PREF
engaged in a partnership for customer coverage ("peering").
o A last resort, or backup route. 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.
It is entirely possible that some providers may have more classes of +---------------------+---------------------------------------------+
route preference but it is possible to codify both the route | BGP Large Community | Description |
preference class and the regional scope within the Local Data fields +---------------------+---------------------------------------------+
of the Large Community attribute. | 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 |
+---------------------+---------------------------------------------+
For example, AS64497 might establish the following function Example documentation for Action Communities deployed by AS 64497 to
identifiers to set route preference class, which could allow pairing expose a BGP traffic engineering function which allows a BGP neighbor
with a location or peer-based operand to determine scope. to globally manipulate the LOCAL_PREF attribute for the route within
AS 64497.
+----------+-----------------------------------------------+ Table 10: Action: Global LOCAL_PREF Manipulation
| Function | Preference Class |
+----------+-----------------------------------------------+
| 10 | Qualified customer route. Highest preference. |
| 15 | Peering partner. Median preference. |
| 19 | Route of last resort. Lowest preference. |
+----------+-----------------------------------------------+
Table 8: Action: Preference Function Identifiers 4.3.2. Location Based Manipulation of LOCAL_PREF
Once established, these route preference setting functions can be AS 64497 could place one of the previously defined Preference
linked with a scoping operand such as per-peer or per-location based Function Identifiers in the Function field and use an ISO 3166-1
identifiers in order to provide AS64497's customers with a numeric country identifier in the Parameter field to designate the
comprehensive and rich toolset to influence route preference. 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 | | BGP Large | Description |
| Community | | | Community | |
+--------------------+----------------------------------------------+ +--------------+----------------------------------------------------+
| 64497:15:528 | Set as peer route in Netherlands | | 64497:9:528 | Assign LOCAL_PREF for a customer backup route on |
| 64497:19:840 | Set as backup route in United States of | | | BGP speakers in the Netherlands |
| | America | | 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 |
+--------------+----------------------------------------------------+
Table 9: Action: Regional Preference Communities 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.
Since the degree of preference influences BGP best path selection Table 11: Action: Regional LOCAL_PREF Manipulation
(which in turn influences onward route propagation) Operators should
take special care with a traffic engineering tool such as location 4.3.3. Note of Caution for LOCAL_PREF Functions
based local preference influence (BGP Wedgies [RFC4264]).
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 5. Security Considerations
Network operators should note the recommendations in Section 11 of Network operators should note the recommendations in Section 11 of
BGP Operations and Security [RFC7454]. BGP Operations and Security [RFC7454].
6. IANA Considerations 6. IANA Considerations
None. None.
7. Acknowledgements 7. Acknowledgments
The authors would like to gratefully acknowledge the insightful The authors would like to gratefully acknowledge the insightful
comments, contributions, critique and support from John Heasley, Adam comments, contributions, critique and support from Adam Chappell,
Chappell, Jonathan Stewart, and Will Hargrave. Jonathan Stewart, and Will Hargrave.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
<http://www.rfc-editor.org/info/rfc1997>. <http://www.rfc-editor.org/info/rfc1997>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4264] Griffin, T. and G. Huston, "BGP Wedgies", RFC 4264, [RFC4264] Griffin, T. and G. Huston, "BGP Wedgies", RFC 4264,
DOI 10.17487/RFC4264, November 2005, DOI 10.17487/RFC4264, November 2005,
<http://www.rfc-editor.org/info/rfc4264>. <http://www.rfc-editor.org/info/rfc4264>.
[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
February 2015, <http://www.rfc-editor.org/info/rfc7454>. February 2015, <http://www.rfc-editor.org/info/rfc7454>.
[RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas, [RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas,
I., and N. Hilliard, "BGP Large Communities Attribute", I., and N. Hilliard, "BGP Large Communities Attribute",
RFC 8092, DOI 10.17487/RFC8092, February 2017, RFC 8092, DOI 10.17487/RFC8092, February 2017,
<http://www.rfc-editor.org/info/rfc8092>. <http://www.rfc-editor.org/info/rfc8092>.
8.2. URIs 8.2. URIs
[1] http://nanog.net [1] http://nanog.net
[2] http://nlnog.net [2] http://nlnog.net
[3] http://unstats.un.org/unsd/methods/m49/m49regin.htm [3] https://www.iso.org/iso-3166-country-codes.html
[4] https://unstats.un.org/unsd/methodology/m49/
Authors' Addresses Authors' Addresses
Job Snijders Job Snijders
NTT Communications NTT Communications
Theodorus Majofskistraat 100 Theodorus Majofskistraat 100
Amsterdam 1065 SZ Amsterdam 1065 SZ
The Netherlands The Netherlands
Email: job@ntt.net Email: job@ntt.net
skipping to change at page 11, line 31 skipping to change at page 13, line 4
Authors' Addresses Authors' Addresses
Job Snijders Job Snijders
NTT Communications NTT Communications
Theodorus Majofskistraat 100 Theodorus Majofskistraat 100
Amsterdam 1065 SZ Amsterdam 1065 SZ
The Netherlands The Netherlands
Email: job@ntt.net Email: job@ntt.net
John Heasley John Heasley
NTT Communications NTT Communications
12160 NW Coleman Drive 1111 NW 53rd Drive
Portland, OR 97229 Portland, OR 97210
United States of America United States of America
Email: heas@shrubbery.net Email: heas@shrubbery.net
Martijn Schmidt Martijn Schmidt
i3D.net i3D.net
Rivium 1e Straat 1 Rivium 1e Straat 1
Capelle aan den IJssel 2909 LE Capelle aan den IJssel 2909 LE
NL NL
 End of changes. 78 change blocks. 
246 lines changed or deleted 306 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/