idnits 2.17.1 draft-ietf-idr-communities-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 126: '... this value MUST NOT be advertise...' RFC 2119 keyword, line 131: '... this value MUST NOT be advertise...' RFC 2119 keyword, line 134: '... this value MUST NOT be advertise...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 10, 1996) is 10205 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 198, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (ref. '1') (Obsoleted by RFC 4271) ** Downref: Normative reference to an Experimental draft: draft-ietf-idr-bgp-confed (ref. '2') Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Ravi Chandra 3 INTERNET DRAFT Paul Traina 4 cisco Systems 5 Tony Li 6 April 10, 1996 8 BGP communities attribute 10 Status of this Memo 12 This memo provides information for the Internet community. It does 13 not specify an Internet standard. Distribution of this memo is 14 unlimited. 16 This document is an Internet Draft. Internet Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its Areas, 18 and its Working Groups. Note that other groups may also distribute 19 working documents as Internet Drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months. Internet Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet 24 Drafts as reference material or to cite them other than as a "working 25 draft" or "work in progress". 27 Please check the I-D abstract listing contained in each Internet 28 Draft directory to learn the current status of this or any other 29 Internet Draft. 31 Abstract 33 Border Gateway Protocol [1] is an inter-autonomous system routing 34 protocol designed for TCP/IP internets. 36 This document describes an extension to BGP which may be used to pass 37 additional information to both neighboring and remote BGP peers. 39 The intention of the proposed technique is to aid in policy 40 administration and reduce the management complexity of maintaining 41 the Internet. 43 Introduction 45 BGP supports transit policies via controlled distribution of routing 46 information. Mechanisms for this are described in [1] and have been 47 successfully used by transit service providers. However, control 48 over the distribution of routing information is presently based on 49 either IP address prefixes or on the value of the AS_PATH attribute 50 (or part of it). 52 To facilitate and simplify the control of routing information this 53 document suggests a grouping of destinations so that the routing 54 decision can also be based on the identity of a group. Such a scheme 55 is expected to significantly simplify a BGP speaker's configuration 56 that controls distribution of routing information. 58 Terms and Definitions 60 Community 61 A community is a group of destinations which share some common 62 property. 64 Each autonomous system administrator may define which communities 65 a destination belongs to. By default, all destinations belong to 66 the general Internet community. 68 Examples 70 A property such as "NSFNET sponsored/AUP" could be added to all AUP 71 compliant destinations advertised into the NSFNET. NSFNET operators 72 could define a policy that would advertise all routes, tagged or not, 73 to directly connected AUP compliant customers and only tagged routes 74 to commercial or external sites. This would insure that at least one 75 side of a given connection is AUP compliant as a way of enforcing NSF 76 transit policy guidelines. 78 In this example, we have just eliminated the primary motivation for a 79 complex policy routing database that is used to generate huge prefix 80 and AS path based filter rules. We have also eliminated the delays 81 caused by the out-of-band maintenance of this database (mailing in 82 NACRs, weekly configuration runs, etc.) 84 A second example comes from experience with aggregation. It is often 85 useful to advertise both an aggregate prefix and the component more- 86 specific prefixes that were used to form the aggregate to optimize 87 "next hop" routing. These component prefixes are only useful to the 88 neighboring BGP peer or perhaps the autonomous system of the 89 neighboring BGP peer, so it is desirable to filter this information. 90 By specifying a community value that the neighboring peer or peers 91 will match and filter on, these more specific routes may be 92 advertised with the assurance that they will not propagate beyond 93 their desired scope. 95 COMMUNITIES attribute 97 This document creates the COMMUNITIES path attribute is an optional 98 transitive attribute of variable length. The attribute consists of a 99 set of four octet values, each of which specify a community. All 100 routes with this attribute belong to the communities listed in the 101 attribute. 103 The COMMUNITIES attribute has Type Code 8. 105 Communities are treated as 32 bit values, however for administrative 106 assignment, the following presumptions may be made: 108 The community attribute values ranging from 0x0000000 through 109 0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are hereby reserved. 111 The rest of the community attribute values shall be encoded using an 112 autonomous system number in the first two octets. The semantics of 113 the final two octets may be defined by the autonomous system (e.g. AS 114 690 may define research, educational and commercial community values 115 that may be used for policy routing as defined by the operators of 116 that AS using community attribute values 0x02B20000 through 117 0x02B2FFFF). 119 Well-known Communities 121 The following communities have global significance and their 122 operations shall be implemented in any community-attribute-aware BGP 123 speaker. 124 NO_EXPORT (0xFFFFFF01) 125 All routes received carrying a communities attribute containing 126 this value MUST NOT be advertised outside a BGP confederation 127 boundary (a stand-alone autonomous system that is not part of a 128 confederation should be considered a confederation itself). 129 NO_ADVERTISE (0xFFFFFF02) 130 All routes received carrying a communities attribute containing 131 this value MUST NOT be advertised to other BGP peers. 132 NO_EXPORT_SUBCONFED (0xFFFFFF03) 133 All routes received carrying a communities attribute containing 134 this value MUST NOT be advertised to external BGP peers (this 135 includes peers in other members autonomous systems inside a BGP 136 confederation). 138 Operation 140 A BGP speaker may use this attribute to control which routing 141 information it accepts, prefers or distributes to other neighbors. 143 A BGP speaker receiving a route that does not have the COMMUNITIES 144 path attribute may append this attribute to the route when 145 propagating it to its peers. 147 A BGP speaker receiving a route with the COMMUNITIES path attribute 148 may modify this attribute according to the local policy. 150 Aggregation 152 If a range of routes is to be aggregated and the resultant aggregates 153 attribute section does not carry the ATOMIC_AGGREGATE attribute, then 154 the resulting aggregate should have a COMMUNITIES path attribute 155 which contains all communities from all of the aggregated routes. 157 Applicability 159 The COMMUNITIES path attribute may be used with BGP version 2 and all 160 subsequent versions of BGP unless specifically noted otherwise. 162 Security Considerations 164 Security considerations are not discussed in this memo. 166 Acknowledgments 168 We'd like to thank Vince Fuller, Sean Doran, and Andrew Partan for 169 bringing to our attention the problems that we believe the BGP 170 communities attribute will help solve. We'd also like to thank Yakov 171 Rekhter his review of this document as well as his constructive and 172 valuable comments. 174 Author's Addresses: 176 Paul Traina 177 cisco Systems, Inc. 178 170 W. Tasman Dr. 179 San Jose, CA 95134 180 pst@cisco.com 182 Ravishanker Chandrasekeran 183 (Ravi Chandra) 184 cisco Systems, Inc. 185 170 W. Tasman Dr. 186 San Jose, CA 95134 187 rchandra@cisco.com 189 Tony Li 190 tli@skat.usc.edu 192 References 194 [1] RFC1771 195 Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", March 196 1995. 198 [2] draft-ietf-idr-bgp-confed-00.txt 199 Traina, P. "Autonomous System Confederations for BGP", December 200 1995, Internet Draft: work in progress.