7
Network Working Group R. Chandra
8
Request for Comments: 1997 P. Traina
9
Category: Standards Track cisco Systems
14
BGP Communities Attribute
18
This document specifies an Internet standards track protocol for the
19
Internet community, and requests discussion and suggestions for
20
improvements. Please refer to the current edition of the "Internet
21
Official Protocol Standards" (STD 1) for the standardization state
22
and status of this protocol. Distribution of this memo is unlimited.
26
Border Gateway Protocol [1] is an inter-autonomous system routing
27
protocol designed for TCP/IP internets.
29
This document describes an extension to BGP which may be used to pass
30
additional information to both neighboring and remote BGP peers.
32
The intention of the proposed technique is to aid in policy
33
administration and reduce the management complexity of maintaining
38
BGP supports transit policies via controlled distribution of routing
39
information. Mechanisms for this are described in [1] and have been
40
successfully used by transit service providers. However, control
41
over the distribution of routing information is presently based on
42
either IP address prefixes or on the value of the AS_PATH attribute
45
To facilitate and simplify the control of routing information this
46
document suggests a grouping of destinations so that the routing
47
decision can also be based on the identity of a group. Such a scheme
48
is expected to significantly simplify a BGP speaker's configuration
49
that controls distribution of routing information.
58
Chandra, et. al. Standards Track [Page 1]
60
RFC 1997 BGP Communities Attribute August 1996
66
A community is a group of destinations which share some common
69
Each autonomous system administrator may define which communities
70
a destination belongs to. By default, all destinations belong to
71
the general Internet community.
75
A property such as "NSFNET sponsored/AUP" could be added to all AUP
76
compliant destinations advertised into the NSFNET. NSFNET operators
77
could define a policy that would advertise all routes, tagged or not,
78
to directly connected AUP compliant customers and only tagged routes
79
to commercial or external sites. This would insure that at least one
80
side of a given connection is AUP compliant as a way of enforcing NSF
81
transit policy guidelines.
83
In this example, we have just eliminated the primary motivation for a
84
complex policy routing database that is used to generate huge prefix
85
and AS path based filter rules. We have also eliminated the delays
86
caused by the out-of-band maintenance of this database (mailing in
87
NACRs, weekly configuration runs, etc.)
89
A second example comes from experience with aggregation. It is often
90
useful to advertise both an aggregate prefix and the component more-
91
specific prefixes that were used to form the aggregate to optimize
92
"next hop" routing. These component prefixes are only useful to the
93
neighboring BGP peer or perhaps the autonomous system of the
94
neighboring BGP peer, so it is desirable to filter this information.
95
By specifying a community value that the neighboring peer or peers
96
will match and filter on, these more specific routes may be
97
advertised with the assurance that they will not propagate beyond
100
COMMUNITIES attribute
102
This document creates the COMMUNITIES path attribute is an optional
103
transitive attribute of variable length. The attribute consists of a
104
set of four octet values, each of which specify a community. All
105
routes with this attribute belong to the communities listed in the
108
The COMMUNITIES attribute has Type Code 8.
114
Chandra, et. al. Standards Track [Page 2]
116
RFC 1997 BGP Communities Attribute August 1996
119
Communities are treated as 32 bit values, however for administrative
120
assignment, the following presumptions may be made:
122
The community attribute values ranging from 0x0000000 through
123
0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are hereby reserved.
125
The rest of the community attribute values shall be encoded using an
126
autonomous system number in the first two octets. The semantics of
127
the final two octets may be defined by the autonomous system (e.g. AS
128
690 may define research, educational and commercial community values
129
that may be used for policy routing as defined by the operators of
130
that AS using community attribute values 0x02B20000 through
133
Well-known Communities
135
The following communities have global significance and their
136
operations shall be implemented in any community-attribute-aware BGP
139
NO_EXPORT (0xFFFFFF01)
140
All routes received carrying a communities attribute
141
containing this value MUST NOT be advertised outside a BGP
142
confederation boundary (a stand-alone autonomous system that
143
is not part of a confederation should be considered a
144
confederation itself).
145
NO_ADVERTISE (0xFFFFFF02)
146
All routes received carrying a communities attribute
147
containing this value MUST NOT be advertised to other BGP
149
NO_EXPORT_SUBCONFED (0xFFFFFF03)
150
All routes received carrying a communities attribute
151
containing this value MUST NOT be advertised to external BGP
152
peers (this includes peers in other members autonomous
153
systems inside a BGP confederation).
157
A BGP speaker may use this attribute to control which routing
158
information it accepts, prefers or distributes to other neighbors.
160
A BGP speaker receiving a route that does not have the COMMUNITIES
161
path attribute may append this attribute to the route when
162
propagating it to its peers.
164
A BGP speaker receiving a route with the COMMUNITIES path attribute
165
may modify this attribute according to the local policy.
170
Chandra, et. al. Standards Track [Page 3]
172
RFC 1997 BGP Communities Attribute August 1996
177
If a range of routes is to be aggregated and the resultant aggregates
178
attribute section does not carry the ATOMIC_AGGREGATE attribute, then
179
the resulting aggregate should have a COMMUNITIES path attribute
180
which contains all communities from all of the aggregated routes.
184
The COMMUNITIES path attribute may be used with BGP version 2 and all
185
subsequent versions of BGP unless specifically noted otherwise.
187
Security Considerations
189
Security issues are not discussed in this memo.
193
We'd like to thank Vince Fuller, Sean Doran, and Andrew Partan for
194
bringing to our attention the problems that we believe the BGP
195
communities attribute will help solve. We'd also like to thank Yakov
196
Rekhter his review of this document as well as his constructive and
209
Ravishanker Chandrasekeran
215
EMail: rchandra@cisco.com
219
EMail: tli@skat.usc.edu
226
Chandra, et. al. Standards Track [Page 4]
228
RFC 1997 BGP Communities Attribute August 1996
234
Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
238
Traina, P., "Autonomous System Confederations for BGP", June 1996.
282
Chandra, et. al. Standards Track [Page 5]
added
removed
dev/RFC/rfc1997.txt
