Large BGP CommunitiesCisco170 West Tasman DriveSan JoseCA95054USAjheitz@cisco.comNTT CommunicationsTheodorus Majofskistraat 1001065 SZAmsterdamThe Netherlandsjob@ntt.netArrcus, Inckeyur@arrcus.comEquinixLondonUKibagdona.ietf@gmail.comNokia600 March RoadOttawaOntario K2K 2E6Canadaadam.1.simpson@nokia.comINEX4027 Kingswood RoadDublin24IEnick@inex.ie
Routing
IDRBGPcommunities
This document describes the Large BGP Communities attribute, an
extension to BGP-4. This attribute provides a mechanism to
signal opaque information within separate namespaces to aid in
routing management. The attribute is suitable for use in four-octet
ASNs.
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
.
BGP implementations typically support a routing policy language
to control the distribution of routing information. Network
operators attach BGP communities to routes to identify intrinsic
properties of these routes. These properties may include
information such as the route origin location, or specification
of a routing policy action to be taken, or one that has been
taken, and may apply to an individual route or to a group of
routes. Because BGP communities are optional transitive BGP
attributes, BGP communities may be acted upon or otherwise used
by routing policies in other Autonomous Systems (ASes) on the
Internet.
BGP Communities attributes are
four-octet values split into two two-octet words. The most
significant word is interpreted as an Autonomous System Number
(ASN) and the least significant word is a locally defined value
whose meaning is assigned by the operator of the Autonomous
System in the most significant word.
Since the adoption of four-octet ASNs , the
BGP Communities attribute can no longer accommodate the above
encoding, as a two-octet word cannot fit a four-octet ASN. The BGP
Extended Communities attribute is also
unsuitable, as the protocol limit of six octets cannot
accommodate both a four-octet Global Administrator value and a
four-octet Local Administrator value, which precludes the common
operational practice of encoding a target ASN in the Local
Administrator field.
To address these shortcomings, this document defines a Large
BGP Communities attribute encoded as one or more twelve-octet values,
each consisting of a four-octet ASN and two four-octet operator-defined
values, each of which can be used to denote properties or actions
significant to that ASN.
This document creates the Large BGP Communities attribute
as an optional transitive path attribute of variable length. All
routes with the Large BGP Communities attribute belong to the
community specified in the attribute.
The attribute consists of one or more twelve-octet values. Each
twelve-octet Large BGP Communities value represents three four-octet values, as
follows:
A four-octet namespace identifier. This SHOULD be an Autonomous
System Number.
A four-octet operator-defined value.A four-octet operator-defined value.
The Global Administrator field is intended to allow different
Autonomous Systems to define Large BGP Communities without
collision. Implementations MUST allow the operator to specify any
value for the Global Administrator field.
There is no significance to the order in which Large BGP
Communities are encoded in the BGP path attribute payload. A BGP
speaker can transmit them in any order.
Duplicate Large BGP Communities SHOULD NOT be transmitted. A
receiving speaker SHOULD silently remove duplicate Large
BGP Communities from a BGP UPDATE message.
If a range of routes is aggregated, then the resulting aggregate
should have a Large BGP Communities attribute which contains all
of the Large BGP Communities attributes from all of the
aggregated routes.
Large BGP Communities MUST be represented as three separate
unsigned integers in decimal notation, without leading zeros, in
the following order: Global Administrator, Local Data 1, Local Data
2. Numbers MUST not be omitted, even when zero. For example:
64496:4294967295:2 or 64496:0:0 or (64496, 111, 222).
The following Global Administrator values are reserved: 0 (the
first ASN) , 65535 (UINT16_MAX) and
4294967295 (the last ASN) . Operators
SHOULD NOT use these Global Administrator values.
Although this document does not define any Special-Use Large BGP
Communities, the Global Administrator values specified above could
be used if there is a future need for them.
The error handling of Large BGP Communities is as follows:
A Large BGP Communities attribute SHALL be considered
malformed if its length is not a non-zero multiple of 12.
A BGP UPDATE message with a malformed Large BGP Communities
attribute SHALL be handled using the approach of "treat-as-withdraw"
as described in section 2.
The Large BGP Communities Global Administrator field may contain
any value, and a Large BGP Communities attribute MUST NOT be
considered malformed if the Global Administrator field contains
an unallocated, unassigned or reserved ASN or is set to one of
the reserved Large BGP Community values defined in .
This extension to BGP has similar security implications as BGP
Communities .
This document does not change any underlying security issues
associated with any other BGP Communities mechanism. Specifically,
an AS relying on the Large BGP Communities attribute carried in BGP
must have trust in every other AS in the path, as any intermediate
Autonomous System in the path may have added, deleted or altered
the Large BGP Communities attribute. Specifying the mechanism to
provide such trust is beyond the scope of this document.
Network administrators should note the recommendations in
Section 11 of BGP Operations and Security .
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of
this Internet-Draft, and is based on a proposal described in
. The description of implementations in this
section is intended to assist the IETF in its decision processes in
progressing drafts to RFCs. Please note that the listing of any
individual implementation here does not imply endorsement by the
IETF. Furthermore, no effort has been spent to verify the
information presented here that was supplied by IETF contributors.
This is not intended as, and must not be construed to be, a catalog
of available implementations or their features. Readers are advised
to note that other implementations may exist.
As of today these vendors have produced an implementation of Large
BGP Communities:
Cisco IOS XRExaBGPGoBGPBIRDOpenBGPDpmacct
The latest implementation news is tracked at
http://largebgpcommunities.net/.
IANA has made an Early Allocation of the value 32 (LARGE_COMMUNITY)
in the "BGP Path Attributes" registry under the "Border Gateway
Protocol (BGP) Parameters" group and is now asked to make that
Permanent.
The authors would like to thank Ruediger Volk, Russ White, Acee
Lindem, Shyam Sethuram, Jared Mauch, Joel M. Halpern, Jeffrey Haas,
John Heasley, Gunter van de Velde, Marco Marzetti, Eduardo Ascenco
Reis, Mark Schouten, Paul Hoogsteder, Martijn Schmidt, Greg
Hankins, Bertrand Duvivier, Barry O'Donovan, Grzegorz Janoszka,
Linda Dunbar, Marco Davids, Gaurab Raj Upadhaya, Jeff Tantsura,
Teun Vink, Adam Davenport, Theodore Baschak, Pier Carlo Chiodi,
Nabeel Cocker, Ian Dickinson, Jan Baggen, Duncan Lockwood, David
Farmer, Randy Bush, Wim Henderickx, Stefan Plug, Kay Rechthien, Rob
Shakir, Warren Kumari, Gert Doering, Thomas King, Mikael
Abrahamsson, Wesley Steehouwer, Sander Steffann, Brad Dreisbach,
Martin Millnert, Christopher Morrow, Jay Borkenhagen, Arnold
Nipper, Joe Provo, Niels Bakker, Bill Fenner, Tom Daly, Ben
Maddison, Alexander Azimov, Brian Dickson, Peter van Dijk, Julian
Seifert, Tom Petch, Tom Scholl, Arjen Zonneveld, Remco van Mook,
Adam Chappell, Jussi Peltola, Kristian Larsson, Markus Hauschild,
Richard Steenbergen, and David Freedman for their support,
insightful review and comments.