Skip to main content

BGP Communities Attribute
draft-ietf-idr-communities-00

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 1997.
Authors Tony Li , Ravi Chandra , Paul S. Traina
Last updated 2014-02-13 (Latest revision 1996-04-10)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 1997 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-idr-communities-00
Internet Engineering Task Force                      Ravi Chandra
INTERNET DRAFT                                       Paul Traina
<draft-ietf-idr-communities-00.txt>                  cisco Systems
                                                     Tony Li
                                                     April 10, 1996

                       BGP communities attribute

                          Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

   This document is an Internet Draft. Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups. Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time. It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress".

   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the current status of this or any other
   Internet Draft.

Abstract

   Border Gateway Protocol [1] is an inter-autonomous system routing
   protocol designed for TCP/IP internets.

   This document describes an extension to BGP which may be used to pass
   additional information to both neighboring and remote BGP peers.

   The intention of the proposed technique is to aid in policy
   administration and reduce the management complexity of maintaining
   the Internet.

Expiration Date November 1996                                   [Page 1]
INTERNET DRAFT                                            April 10, 1996

Introduction

   BGP supports transit policies via controlled distribution of routing
   information.  Mechanisms for this are described in [1] and have been
   successfully used by transit service providers.  However, control
   over the distribution of routing information is presently based on
   either IP address prefixes or on the value of the AS_PATH attribute
   (or part of it).

   To facilitate and simplify the control of routing information this
   document suggests a grouping of destinations so that the routing
   decision can also be based on the identity of a group.  Such a scheme
   is expected to significantly simplify a BGP speaker's configuration
   that controls distribution of routing information.

Terms and Definitions

   Community
      A community is a group of destinations which share some common
      property.

      Each autonomous system administrator may define which communities
      a destination belongs to.  By default, all destinations belong to
      the general Internet community.

Examples

   A property such as "NSFNET sponsored/AUP" could be added to all AUP
   compliant destinations advertised into the NSFNET.  NSFNET operators
   could define a policy that would advertise all routes, tagged or not,
   to directly connected AUP compliant customers and only tagged routes
   to commercial or external sites. This would insure that at least one
   side of a given connection is AUP compliant as a way of enforcing NSF
   transit policy guidelines.

   In this example, we have just eliminated the primary motivation for a
   complex policy routing database that is used to generate huge prefix
   and AS path based filter rules.  We have also eliminated the delays
   caused by the out-of-band maintenance of this database (mailing in
   NACRs, weekly configuration runs, etc.)

   A second example comes from experience with aggregation.  It is often
   useful to advertise both an aggregate prefix and the component more-
   specific prefixes that were used to form the aggregate to optimize
   "next hop" routing.  These component prefixes are only useful to the
   neighboring BGP peer or perhaps the autonomous system of the

Expiration Date November 1996                                   [Page 2]
INTERNET DRAFT                                            April 10, 1996

   neighboring BGP peer, so it is desirable to filter this information.
   By specifying a community value that the neighboring peer or peers
   will match and filter on, these more specific routes may be
   advertised with the assurance that they will not propagate beyond
   their desired scope.

COMMUNITIES attribute

   This document creates the COMMUNITIES path attribute is an optional
   transitive attribute of variable length.  The attribute consists of a
   set of four octet values, each of which specify a community.  All
   routes with this attribute belong to the communities listed in the
   attribute.

   The COMMUNITIES attribute has Type Code 8.

   Communities are treated as 32 bit values,  however for administrative
   assignment,  the following presumptions may be made:

   The community attribute values ranging from 0x0000000 through
   0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are hereby reserved.

   The rest of the community attribute values shall be encoded using an
   autonomous system number in the first two octets.  The semantics of
   the final two octets may be defined by the autonomous system (e.g. AS
   690 may define research, educational and commercial community values
   that may be used for policy routing as defined by the operators of
   that AS using community attribute values 0x02B20000 through
   0x02B2FFFF).

Well-known Communities

   The following communities have global significance and their
   operations shall be implemented in any community-attribute-aware BGP
   speaker.
      NO_EXPORT (0xFFFFFF01)
         All routes received carrying a communities attribute containing
         this value MUST NOT be advertised outside a BGP confederation
         boundary (a stand-alone autonomous system that is not part of a
         confederation should be considered a confederation itself).
      NO_ADVERTISE (0xFFFFFF02)
         All routes received carrying a communities attribute containing
         this value MUST NOT be advertised to other BGP peers.
      NO_EXPORT_SUBCONFED (0xFFFFFF03)
         All routes received carrying a communities attribute containing
         this value MUST NOT be advertised to external BGP peers (this

Expiration Date November 1996                                   [Page 3]
INTERNET DRAFT                                            April 10, 1996

         includes peers in other members autonomous systems inside a BGP
         confederation).

Operation

   A BGP speaker may use this attribute to control which routing
   information it accepts, prefers or distributes to other neighbors.

   A BGP speaker receiving a route that does not have the COMMUNITIES
   path attribute may append this attribute to the route when
   propagating it to its peers.

   A BGP speaker receiving a route with the COMMUNITIES path attribute
   may modify this attribute according to the local policy.

Aggregation

   If a range of routes is to be aggregated and the resultant aggregates
   attribute section does not carry the ATOMIC_AGGREGATE attribute, then
   the resulting aggregate should have a COMMUNITIES path attribute
   which contains all communities from all of the aggregated routes.

Applicability

   The COMMUNITIES path attribute may be used with BGP version 2 and all
   subsequent versions of BGP unless specifically noted otherwise.

Security Considerations

   Security considerations are not discussed in this memo.

Acknowledgments

   We'd like to thank Vince Fuller, Sean Doran, and Andrew Partan for
   bringing to our attention the problems that we believe the BGP
   communities attribute will help solve.  We'd also like to thank Yakov
   Rekhter his review of this document as well as his constructive and
   valuable comments.

Expiration Date November 1996                                   [Page 4]
INTERNET DRAFT                                            April 10, 1996

Author's  Addresses:

   Paul Traina
   cisco Systems, Inc.
   170 W. Tasman Dr.
   San Jose, CA 95134
   pst@cisco.com

   Ravishanker Chandrasekeran
   (Ravi Chandra)
   cisco Systems, Inc.
   170 W. Tasman Dr.
   San Jose, CA 95134
   rchandra@cisco.com

   Tony Li
   tli@skat.usc.edu

References

[1] RFC1771
   Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", March
   1995.

[2] draft-ietf-idr-bgp-confed-00.txt
   Traina, P.  "Autonomous System Confederations for BGP", December
   1995, Internet Draft: work in progress.

Expiration Date November 1996                                   [Page 5]