idnits 2.17.1 draft-ietf-idr-bgp-ext-communities-05.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 10 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 an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 68 has weird spacing: '...es with the E...' == Line 359 has weird spacing: '...tribute as de...' -- 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) == Unused Reference: 'BGP-4' is defined on line 412, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (ref. 'BGP-4') (Obsoleted by RFC 4271) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Srihari R. Sangli (Procket Networks) 3 Internet Draft Daniel Tappan (Cisco Systems) 4 Expiration Date: November 2002 Yakov Rekhter (Juniper Networks) 6 BGP Extended Communities Attribute 8 draft-ietf-idr-bgp-ext-communities-05.txt 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 2. Abstract 33 This document describes an extension to BGP-4 which may be used to 34 provide flexible control over the distribution of routing 35 information. 37 3. Specification of Requirements 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in RFC 2119 [RFC2119]. 43 4. Introduction 45 The Extended Community Attribute provides two important enhancements 46 over the existing BGP Community Attribute: 48 - It provides an extended range, ensuring that communities can be 49 assigned for a plethora of uses, without fear of overlap. 51 - The addition of a Type field provides structure for the 52 community space. 54 The addition of structure allows the usage of policy based on the 55 application for which the community value will be used. For example, 56 one can filter out all communities of a particular type, or allow 57 only certain values for a particular type of community. It also 58 allows one to specify whether a particular community is transitive or 59 non-transitive across Autonomous system boundary. Without structure, 60 this can only be accomplished by explicitly enumerating all community 61 values which will be denied or allowed and passed to BGP speakers in 62 neighboring ASes based on the transitive property. 64 5. BGP Extended Communities Attribute 66 The Extended Communities Attribute is a transitive optional BGP 67 attribute, with the Type Code 16. The attribute consists of a set of 68 "extended communities". All routes with the Extended Communities 69 attribute belong to the communities listed in the attribute. 71 Each Extended Community is encoded as an eight octet quantity, as 72 follows: 74 - Type Field : 1 or 2 octets 75 - Value Field : Remaining octets 76 0 1 2 3 77 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 78 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 79 | Type high | Type low(*) | | 80 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | 81 | | 82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 84 *) Present for Extended types only, used for the Value field 85 otherwise 87 Type Field: 89 Two classes of Type Field are introduced: Regular type and 90 Extended type. 92 The size of Type Field for Regular types is 1 octet and the 93 size of the Type Field for Extended types is 2 octets. 95 The value of the high-order octet of the Type Field determines 96 if an extended community is a Regular type or an Extended type. 98 The high-order octet of the Type Field is as shown below: 100 0 1 2 3 4 5 6 7 101 +-+-+-+-+-+-+-+-+ 102 |I|T| | 103 +-+-+-+-+-+-+-+-+ 105 I - IANA authority bit 107 Value 0: IANA assignable type using the "First Come First 108 Serve" policy 110 Value 1: IANA assignable type using the IETF Consensus 111 policy and experimental 113 T - Transitive bit 115 Value 0: The community is transitive across ASes 117 Value 1: The community is non-transitive across ASes 119 Remaining 6 bits: Indicates the structure of the community 120 Value Field: 122 The encoding of the Value Field is dependent on the "type" of 123 the community as specified by the Type Field. 125 Two extended communities are declared equal only when all 8 octets of 126 their encoding are equal. 128 The two members in the tuple should be enumerated to 129 specify any community value. Based on the value of the Type field, 130 the remaining octets of the community should be interpreted. 132 6. Defined BGP Extended Community Types 134 This section introduces a few extended types and defines the format 135 of the Value Field for those types. The types introduced here provide 136 "templates", where each template is identified by the high order 137 octet of the extended community Type field, and the lower order octet 138 (sub-type) is used to indicate a particular type of extended commu- 139 nity. 141 6.1. Two-octet AS specific extended community 143 This is an extended type with Type Field comprising of 2 octets and 144 Value Field comprising of 6 octets. 146 0 1 2 3 147 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | 0x00 or 0x40 | Sub-Type | Global Administrator | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Local Administrator | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 The value of the high-order octet of this extended type is either 155 0x00 or 0x40. The low-order octet of this extended type is used to 156 indicate sub-types. 158 The Value Field consists of two sub-fields: 160 Global Administrator sub-field: 2 octets 162 This sub-field contains an Autonomous System number assigned by 163 IANA. 165 Local Administrator sub-field: 4 octets 167 The organization identified by Autonomous System number in the 168 Global Administrator sub-field, can encode any information in 169 this sub-field. The format and meaning of the value encoded in 170 this sub-field should be defined by the sub-type of the commu- 171 nity. 173 6.2. IPv4 address specific extended community 175 This is an extended type with Type Field comprising of 2 octets and 176 Value Field comprising of 6 octets. 178 0 1 2 3 179 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | 0x01 or 0x41 | Sub-Type | Global Administrator | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Global Administrator (cont.) | Local Administrator | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 The value of the high-order octet of this extended type is either 187 0x01 or 0x41. The low-order octet of this extended type is used to 188 indicate sub-types. 190 The Value field consists of two sub-fields: 192 Global Administrator sub-field: 4 octets 194 This sub-field contains an IPv4 address assigned by IANA. 196 Local Administrator sub-field: 2 octets 198 The organization which has been assigned the IPv4 address in 199 the Global Administrator sub-field, can encode any information 200 in this sub-field. The format and meaning of this value 201 encoded in this sub-field should be defined by the sub-type of 202 the community. 204 6.3. Four-octet AS specific extended community 206 This is an extended type with Type Field comprising of 2 octets and 207 Value Field comprising of 6 octets. 209 0 1 2 3 210 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | 0x02 or 0x42 | Sub-Type | Global Administrator | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Global Administrator (cont.) | Local Administrator | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 The value of the high-order octet of this extended type is either 218 0x02 or 0x42. The low-order octet of this extended type is used to 219 indicate sub-types. 221 The Value Field consists of two sub-fields: 223 Global Administrator sub-field: 4 octets 225 This sub-field contains a 4-octets Autonomous System number 226 assigned by IANA. 228 Local Administrator sub-field: 2 octets 230 The organization identified by Autonomous System number in the 231 Global Administrator sub-field, can encode any information in 232 this sub-field. The format and meaning of the value encoded in 233 this sub-field should be defined by the sub-type of the commu- 234 nity. 236 6.4. Opaque extended community 238 This is an extended type with Type Field comprising of 2 octets and 239 Value Field comprising of 6 octets. 241 0 1 2 3 242 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | 0x03 or 0x43 | Sub-Type | Value | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Value (cont.) | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 The value of the high-order octet of this extended type is either 250 0x03 or 0x43. The low-order octet of this extended type is used to 251 indicate sub-types. 253 This is a generic community of extended type. The value of the sub- 254 type which should define the Value Field is to be assigned by IANA. 256 7. Route Target Community 258 The Route Target Community identifies one or more routers that may 259 receive a set of routes (that carry this Community) carried by BGP. 260 This is transitive across the Autonomous system boundary. 262 The Route Target Community is of an extended type. 264 The value of the high-order octet of the Type field for the Route 265 Target Community can be 0x00, 0x01 or 0x02. The value of the low- 266 order octet of the Type field for this community is 0x02. 268 When the value of the high-order octet of the Type field is 0x00 or 269 0x02, the Local Administrator sub-field contains a number from a num- 270 bering space which is administered by the organization to which the 271 Autonomous System number carried in the Global Administrator subfield 272 has been assigned by an appropriate authority. 274 When the value of the high-order octet of the Type field is 0x01, the 275 Local Administrator sub-field contains a number from a numbering 276 space which is administered by the organization to which the IP 277 address carried in the Global Administrator subfield has been 278 assigned by an appropriate authority. 280 8. Route Origin Community 282 The Route Origin Community identifies one or more routers that inject 283 a set of routes (that carry this Community) into BGP. This is transi- 284 tive across the Autonomous system boundary. 286 The Route Origin Community is of an extended type. 288 The value of the high-order octet of the Type field for the Route 289 Origin Community can be 0x00, 0x01 or 0x02. The value of the low- 290 order octet of the Type field for this community is 0x03. 292 When the value of the high-order octet of the Type field is 0x00 or 293 0x02, the Local Administrator sub-field contains a number from a num- 294 bering space which is administered by the organization to which the 295 Autonomous System number carried in the Global Administrator subfield 296 has been assigned by an appropriate authority. 298 When the value of the high-order octet of the Type field is 0x01, the 299 Local Administrator sub-field contains a number from a numbering 300 space which is administered by the organization to which the IP 301 address carried in the Global Administrator subfield has been 302 assigned by an appropriate authority. 304 9. Link Bandwidth Community 306 When a router receives a route from a directly connected external 307 neighbor (the external neighbor that is one IP hop away), and adver- 308 tises this route (via IBGP) to internal neighbors, as part of this 309 advertisement the router may carry the bandwidth of the link that 310 connects the router with the external neighbor. The bandwidth of such 311 a link is carried in the Link Bandwidth Community. 313 The Link Bandwidth Community is of an extended type. 315 The value of the high-order octet of the Type Field is 0x00. The 316 value of the low-order octet of the Type field for this community is 317 0x04. 319 The value of the Global Administrator sub-field in the Value Field 320 MUST represent the Autonomous System of the router that attaches the 321 Link Bandwidth Community. 323 The bandwidth of the link is expressed as 4 octets in IEEE floating 324 point format, units being bytes per second. It is carried in the 325 Local Administrator sub-field of the Value Field. 327 10. Operations 329 A BGP speaker may use the Extended Communities attribute to control 330 which routing information it accepts or distributes to its peers. 332 The Extended Community attribute MUST NOT be used to modify the BGP 333 best path selection algorithm in a way that leads to forwarding 334 loops. 336 A BGP speaker receiving a route that doesn't have the Extended Commu- 337 nities attribute MAY append this attribute to the route when propa- 338 gating it to its peers. 340 A BGP speaker receiving a route with the Extended Communities 341 attribute MAY modify this attribute according to the local policy. 343 By default if a range of routes is to be aggregated and the resultant 344 aggregates path attributes do not carry the ATOMIC_AGGREGATE 345 attribute, then the resulting aggregate should have an Extended Com- 346 munities path attribute which contains the set union of all the 347 Extended Communities from all of the aggregated routes. The default 348 behavior could be overriden via local configuration, in which case 349 handling the Extended Communities attribute in the presence of route 350 aggregation becomes a matter of the local policy of the BGP speaker 351 that performs the aggregation. 353 If a route has a non-transitivity extended community, then before 354 advertising the route across the Autonomous system boundary the com- 355 munity SHOULD be removed from the route. However, the community 356 SHOULD NOT be removed when advertising the route across the BGP Con- 357 federation boundary. 359 A route may carry both the BGP Communities attribute as defined in 360 [RFC1997]), and the Extended BGP Communities attribute. In this case 361 the BGP Communities attribute is handled as specified in [RFC1997], 362 and the Extended BGP Communities attribute is handled as specified in 363 this document. 365 11. IANA Considerations 367 The value of the high-order octet of the Type Field determines if an 368 extended community is a regular type or an extended type. The value 369 of the high-order octet of the Type Field defined as regular type (or 370 extended type) for a extended community MUST NOT be reused as the 371 value of the high-order octet of the Type Field defined as extended 372 type (or regular type). 374 For the high-order octet of the Type Field, values 0x00 through 0x03 375 and 0x40 through 0x43 are assigned in this document and are defined 376 as extended types. 378 For the combination of the high-order and low-order octets of the 379 Type Field values 0x0002-0x0004, 0x0102-0x0103, and 0x0202-0x0203 are 380 assigned in this document. 382 The Type Field values 0x04-0x3f and 0x44-0x7f for regular types 383 (0x0400-0x3fff and 0x4400-0x7fff when expressed as extended types) 384 are to be assigned by IANA, using the "First Come First Served" pol- 385 icy defined in RFC 2434. 387 The extended Type Field values 0x0000-0x0001, 0x0005-0x00ff, 388 0x0100-0x0101, 0x0104-0x01ff, 0x0200-0x0201, 0x0204-0x02ff, 389 0x0300-0x03ff, and 0x4000-0x43ff are to be assigned by IANA, using 390 the "First Come First Served" policy defined in RFC 2434. 392 The Type Field values 0x90-0xbf and 0xd0-0xff for regular types 393 (0x9000-0xbfff and 0xd000-0xffff when expressed as extended types) 394 are to be assigned by IANA, using the "IETF Consensus" policy defined 395 in RFC2434. 397 The Type Field values 0x80-0x8f and 0xc0-0xcf for regular types 398 (0x8000-0x8fff and 0xc000-0xcfff when expressed as extended types) 399 are experimental, and are not to be assigned by IANA. 401 12. Security Considerations 403 This extension to BGP does not change the underlying security issues. 405 13. Acknowledgements 407 The authors would like to thank John Hawkinson, Jeffrey Haas, Bruno 408 Rijsman, and Alex Zinin for their suggestions and feedback. 410 14. References 412 [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 413 (BGP-4)", RFC 1771, March 1995. 415 [RFC1997] Chandra, R., Traina, P., Li, T., "BGP Communities 416 Attribute", RFC1997, August 1996. 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, March 1997. 421 15. Author Information 423 Srihari R. Sangli 424 Procket Networks, Inc. 425 1100 Cadillac Court 426 Milpitas, CA - 95035 427 e-mail: srihari@procket.com 429 Dan Tappan 430 Cisco Systems, Inc. 431 250 Apollo Drive 432 Chelmsford, MA 01824 433 e-mail: tappan@cisco.com 435 Yakov Rekhter 436 Juniper Networks, Inc. 437 1194 N. Mathilda Ave 438 Sunnyvale, CA 94089 439 e-mail: yakov@juniper.net