idnits 2.17.00 (12 Aug 2021) /tmp/idnits46710/draft-lange-flexible-bgp-communities-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (August 2, 2010) is 4303 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: 'RFC1771' is defined on line 897, but no explicit reference was found in the text == Unused Reference: 'RFC2842' is defined on line 913, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2547 (Obsoleted by RFC 4364) ** Obsolete normative reference: RFC 2842 (Obsoleted by RFC 3392) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Lange 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track J. Haas 5 Expires: February 3, 2011 Juniper Networks 6 K. Patel 7 Cisco 8 S. Amante 9 Level 3 10 August 2, 2010 12 Flexible BGP Communities 13 draft-lange-flexible-bgp-communities-03 15 Abstract 17 This document defines a new attribute for BGP called the Flexible 18 Community attribute. Flexible Communities build on the experience 19 and utility of the standard BGP community, and the extended BGP 20 community attributes. This attribute allows operators to associate 21 structured information with a route or set of routes. This 22 information can be then be used to execute routing policy. An 23 enhanced version of communities is necessary to accommodate IPv6, 24 4-byte ASN's, and introduce a more extensible and flexible policy 25 expression. This document also introduces the concept of Neighbor 26 Classes. A Neighbor Class is applied to a group of BGP neighbors who 27 share certain attributes. For example, the PEER Neighbor Class could 28 be applied to BGP sessions between ASN X and other networks with 29 which ASN X has a non-transit peering relationship. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on February 3, 2011. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Specification of Requirements . . . . . . . . . . . . . . . . 3 65 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. The BGP Flexible Community Attribute . . . . . . . . . . . . . 4 67 3.1. Transitivity Field . . . . . . . . . . . . . . . . . . . . 4 68 3.2. Structure Field . . . . . . . . . . . . . . . . . . . . . 5 69 3.3. Type Field . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.4. Originating ASN Field . . . . . . . . . . . . . . . . . . 6 71 3.5. Length Field . . . . . . . . . . . . . . . . . . . . . . . 6 72 4. Locally Defined Structures and Types . . . . . . . . . . . . . 6 73 5. Neighbor Classes . . . . . . . . . . . . . . . . . . . . . . . 7 74 5.1. Locally Defined Neighbor Classes . . . . . . . . . . . . . 8 75 5.2. Defined Neighbor Classes . . . . . . . . . . . . . . . . . 9 76 6. Defined Flexible BGP Community Structures . . . . . . . . . . 9 77 7. Base BGP Flexible Community Type (Opaque Type) . . . . . . . . 11 78 8. Defined Flexible BGP Community Types . . . . . . . . . . . . . 11 79 8.1. NO_EXPORT . . . . . . . . . . . . . . . . . . . . . . . . 12 80 8.2. ONLY_EXPORT . . . . . . . . . . . . . . . . . . . . . . . 13 81 8.3. ANNOUNCE_WITH . . . . . . . . . . . . . . . . . . . . . . 14 82 8.4. PREPEND . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 8.5. The BGP VPN Communities . . . . . . . . . . . . . . . . . 16 84 9. New Capability Code for Flexible Communities . . . . . . . . . 17 85 10. Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 11. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 88 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 89 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 90 15. Normative References . . . . . . . . . . . . . . . . . . . . . 20 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 93 1. Specification of Requirements 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 2. Introduction 101 This attribute represents the third generation of the BGP community 102 attribute. The first generation is documented in [RFC1997]. The 103 second generation, the extended community, is documented in 104 [RFC4360]. 106 The Flexible Community Attribute provides a number of important 107 enhancements over the existing BGP Community Attribute and BGP 108 Extended Community Attribute. These enhancements are: 110 o Support for IPv6. 112 o More efficient encoding of lists of data, for example, a list of 113 ASN's. 115 o Clean support for a broad range of future data field structures 116 and interpretations. 118 o Support for locally defined community structures, and 119 interpretations. 121 o Easy extensibility for a range of future applications. 123 The continuation and expansion of the structure introduced with 124 Extended Communities allows for policy based on the application where 125 the community is being used. The separation of structure and 126 interpretation allows for easier machine and human parsing of 127 community types which do the same thing with slightly different 128 input. 130 This attribute continues the use of the Transitivity community bit, 131 first introduced in the Extended Community Attribute. 133 We also define a set of well-known values for this attribute which 134 can be used to replicate and extend the functionality of the existing 135 well-known community values. 137 The concept of Neighbor Classes is introduced. A Neighbor Class is 138 defined on a BGP peering session. It allows neighbors that share a 139 set of administrative attributes to be easily grouped together. 141 Policy can then be defined through Flexible Communities in reference 142 to these groupings. 144 3. The BGP Flexible Community Attribute 146 The Flexible Community Attribute is a transitive optional BGP 147 attribute with a Type Code of TBD. The attribute consists of a list 148 of "flexible communities." 150 Each Flexible Community is encoded as a variable length quantity. 151 The encoding scheme is: 153 o Transitivity Field: 1 bit 155 o Structure Field: 7 bits 157 o Type Field: 2 octets 159 o Length Field: 1 octet 161 o Value Field: 0-255 octets 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 |T| Struct. | Type | Originating | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | ASN | Length | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Value Field (0-255 octets) | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Figure 1: Flexible Community Packet Format 175 3.1. Transitivity Field 177 The Transitivity Field is one bit. It can take the following values: 179 o Value 0: The community is transitive across ASes 181 o Value 1: The community is non-transitive across ASes 183 It is important to note that the transitivity defined by this field 184 is different from the general transitivity of a BGP attribute. A 185 single Flexible Community Attribute, can contain multiple Flexible 186 Communities, each of which may or may not be transitive. If a route 187 originates in an AS with the transitivity bit set, indicating that 188 the community is non-transitive, then that AS MUST NOT propagate that 189 community to its peers. However, if a community with the transitive 190 bit set is applied on an outbound policy expression (e.g., a route- 191 map), the community will be conveyed to the immediately adjacent 192 peer. That peer, in turn, will NOT propagate the community to its 193 peers. The one exception to this is as-confederations. For the 194 purposes of this attribute, confederation boundaries should be 195 treated the same as IBGP. In other words, non-transitive flexible 196 communities should be propagated to other members of the as- 197 confederation, unless overridden by local policy. 199 If the community is transitive, then the Value Field MUST contain the 200 originating ASN. This ASN is encoded as a 4-octet value, occupying 201 the first 4 octets of the Value Field. Two-octet ASN numbers are 202 padded out to 4 octets. Any additional information in the Value 203 Field comes after this origin ASN data. 205 3.2. Structure Field 207 The Structure Field's contents modify the Type Field. For example, a 208 Flexible Community which specifies SPECIFIC_NO_EXPORT in its Type 209 Field, can be modified by the contents of the Structure Field to let 210 the receiver know if the list of data on which it must act is a list 211 of 2 octet or 4 octet ASNs. A set of commonly used Structure values 212 is defined later in this document. 214 The Structure field is the latter 7 bits of the first octet. It is 215 split into two sub-fields. 217 0 218 0 1 2 3 4 5 6 7 219 +-+-+-+-+-+-+-+-+ 220 |T|L| Struct. | 221 +-+-+-+-+-+-+-+-+ 223 Figure 2: Structure Field 225 o L - Local bit. The Local bit can take two values: 227 * Value 0: The Structure is Locally Defined. 229 * Value 1: The Structure is Well Known. 231 3.3. Type Field 233 The Type Field is two octets. This contents of this field are used 234 to define an action for the recipient to take on the route, or to 235 define and attribute that is related to that route. An example of 236 the former would be a Type which requests that a route be 237 ONLY_EXPORTed to a specific set of peers. An example of the latter 238 would be a Type that defines the LINK_BANDWIDTH associated with a 239 certain NLRI. 241 Like the Structure Field the Type Field is split into two Sub-Fields: 243 1 2 244 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 |L| Type | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Figure 3: Type Field 251 The Local bit can take two values: 253 o Value 0: The Type is Locally Defined. 255 o Value 1: The Type is Well Known. 257 An implementation MUST allow an operator to filter out entire Types 258 of Flexible Communities from their peering sessions if they so 259 choose. 261 3.4. Originating ASN Field 263 This field contains the ASN that added the flexible community to the 264 route. It is 4 octets long. In the case of a 2-byte ASN, the first 265 2 octets are set to zero, as padding. 267 3.5. Length Field 269 The Length Field specifies the length, in octets, of the Value Field. 271 4. Locally Defined Structures and Types 273 The Local bit allows the operator of the network to define Structures 274 and Types that are relevant only within that ASN's boundaries. The 275 definition the term "local" used throughout this document is: "A 276 value used by ad hoc agreement or convention outside the scope of 277 standardization, which has meaning only between the parties using the 278 Flexible Community in question." This typically means that the Local 279 value only has meaning within an AS or set of ASes controlled by a 280 single entity. 282 A Locally Defined Structure or Type will have a syntax for 283 interpretation defined on the routers that need to interpret it. If 284 a router receives a community with a Locally Defined Structure or 285 Type that it does not recognize, then it should ignore the contents 286 and process the route based on the information in the route that it 287 does understand. This includes obeying the transitivity bit, in the 288 Flexible Community. If the community is set to non-transitive, even 289 if the router does not understand the rest of the Structure or Type 290 of the community, that community should not be forwarded outside the 291 AS. 293 In order to prevent collisions with other operators' Locally Defined 294 values, Flexible Communities containing Locally Defined Structures or 295 Types MUST be non-transitive (have their Transitivity Field set to 296 1). 298 5. Neighbor Classes 300 A Neighbor Class is a value which represents a certain class, or 301 group, of BGP neighbors. Each BGP peering session can be configured 302 with zero or more Neighbor Classes. This value will allow a general 303 classification of what sort of relationship the BGP session 304 represents. With the sort of session defined, it becomes easier to 305 apply policy to only that class of neighbors. Neighbor Classes make 306 the expression of policy through flexible communities much easier. 307 There are a number of examples in the sections on defined values. 309 Neighbor Classes can be used in two main ways. First they can be 310 used in a passive manner, where the configuration acts as a policy 311 expression for communities matching it. An example of this would be 312 configuring a neighbor with the PEER neighbor class, and having a 313 community that, say is set to NO_EXPORT for the NEIGHBOR CLASS PEER. 314 In this configuration, all the neighbors that are configured as PEERs 315 would match and filter out the route carrying the NO_EXPORT, NEIGHBOR 316 CLASS PEER community. This is the standard way of using neighbor 317 classes. 319 A second, optional, way to use Neighbor Classes would be to allow 320 inbound community tagging. In this usage, routes traversing the 321 session would be automatically tagged with a flexible community with 322 the appropriate neighbor class value. This eases configuration. To 323 extend the example above, our neighbor designated PEER would add a 324 community with NEIGHBOR CLASS PEER to routes traversing the BGP 325 session. This community could then be used further down the line to 326 just announce PEER routes to a particular customer. This usage is 327 configurable on a per-neighbor basis. 329 A Neighbor Class is encoded as a 2-octet value with 2 parts: 331 0 1 332 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 |L| Neighbor Class | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Figure 4: Neighbor Class 339 The Local bit can take two values: 341 o Value 0: The Neighbor Class is Locally Defined. 343 o Value 1: The Neighbor Class is Well Known. 345 5.1. Locally Defined Neighbor Classes 347 If a router receives a Flexible Community containing a Neighbor Class 348 that it does not recognize, then it should ignore the contents and 349 process the route based on the information in the route that it does 350 understand. If the Transitivity Field of the Flexible Community with 351 the Locally Defined Structure or Type is set to 1 (the community is 352 non-transitive) then the router MUST NOT forward the Flexible 353 Community. Similarly, if the Transitivity Field is set to 0 (the 354 community is transitive) the router MUST forward the community along 355 with the NLRI. 357 Using Locally Defined Neighbor Classes an operator could easily 358 define a set that is locally useful. This set could be used in a 359 flat name space, for example, one could say that "31" would be "Asian 360 Public Peers", and "34" would be European Private Peers. 362 Also, a given BGP Neighbor can be part of multiple Neighbor Classes. 363 This would allow for a hierarchical or additive name space. For 364 example, a neighbor could be part of both "PEER", and locally defined 365 "ASIAN" and "PUBLIC PEER" Classes. The logical matching 366 functionality available is left implementation-dependent. However, 367 the default in such as case is logical OR functionality for matching 368 this neighbor class. In the case where routes are being tagged 369 inbound, then by default a single community with all configured 370 neighbor classes in a list is added. Implementation dependent knobs 371 are suggested to allow more fine grained control. 373 5.2. Defined Neighbor Classes 375 This document defines Neighbor Class values for common BGP neighbor 376 groupings: 378 o ALL NEIGHBORS 380 * This class is the default Neighbor Class for all BGP peers. 382 * This class is represented by a value of 0 (0x8000). 384 o PEER 386 * This class is typically applied to sessions where a transit- 387 free relationship exists between the two providers. 389 * This class is represented by a value of 1 (0x8001). 391 o CUSTOMER 393 * This class is typically applied to sessions where the remote 394 end of the session is operated by a customer. 396 * This class is represented by a value of 2 (0x8002). 398 o UPSTREAM 400 * This class is typically applied to sessions where the remote 401 end of the session is operated by a network from which you 402 receive transit routes. 404 * This class is represented by a value of 3 (0x8003). 406 o CONFEDERATION PEER 408 * This class is typically applied to sessions where the remote 409 end of the session is part of a confederation. 411 * This class is represented by a value of 4 (0x8004). 413 6. Defined Flexible BGP Community Structures 415 This section defines a number of Structure values which different 416 Type values can inherit. 418 Summary of the Defined Values: 420 o opaque/variable (0x40 or 0xC0) 422 o list of ASN's (0x41 or 0xC1) 424 o list of IPv4 addresses (0x42 or 0xC2) 426 o list of IPv6 addresses (0x43 or OxC3) 428 o list of neighbor_classes (0x44 or 0xC4) 430 Defined Structure can be transitive or non-transitive, they are well 431 known. 433 Opaque/Variable Structure 435 This sort of structure defers interpretation of the community 436 and value field to the Type value. Typically this structure 437 value will be used when the Type value does not have a lot of 438 variations, but rather one structure for the Value Field. 440 This structure is represented by the value 0x00. 442 List of ASN's 444 This structure value means that the Type Field's action is 445 qualified by a list of ASN's, contained in the Value Field. In 446 the case of 2 byte ASN's the value is padded to 4 bytes by 447 inserting 2 octets worth of zeros in the leftmost portion of 448 the value. 450 This structure is represented by the value 0x01. 452 List of IPv4 Addresses 454 This structure value means that the Type Field's action is 455 qualified by a list of IPv4 addresses, contained in the Value 456 Field. 458 This structure is represented by the value 0x02. 460 List of IPv6 Addresses 462 This structure value means that the Type Field's action is 463 qualified by a list of IPv6 addresses, contained in the Value 464 Field. 466 This structure is represented by the value 0x03. 468 List of Neighbor Classes 470 This structure value means that the Type Field's action is 471 qualified by a list of neighbor classes, contained in the Value 472 Field. 474 This structure is represented by the value 0x04. 476 7. Base BGP Flexible Community Type (Opaque Type) 478 This section defines the base BGP community specification. Since the 479 root value of communities is the ability to tag a route with 480 arbitrary information, and then create a system to give that 481 information meaning, the base flexible community type (type 0), is 482 very simple. This base type could also be described as the "opaque 483 type." All actions can be replicated with a well-thought out, 484 provider dependent, implementation of a scheme using this opaque 485 type. 487 Like all flexible communities, this type can be transitive or non- 488 transitive. This is a well known type. 490 0 1 2 3 491 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 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | 0x00,0xC0 | 0x0000 | Originating | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | ASN | Length | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Value Field (0-255 octets) | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 Figure 5: Opaque Type 502 8. Defined Flexible BGP Community Types 504 The Type Field specifies the subgroup that a set of communities 505 belongs to. Typically this subgroup represents an action to be taken 506 on the data. A variety of well-known Type Values follow. 508 8.1. NO_EXPORT 510 This grouping of well-known communities specify a list of ASNs, Peer 511 IPs, or Neighbor Classes NOT to announce a route to. 513 Name: NO_EXPORT 515 Type Code: 0x0001 517 Can Take Structures: 519 o Ox01 (ASN) 521 o 0x02 (IPv4) 523 o 0x03 (IPv6) 525 o 0x04 (neighbor-class) 527 Transitive: Non-Transitive 529 Min Length of Value Field: 2 octets 531 Max Length of Value Field: 254 octets 533 Behavior: 535 All routes received with this community MUST NOT be advertised 536 to the list of ASNs, Peer IPs, or Neighbor Classes contained in 537 the Value Field. 539 Notes: 541 GLOBAL_NO_EXPORT is accomplished by sending a NO_EXPORT Flexible 542 Community with the Neighbor Class of 0x00 (ALL NEIGHBORS). 544 GLOBAL_NO_EXPORT's NO_EXPORT behavior is defined as: All routes 545 received with this community MUST NOT be advertised outside a BGP 546 confederation boundary (a stand-alone autonomous system that is 547 not part of a confederation should be considered a confederation 548 itself.)[RFC1997] 550 This is analogous to the NO_EXPORT community defined in [RFC1997]. 552 8.2. ONLY_EXPORT 554 This grouping of well-known communities specify a list of ASNs, Peer 555 IPs, or Neighbor Classes to announce a route to. 557 Name: ONLY_EXPORT 559 Type Code: 0x0002 561 Can Take Structures: 563 o Ox01 (ASN) 565 o 0x02 (IPv4) 567 o 0x03 (IPv6) 569 o 0x04 (neighbor-class) 571 Transitive: Non-Transitive 573 Min Length of Value Field: 0 octets 575 Max Length of Value Field: 254 octets 577 Behavior: 579 The Value Field contains a list of ASNs, neighbor IP addresses, 580 or Neighbor Classes to which the route should be advertised. 582 The default behavior of a route carrying this community is the 583 same as the GLOBAL_NO_EXPORT behavior, except for the ASNs, 584 IPs, or Neighbor Classes listed in the Value Field. 586 Notes: 588 This community can be used to replicate the NO_ADVERTISE 589 functionality from [RFC1997]. To do so, simply announce 590 ONLY_EXPORT with a Structure of 0x03 or 0x04 (one of the IP 591 address Structures), but with no IP address in the list. This 592 will tell the receiving router that you wish to ONLY_EXPORT this 593 route to NO peer IPs. 595 This community can also be use to replicate the 596 NO_EXPORT_SUBCONFED functionality from [RFC1997]. To do so, 597 simply announce ONLY_EXPORT with a Neighbor Class of CONFEDERATION 598 PEER (4, 0x8004). This will tell the receiving router that you 599 wish to ONLY_EXPORT this route to Confederation Peers. 601 8.3. ANNOUNCE_WITH 603 This group of well-known communities allows a network to announce a 604 community to an ASN beyond those that it directly peers with, 605 assuming its direct peers allow it to transit the community value. 606 This community group has a lot of flexibility, and could be used to 607 nest another ANNOUNCE_WITH community to gain reach greater than 2 608 ASN-hops away. If this is a good idea or not is unknown and is left 609 to further study. The only theoretical restriction to the amount of 610 nesting is that the community cannot exceed the maximum size for the 611 Value Field. 613 Since true transitivity can be obtained by simply setting a bit, this 614 community is mainly useful for propagating NO_EXPORT or ONLY_EXPORT 615 (which are non-transitive) to your neighbor's neighbors. 617 In effect, this community, if allowed by the BGP neighbors in the 618 chain, can be used for an originating network to very specifically 619 control the distribution of its routes. This community type does 620 contain a LOT of rope, and should be used with care. In the end, 621 though, a mistake should only effect the person originating the 622 route. 624 Name: ANNOUNCE_WITH 626 Type Code: 0x0003 628 Can Take Structures: 630 o Ox01 (ASN) 632 o 0x02 (IPv4) 634 o 0x03 (IPv6) 636 o 0x04 (neighbor-class) 638 Transitive: Non-Transitive 640 Min Length of Value Field: 8 octets 642 Max Length of Value Field: 254 octets 644 Behavior: This community's Value Field is split into two sections. 646 * The first section is a variable length field that contains the 647 full community value that you wish to announce. 649 * The second section is a variable length field that contains the 650 list of, ASN's, IP addresses, or neighbor_classes you wish to 651 propagate this community to. If you wish to propagate to all 652 peers, use the ALL NEIGHBORS neighbor class. 654 When a router receives this community value, it should strip the 655 ANNOUNCE_WITH community and announce the underlying community value 656 to its neighbor. 658 8.4. PREPEND 660 This community can be used to ask a BGP peer to prepend its own ASN 661 to its peers. 663 Name: PREPEND 665 Type Code: 0x0004 667 Can Take Structures: 669 o Ox01 (ASN) 671 o 0x02 (IPv4) 673 o 0x03 (IPv6) 675 o 0x04 (neighbor-class) 677 Transitive: Non-Transitive 679 Min Length of Value Field: 3 octets 681 Max Length of Value Field: 254 octets 683 Behavior: This community has 2 sections: 685 * The first section: Is a one-octet value which specifies the 686 number of times that the ASN should prepend its ASN. It is 687 recommended that operators constrain this value to no more than 688 3. Implementations MUST offer the ability for an operator to 689 set a maximum bound for this field. The suggested default is 690 also 3. 692 * The second section: Contains a list of ASNs, peer IPs, or 693 Neighbor Classes to which the originator of this community 694 wishes its peer to prepend its ASN. 696 8.5. The BGP VPN Communities 698 These communities are used mostly for BGP MPLS VPN's. Please see 699 [RFC2547] for more detail on how these VPNs are constructed. 701 Name: ROUTE_TARGET 703 Type Code: 0x0005 705 Can Take Structures: 707 o 0x02 (IPv4) 709 o 0x03 (IPv6) 711 Transitive: Transitive or Non-Transitive 713 Min Length of Value Field: 4 octets 715 Max Length of Value Field: 254 octets 717 Behavior: The Value Field of this community represents a list of 718 the IP addresses where this route is to be announced. 720 Name: ROUTE_ORIGIN 722 Type Code: 0x0006 724 Can Take Structures: 726 o 0x02 (IPv4) 728 o 0x03 (IPv6) 730 Transitive: Transitive or Non-Transitive 732 Min Length of Value Field: 4 octets 734 Max Length of Value Field: 16 octets 736 Behavior: The Value Field of this community represents a list of 737 the IP address where this route is originated. This community can 738 only contain one IP address. 740 Name: LINK_BANDWIDTH 742 Type Code: 0x0007 744 Can Take Structures: 746 o 0x00 (opaque) 748 o Ox01 (ASN) 750 Transitive: Transitive or Non-Transitive 752 Min Length of Value Field: 4 octets 754 Max Length of Value Field: 6 octets 756 Behavior: This community consists of two parts: 758 * The first part represents the bandwidth of the link in bits- 759 per- second, encoded in IEEE floating point format. This part 760 is 4 octets long. 762 * The second part consists of a list of ASNs of the peer whose 763 link bandwidth you wish to propagate. 765 9. New Capability Code for Flexible Communities 767 To ensure compatibility between implementations that may or may not 768 implement this protocol extension, this document defines a new 769 capability. 771 Capability Code: TBD 773 Capability Length: 1 775 Capability Value: 777 * 0x00 for unsupported 779 * 0x01 for supported 781 Capability negotiation is especially important for this attribute 782 because we are creating a transitivity action within an optional, 783 transitive attribute. If an implementation sends a flexible 784 community with the non-transitive bit set within the community to a 785 router that does not support flexible communities, that router will 786 send the community on to its peers when it should not do so. 788 10. Aggregation 790 Aggregation behaves the same as with other community types. 792 By default if a range of routes is to be aggregated and the resultant 793 aggregates path attributes do not carry the ATOMIC_AGGREGATE 794 attribute, then the resulting aggregate should have an Flexible 795 Communities path attribute which contains the set union of all the 796 Flexible Communities from all of the aggregated routes. The default 797 behavior could be overridden via local configuration, in which case 798 handling the Flexible Communities attribute in the presence of route 799 aggregation becomes a matter of the local policy of the BGP speaker 800 that performs the aggregation. 802 11. Operations 804 Flexible Communities are handled operationally in a manner very 805 similar to other community values. 807 A BGP speaker may use the Flexible Communities attribute to control 808 which routing information it accepts or distributes to its peers. 810 The Flexible Community attribute MUST NOT be used to modify the BGP 811 best path selection algorithm in a way that leads to forwarding 812 loops. 814 A BGP speaker receiving a route that doesn't have the Flexible Commu- 815 nities attribute MAY append this attribute to the route when 816 propagating it to its peers. 818 A BGP speaker receiving a route with the Flexible Communities 819 attribute MAY modify this attribute according to the local policy. 820 If a route has a non-transitivity flexible community, then before 821 advertising the route across the Autonomous system boundary the 822 community SHOULD be removed from the route. However, the community 823 SHOULD NOT be removed when advertising the route across the BGP 824 Confederation boundary. 826 A route may carry the BGP Communities attribute as defined in 827 [RFC1997], the Extended BGP Communities attribute as defined in 828 [RFC4360], and the Flexible Communities attribute. In this case the 829 BGP Communities attribute is handled as specified in [RFC1997], the 830 Extended BGP Communities attribute is handled as specified in 831 [RFC4360] and the Flexible Communities attribute is handled as 832 specified in this document. 834 If older community types are present in addition to the flexible 835 community there is the possibility that the information contained may 836 be redundant. Although effort should be made to avoid this 837 situation, if it does occur the BGP Speaker shall prefer the flexible 838 community first, then the extended community second and then the base 839 community. 841 12. Security Considerations 843 This extension to BGP does not change the underlying security issues. 845 13. IANA Considerations 847 The values for the Transitivity Field (1 or 0) are completely defined 848 in this document. 850 The assignment policy for the Structure Field is: 852 o The "L" bit's usage is completely defined in this document. 854 o Values of the Structure Field where the "L" bit is "0" are to be 855 assigned in accordance with the Private Use policy outlined in 856 [RFC2434]. 858 o Values of the Structure Field where the "L" bit is "1" defined in 859 this document are: 0-4 (0x40-0x44 and 0xC1-0xC4). Remaining 860 values in this range are to be assigned using the IETF Consensus 861 policy outlined in [RFC2434]. 863 The assignment policy for the Type Field is: 865 o The "L" bit's usage is completely defined in this document. 867 o Values of the Type Field where the "L" bit is "0" are to be 868 assigned in accordance with the Private Use policy outlined in 869 [RFC2434]. 871 o Values of the Type Field where the "L" but is "1" defined in this 872 document are: 0-7 (0x0000-0x0007). Remaining values in this range 873 are to be assigned using the IETF Consensus policy outlined in 874 [RFC2434]. 876 The assignment policy for Neighbor Classes is: 878 o The "L" bit's usage is completely defined in this document. 880 o Values of the Type Field where the "L" bit is "0" are to be 881 assigned in accordance with the Private Use policy outlined in 882 [RFC2434]. 884 o Values of the Type Field where the "L" but is "1" defined in this 885 document are: 0-4 (0x8000-0x8004). Remaining values in this range 886 are to be assigned using the IETF Consensus policy outlined in 887 [RFC2434]. 889 14. Acknowledgements 891 I would like to thank Tom Barron, Dave Ward and especially Hal 892 Peterson for their valuable comments and feedback. I would also like 893 to thank Brian Haberman. 895 15. Normative References 897 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 898 (BGP-4)", RFC 1771, March 1995. 900 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 901 Communities Attribute", RFC 1997, August 1996. 903 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 904 Requirement Levels", BCP 14, RFC 2119, March 1997. 906 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 907 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 908 October 1998. 910 [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, 911 March 1999. 913 [RFC2842] Chandra, R. and J. Scudder, "Capabilities Advertisement 914 with BGP-4", RFC 2842, May 2000. 916 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 917 Communities Attribute", RFC 4360, February 2006. 919 Authors' Addresses 921 Andrew Lange 922 Alcatel-Lucent 924 Email: andrew.lange@alcatel-lucent.com 926 Jeffrey Haas 927 Juniper Networks 929 Email: jhaas@pfrc.org 931 Keyur Patel 932 Cisco 934 Email: keyupate@cisco.com 936 Shane Amante 937 Level 3 939 Email: shane@castlepoint.net