home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1997 < prev    next >
Text File  |  1996-08-28  |  8KB  |  284 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         R. Chandra
  8. Request for Comments: 1997                                     P. Traina
  9. Category: Standards Track                                  cisco Systems
  10.                                                                    T. Li
  11.                                                              August 1996
  12.  
  13.  
  14.                        BGP Communities Attribute
  15.  
  16. Status of This Memo
  17.  
  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.
  23.  
  24. Abstract
  25.  
  26.    Border Gateway Protocol [1] is an inter-autonomous system routing
  27.    protocol designed for TCP/IP internets.
  28.  
  29.    This document describes an extension to BGP which may be used to pass
  30.    additional information to both neighboring and remote BGP peers.
  31.  
  32.    The intention of the proposed technique is to aid in policy
  33.    administration and reduce the management complexity of maintaining
  34.    the Internet.
  35.  
  36. Introduction
  37.  
  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
  43.    (or part of it).
  44.  
  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.
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Chandra, et. al.            Standards Track                     [Page 1]
  59.  
  60. RFC 1997               BGP Communities Attribute             August 1996
  61.  
  62.  
  63. Terms and Definitions
  64.  
  65.    Community
  66.       A community is a group of destinations which share some common
  67.       property.
  68.  
  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.
  72.  
  73. Examples
  74.  
  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.
  82.  
  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.)
  88.  
  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
  98.    their desired scope.
  99.  
  100. COMMUNITIES attribute
  101.  
  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
  106.    attribute.
  107.  
  108.    The COMMUNITIES attribute has Type Code 8.
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Chandra, et. al.            Standards Track                     [Page 2]
  115.  
  116. RFC 1997               BGP Communities Attribute             August 1996
  117.  
  118.  
  119.    Communities are treated as 32 bit values,  however for administrative
  120.    assignment,  the following presumptions may be made:
  121.  
  122.    The community attribute values ranging from 0x0000000 through
  123.    0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are hereby reserved.
  124.  
  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
  131.    0x02B2FFFF).
  132.  
  133. Well-known Communities
  134.  
  135.    The following communities have global significance and their
  136.    operations shall be implemented in any community-attribute-aware BGP
  137.    speaker.
  138.  
  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
  148.          peers.
  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).
  154.  
  155. Operation
  156.  
  157.    A BGP speaker may use this attribute to control which routing
  158.    information it accepts, prefers or distributes to other neighbors.
  159.  
  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.
  163.  
  164.    A BGP speaker receiving a route with the COMMUNITIES path attribute
  165.    may modify this attribute according to the local policy.
  166.  
  167.  
  168.  
  169.  
  170. Chandra, et. al.            Standards Track                     [Page 3]
  171.  
  172. RFC 1997               BGP Communities Attribute             August 1996
  173.  
  174.  
  175. Aggregation
  176.  
  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.
  181.  
  182. Applicability
  183.  
  184.    The COMMUNITIES path attribute may be used with BGP version 2 and all
  185.    subsequent versions of BGP unless specifically noted otherwise.
  186.  
  187. Security Considerations
  188.  
  189.    Security issues are not discussed in this memo.
  190.  
  191. Acknowledgments
  192.  
  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
  197.    valuable comments.
  198.  
  199. Authors' Addresses
  200.  
  201.    Paul Traina
  202.    cisco Systems, Inc.
  203.    170 W. Tasman Dr.
  204.    San Jose, CA 95134
  205.  
  206.    EMail: pst@cisco.com
  207.  
  208.  
  209.    Ravishanker Chandrasekeran
  210.    (Ravi Chandra)
  211.    cisco Systems, Inc.
  212.    170 W. Tasman Dr.
  213.    San Jose, CA 95134
  214.  
  215.    EMail: rchandra@cisco.com
  216.  
  217.  
  218.    Tony Li
  219.    EMail: tli@skat.usc.edu
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Chandra, et. al.            Standards Track                     [Page 4]
  227.  
  228. RFC 1997               BGP Communities Attribute             August 1996
  229.  
  230.  
  231. References
  232.  
  233.    [1] RFC 1771
  234.       Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
  235.       March 1995.
  236.  
  237.    [2] RFC 1965
  238.       Traina, P., "Autonomous System Confederations for BGP", June 1996.
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Chandra, et. al.            Standards Track                     [Page 5]
  283.  
  284.