idnits 2.17.1 draft-ietf-idr-bgp-ext-communities-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 ([BGP-4]), 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 211: '... the Value Field MUST be unique within...' RFC 2119 keyword, line 225: '... the Value Field MUST be unique within...' RFC 2119 keyword, line 243: '... MUST represent the Autonomous Syste...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 68 has weird spacing: '...es with the E...' == Line 269 has weird spacing: '...tribute as de...' == Line 277 has weird spacing: '...e Field value...' == Line 279 has weird spacing: '...es) are to be...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1771 (ref. 'BGP-4') (Obsoleted by RFC 4271) Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Srihari R. Sangli 2 Internet Draft Procket Networks 3 Expiration Date: January 2002 4 Daniel Tappan 5 Cisco Systems 7 Yakov Rekhter 8 Juniper Networks 10 BGP Extended Communities Attribute 12 draft-ietf-idr-bgp-ext-communities-00.txt 14 1. Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026 except that the right to 18 produce derivative works is not granted. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as ``work in progress.'' 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 2. Abstract 38 This document describes an extension to BGP [BGP-4] which may be used 39 to provide flexible control over the distribution of routing 40 information. 42 3. Introduction 44 The Extended Community Attribute provides two important enhancements 45 over the existing BGP Community Attribute: 47 - It provides an extended range, ensuring that communities can be 48 assigned for a plethora of uses, without fear of overlap. 50 - The addition of a Type field provides structure for the 51 community space. 53 The addition of structure allows the application of policy based on 54 the application for which the community value will be used. For 55 example, one can filter out all communities of a particular type, or 56 allow only certain values for a particular type of community. It also 57 allows one to specify whether a particular community is transitive or 58 non-transitive across Autonomous system boundary. Without structure 59 this can only be accomplished by explicitly enumerating all community 60 values which will be denied or allowed and passed to BGP speakers in 61 neighboring ASes based on the transitive property. 63 4. BGP Extended Communities Attribute 65 The Extended Communities Attribute is a transitive optional BGP 66 attribute. The attribute consists of a set of "extended 67 communities". Each extended community is coded as an eight octet 68 value. All routes with the Extended Communities attribute belong to 69 the communities listed in the attribute. 71 The Extended Communities Attribute has Type Code 16. 73 Each Extended Community is encoded as an eight octet quantity, as 74 follows: 76 - Type Field : 1 or 2 octets 77 - Value Field : Remaining octets 79 Type Field: 81 The value of the high-order octet will determine if its a 82 regular type or extended type. The size of Type Field for 83 regular types is 1 octet and the size of the Type Field for 84 extended types is 2 octets. 86 The high-order octet of the Type Field is as shown below: 88 First bit (MSB) : IANA authority bit 89 Value 0 : IANA assignable type 90 Value 1 : Vendor-specific types 92 Second bit : Transitive bit 93 Value 0 : The community is 94 Transitive across ASes 95 Value 1 : The community is 96 Non-Transitive across ASes 98 Remaining 6 bits : Indicates the structure of the 99 community 101 For regular types, values of the Type Field 0 through 0x3f 102 inclusive are assignable by IANA. The values 0x80 through 0xbf 103 inclusive are vendor-specific. 105 For extended types, values of the Type Field 0 through 0x3fff 106 inclusive are assignable by IANA. The values 0x8000 through 107 0xbfff inclusive are vendor-specific. 109 Value Field: 111 The encoding of the Value Field is dependent on the "type" of 112 the community as specified by the Type Field. The encoding of 113 the community for the transitive communities should be such 114 that it is unique globally (i.e. across the Autonomous 115 Systems). 117 Two extended communities are declared equal only when entire 8 118 octets are equal. 120 The two members in the tuple should be enumerated to 121 specify any community value. Based on the value of the Type field, 122 the remaining octets of the community should be interpreted. 124 5. New BGP Extended Community Types. 126 This document introduces a few extended types and defines the Value 127 Field for those types. 129 Type 0x00: 131 This is an extended type with Type Field comprising of 2 octets 132 and Value Field comprising of 6 octets. 134 The value of the high-order octet of this extended type is 135 0x00. The low-order octet of this extended type is used to 136 indicate subtypes. 138 The Value Field consists of two subfields: 140 Global Administrator subfield: 2 octets 142 This subfield contains an Autonomous System number 143 assigned by IANA. 145 Local Administrator subfield: 4 octets 147 The organization identified by Autonomous System number 148 in the Global Administrator subfield, can encode any 149 information in this subfield. The value and meaning of 150 the value encoded in this subfield should be defined by 151 the subtype of the community. 153 Type 0x01: 155 This is an extended type with Type Field comprising of 2 octets 156 and Value Field comprising of 6 octets. 158 The value of the high-order octet of this extended type is 159 0x01. The low-order octet of this extended type is used to 160 indicate subtypes. 162 The Value field consists of two subfields. 164 Global Administrator subfield: 4 octets 166 This subfield contains an IPv4 address assigned by IANA. 168 Local Administrator subfield: 2 octets 170 The organization which has been assigned the IPv4 address 171 in the Global Administrator subfield, can encode any 172 information in this subfield. The value and meaning of 173 this value encoded in this subfield should be defined by 174 the subtype of the community. 176 Type 0x02: 178 This is an extended type with Type Field comprising of 2 octets 179 and Value Field comprising of 6 octets. 181 The value of the high-order octet of this extended type is 182 0x02. The low-order octet of this extended type is used to 183 indicate subtypes. 185 The Value Field consists of two subfields. 187 Global Administrator subfield: 4 octets 189 This subfield contains a 4-octets Autonomous System 190 number assigned by IANA. 192 Local Administrator subfield: 2 octets 194 The organization identified by Autonomous System number 195 in the Global Administrator subfield, can encode any 196 information in this subfield. The value and meaning of 197 the value encoded in this subfield should be defined by 198 the subtype of the community. 200 6. Route Target Community 202 The Route Target Community identifies one or more routers that may 203 receive a set of routes (that carry this Community) carried by BGP. 204 This is transitive across the Autonomous system boundary. 206 The value of the Type field for the Route Target Community is 0x00 or 207 0x01. The value of the low-order octet of the extended type field 208 for this community is 0x02. 210 When the value of the Type field is 0x00, the value of the Local 211 Administrator subfield in the Value Field MUST be unique within the 212 Autonomous system carried in the Global Administrator subfield. 214 7. Route Origin Community 216 The Route Origin Community identifies one or more routers that inject 217 a set of routes (that carry this Community) into BGP. This is 218 transitive across the Autonomous system boundary. 220 The value of the Type field for the Route Origin Community is 0x00 or 221 0x01. The value of the low-order octet of the extended type field 222 for this community is 0x03. 224 When the value of the Type field is 0x00, the value of the Local 225 Administrator subfield in the Value Field MUST be unique within the 226 Autonomous system carried in the Global Administrator subfield. 228 8. Link Bandwidth Community 230 When a router receives a route from a directly connected external 231 neighbor (the external neighbor that is one IP hop away), and 232 advertises this route (via IBGP) to internal neighbors, as part of 233 this advertisement the router may carry the bandwidth of the link 234 that connects the router with the external neighbor. The bandwidth of 235 such a link is carried in the Link Bandwidth Community. The community 236 is non-transitive across the Autonomous system boundary. 238 The value of the high-order octet of the extended Type Field is 0x40. 239 The value of the low-order octet of the extended type field for this 240 community is 0x04. 242 The value of the Global Administrator subfield in the Value Field 243 MUST represent the Autonomous System of the router that attaches the 244 Link Bandwidth Community. When a router receives a route with the 245 community, the router may check the AS number in the Global 246 Administrator subfield to see if its if its not the local AS and 247 hence ignore the information carried in the Link Bandwidth Community. 249 The bandwidth of the link is expressed as 4 octets in IEEE floating 250 point format, units being bytes per second. It is carried in the 251 Local Administrator subfield of the Value Field. 253 9. Operations 255 A BGP speaker may use the Extended Communities attribute to control 256 which routing information it accepts, prefers or distributes to its 257 peers. 259 A BGP speaker receiving a route that doesn't have the Extended 260 Communities attribute may append this attribute to the route when 261 propagating it to its peers. 263 A BGP speaker receiving a route with the Extended Communities 264 attribute may modify this attribute according to the local policy. 266 A BGP speaker should not propagate a non-transitive extended 267 community across the Autonomous system boundary. 269 A route may carry both the BGP Communities attribute as defined in 270 [RFC1997]), and the Extended BGP Communities attribute. In this case 271 the BGP Communities attribute is handled as specified in [RFC1997], 272 and the Extended BGP Communities attribute is handled as specified in 273 this document. 275 10. IANA Considerations 277 The Type Field values 0x00 and 0x01 are assigned in this document. 278 Type Field values 2-0x3fff for extended-types (2-0x3f for regular 279 types) are to be assigned by IANA, using the "First Come First 280 Served" policy defined in RFC 2434. Type values 0x8000-0xbfff for 281 extended-types (0x80-0xbf for regular-types) are for vendor-specific 282 types, and values in this range are not to be assigned by IANA. 284 11. Security Considerations 286 This extension to BGP does not change the underlying security issues. 288 12. Acknowledgements 290 The authors would like to thank John Hawkinson, Jeffrey Haas for 291 their feedback. 293 13. References 295 [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 296 (BGP-4)", RFC 1771, March 1995. 298 [RFC1997] Chandra, R., Traina, P., Li, T., "BGP Communities 299 Attribute", RFC1997, August 1996. 301 14. Author Information 303 Srihari R. Sangli 304 Procket Networks, Inc. 305 1100 Cadillac Court 306 Milpitas, CA - 95035 307 e-mail: srihari@procket.com 309 Dan Tappan 310 Cisco Systems, Inc. 311 250 Apollo Drive 312 Chelmsford, MA 01824 313 e-mail: tappan@cisco.com 315 Yakov Rekhter 316 Juniper Networks, Inc. 317 1194 N. Mathilda Ave 318 Sunnyvale, CA 94089 319 e-mail: yakov@juniper.net