Use of BGP Large CommunitiesNTT CommunicationsTheodorus Majofskistraat 1001065 SZAmsterdamThe Netherlandsjob@ntt.netNTT Communications1111 NW 53rd DrivePortlandOR97210United States of Americaheas@shrubbery.neti3D.netRivium 1e Straat 12909 LECapelle aan den IJsselNLmartijnschmidt@i3d.net
Routing
Global Routing OperationslargeBGPcommunities
This document presents examples and inspiration for operator's application of BGP Large Communities.
Based on operational experience with BGP Communties, 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.
BGP Large Communities provide a mechanism to signal opaque information between Autonomous Systems (ASs).
In very much the same way that provides a concrete real-world application for communities, 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 and NLNOG.
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 8092this documentGlobal AdministratorASNLocal Data Part 1FunctionLocal Data Part 2ParameterA mapping table on the use of fields in BGP Large Communities between and this document.
In contemporary deployments of both BGP Communities and BGP Large Communities, the function of a community can be divided into two categories:
Informational CommunitiesAction Communities
Throughout the document a topology of four ASs is used to illustrate the use of communities in the following configuration:
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 and action, that they support or are visible in BGP RIBs.
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 AS could benefit from receiving these communities.
Action Communities are added as a label 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, 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 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 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 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.
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.
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.
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.
BGP Large CommunityDescription64497:1:528Route learned in the Netherlands64497:1:392Route learned in Japan64497:1:840Route 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.
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.
BGP Large CommunityDescription64497:2:2Route learned in Africa64497:2:9Route learned in Oceania64497:2:145Route learned in Western Asia64497:2:150Route 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.
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 CommunityDescription64497:3:1Route originated internally64497:3:2Route learned from a customer64497:3:3Route learned from a peering partner64497:3:4Route 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.
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.
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.
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 CommunityDescription64497:4:64498Do not export route to AS 6449864497:4:64499Do not export route to AS 6449964497:4:65551Do 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.
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 CommunityDescription64497:5:528Do not export to EBGP neighbors in the Netherlands64497:5:392Do not export to EBGP neighbors in Japan64497:5:840Do 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.
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.
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 two, three or more prepends of AS 64497.
BGP Large CommunityDescription64497:6:64498Prepend 64497 once on export to AS 6449864497:6:64499Prepend 64497 once on export to AS 6449964497:6:65551Prepend 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.
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 CommunityDescription64497:7:528Prepend once to EBGP neighbors in the Netherlands64497:7:392Prepend once to EBGP neighbors in Japan64497:7:840Prepend 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.
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 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 and a BGP Large Community function 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 could be used in the Function field of a BGP Large Community.
FunctionPreference Class8Normal customer route9Backup customer route10Peering route11Upstream transit route12Fallback route, to be installed if no other path is available
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 CommunityDescription64497:9:0Assign LOCAL_PREF for a customer backup route64497:10:0Assign LOCAL_PREF for a peering route64497:12:0Assign 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.
AS 64497 could place one of the previously defined Preference Function Identifiers in the Function field and use an 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 CommunityDescription64497:9:3Assign the LOCAL_PREF value equivalent to a customer backup class route on BGP routers in the North America region64497:10:5Assign the LOCAL_PREF value equivalent to a peering class route on BGP routers in the South America region64497:12:142Assign the LOCAL_PREF value equivalent to a fallback class route on BGP routers in the Asia region
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.
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 decisions are described as "BGP Wedgies" in .
Route Servers 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 .
One widely-used mechanism is a route server specific adaption of "ASN Based Selective NO_EXPORT".
An example BGP Large Communities policy which enables client-controlled prefix distribution for a route server operating as AS 64497, is outlined as follows:
BGP Large CommunityDescription64497:13:peer-asExplicitly prevent announcement of route to peer-as64497:14:peer-asExplicitly announce route to peer-as64497:13:0Do not announce route to any peers by default64497:14:0Announce route to all peers by default
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.
In this case, they would label all their outbound routes to the route server with 64497:14:0 (to announce to all clients by default) and 64497:13:64510 (to prevent announcement to AS 64510).
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 (blocking all distribution by default) and 64497:14:64505, 64497:14:64506 to instruct the route server to force announcement to those two ASNs.
Operators should note the recommendations in Section 11 of BGP Operations and Security and handle BGP Large Communities with their ASN in the Global Administrator field similarly.
In particular and in the same respect as BGP Communities , operators should be congnizant 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 and receive routes with informational communities to or from these other neighbors and it is beneficial to all to permit this.
None.
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.