idnits 2.17.1 draft-raszuk-wide-bgp-communities-05.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4271], [RFC1997]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 6, 2015) is 3329 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) == Missing Reference: 'RFC3765' is mentioned on line 604, but not defined == Outdated reference: A later version (-19) exists of draft-ietf-idr-error-handling-05 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754.1985' == Outdated reference: A later version (-10) exists of draft-ietf-idr-as4octet-extcomm-generic-subtype-06 -- Obsolete informational reference (is this intentional?): RFC 4893 (Obsoleted by RFC 6793) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group R. Raszuk, Ed. 3 Internet-Draft Mirantis Inc. 4 Intended status: Standards Track J. Haas, Ed. 5 Expires: September 7, 2015 Juniper Networks 6 A. Lange, Ed. 7 Alcatel-Lucent 8 S. Amante 9 Apple, Inc. 10 B. Decraene 11 Orange 12 P. Jakma 13 Uni. of Glasgow 14 R. Steenbergen 15 nLayer Communications, Inc. 16 March 6, 2015 18 Wide BGP Communities Attribute 19 draft-raszuk-wide-bgp-communities-05 21 Abstract 23 Route tagging plays an important role in external BGP [RFC4271] 24 relations, in communicating various routing policies between peers. 25 It is also a very common best practice among operators to propagate 26 various additional information about routes intra-domain. The most 27 common tool used today to attach various information about routes is 28 through the use of BGP communities [RFC1997]. 30 Such information is important to allow BGP speakers to perform some 31 mutually agreed actions without the need to maintain a separate 32 offline database for each tuple of prefix and associated set of 33 action entries. 35 This document defines a new encoding which will enhance and simplify 36 what can be accomplished today with the use of BGP communities. The 37 most important addition this specification makes over currently 38 defined BGP communities is the ability to specify, carry as well as 39 use for execution an operator's defined set of parameters. It also 40 provides an extensible platform for any new community encoding needs 41 in the future. 43 Requirements Language 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC 2119 [RFC2119]. 49 Status of This Memo 51 This Internet-Draft is submitted in full conformance with the 52 provisions of BCP 78 and BCP 79. 54 Internet-Drafts are working documents of the Internet Engineering 55 Task Force (IETF). Note that other groups may also distribute 56 working documents as Internet-Drafts. The list of current Internet- 57 Drafts is at http://datatracker.ietf.org/drafts/current/. 59 Internet-Drafts are draft documents valid for a maximum of six months 60 and may be updated, replaced, or obsoleted by other documents at any 61 time. It is inappropriate to use Internet-Drafts as reference 62 material or to cite them other than as "work in progress." 64 This Internet-Draft will expire on September 7, 2015. 66 Copyright Notice 68 Copyright (c) 2015 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents 73 (http://trustee.ietf.org/license-info) in effect on the date of 74 publication of this document. Please review these documents 75 carefully, as they describe your rights and restrictions with respect 76 to this document. Code Components extracted from this document must 77 include Simplified BSD License text as described in Section 4.e of 78 the Trust Legal Provisions and are provided without warranty as 79 described in the Simplified BSD License. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 84 1.1. Protocol Summary . . . . . . . . . . . . . . . . . . . . 4 85 2. Wide Community Atoms . . . . . . . . . . . . . . . . . . . . 5 86 2.1. The Autonomous System number list atom . . . . . . . . . 6 87 2.2. The IPv4 and IPv6 prefix list atoms . . . . . . . . . . . 6 88 2.3. The Integer list atom . . . . . . . . . . . . . . . . . . 6 89 2.4. The IEEE Floating Point Number list atom . . . . . . . . 7 90 2.5. The Neighbor Class list atom . . . . . . . . . . . . . . 7 91 2.6. The User-defined Class list atom . . . . . . . . . . . . 7 92 2.7. The UTF-8 String atom . . . . . . . . . . . . . . . . . . 8 93 3. Wide BGP Community Attribute . . . . . . . . . . . . . . . . 8 94 3.1. Wide BGP Community Attribute Container Header . . . . . . 8 95 4. Container Type 1: Wide Community . . . . . . . . . . . . . . 10 96 4.1. Community Value . . . . . . . . . . . . . . . . . . . . . 10 97 4.2. Source AS Number . . . . . . . . . . . . . . . . . . . . 10 98 4.3. Context AS Number . . . . . . . . . . . . . . . . . . . . 10 99 4.4. Wide Community Target(s) TLV . . . . . . . . . . . . . . 11 100 4.5. Wide Community Exclude Target(s) TLV . . . . . . . . . . 12 101 4.6. Wide Community Parameter(s) TLV . . . . . . . . . . . . . 12 102 4.7. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 13 103 5. The AS-4 List Generic Wide BGP Community . . . . . . . . . . 13 104 5.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 13 105 6. Well Known Standard BGP Communities . . . . . . . . . . . . . 13 106 7. Operational Considerations . . . . . . . . . . . . . . . . . 14 107 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 14 108 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 109 9.1. Example Wide Community Definition . . . . . . . . . . . . 14 110 9.2. Example Wide Community Encoding . . . . . . . . . . . . . 15 111 10. Security considerations . . . . . . . . . . . . . . . . . . . 17 112 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 113 12. Change History . . . . . . . . . . . . . . . . . . . . . . . 18 114 13. Outstanding Issues . . . . . . . . . . . . . . . . . . . . . 19 115 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 116 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 117 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 118 16.1. Normative References . . . . . . . . . . . . . . . . . . 20 119 16.2. Informative References . . . . . . . . . . . . . . . . . 21 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 122 1. Introduction 124 RFC 1997 [RFC1997] defines the BGP Community Attribute. This 125 attribute is used as a tool to carry additional information in BGP 126 routes which may help to automate peering administration. The BGP 127 Communities Attribute consists of one or more sets of four octet 128 values, where each specifies a different community. Except for two 129 reserved ranges, the encoding of community values mandates that the 130 first two octets are to contain the Autonomous System number, with 131 the next two octets containing some locally defined value. 133 With the introduction of 4-octet Autonomous System numbers by RFC 134 4893 [RFC4893] it became obvious that BGP Communities as specified in 135 RFC 1997 will not be able to accommodate new AS encoding. In fact 136 RFC 4893 explicitly recommends use of four octets AS specific 137 [RFC5668] extended communities [RFC4360] as a way to encode new 4 138 octet AS numbers. 140 While the encoding of 4 octet AS numbers is being addressed by 141 [I-D.ietf-idr-as4octet-extcomm-generic-subtype], neither the base BGP 142 communities (standard or extended) nor as4octet-extcomm-generic 143 document define a sufficient level of encoding freedom which could be 144 of practical use. The authors believe that defining a new BGP Path 145 Attribute, with the ability to contain locally defined parameters 146 will enhance the current level of network policies, as well as 147 simplify BGP policy management. The proposed simple encoding will 148 also facilitate the delivery of new network services without a need 149 to define a new BGP extension each time. 151 When defining any new type of tool there is always a unique 152 opportunity to specify a subset of well recognized behaviors. Lists 153 of the current most commonly used BGP communities, as well as 154 provision for a new registry for future definitions will be contained 155 in a separate document. 157 1.1. Protocol Summary 159 Each Wide BGP Community consists of three main parts: 161 1. A Container Header. This header is defined in Section 4. 162 The Container Header encodes: 164 * Container Type. One Type is defined in this document. 165 * Flags to control behavior. 166 * Hop Count to control the degree of Community propagation 167 * Length 169 2. The Community itself, defined as a type of Container. The Type 1 170 Wide Community is defined in Section 4. 171 The Type 1 Wide Community contains: 173 * Community Value: This section defines the action that an 174 operator wishes a router to take. 175 * Source AS: This is the AS originating the community. 176 * Context AS: This its the AS context from which community 177 should be interpreted. 178 * Target(s): This is an optional list that encodes where the 179 community's action should be taken. 180 * Exclude Target(s): This is an optional list that encodes where 181 the community's actions should not be taken. 182 * Parameters: This is an optional list that encodes additional 183 information that the community's action needs to execute 184 properly. 186 3. Community Atoms. These are values and lists of values that are 187 common across community actions. They are defined in Section 2. 189 2. Wide Community Atoms 191 Wide BGP communities will act on and hence need to encode some 192 distinct atoms of data. These are encoded as TLVs, where each TLV 193 has the following format: 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+ 198 | Type | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Length | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Value (variable) | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 The Type field contains a value of 1-254. The values 0 and 255 are 206 reserved for future use. The TLV types are to be assigned and 207 maintained by IANA registry. 209 The Length represents the total length of a given TLV's value field 210 in octets. 212 The Value field contains the TLV value. 214 Supported format of the TLVs can be: 216 Type 1: Autonomous System number list 217 Type 2: IPv4 prefix (1 octet prefix length + prefix) list 218 Type 3: IPv6 prefix (1 octet prefix length + prefix) list 219 Type 4: Integer list 220 Type 5: IEEE Floating Point Number list 221 Type 6: Neighbor Class list 222 Type 7: User-defined Class list 223 Type 8: UTF-8 String 225 The semantics of a given atom will depend upon the context in which 226 it is used, as defined by the containing wide community. 228 In the following sections defining the different atoms, validation 229 rules for the Length of the atom will be presented. If the Length of 230 the atom does not match the rules for that atom, it SHALL be 231 considered malformed. (See Section 8.) 233 2.1. The Autonomous System number list atom 235 This atom represents a list of Autonomous System numbers, each 4 236 octets in size. The minimum Length of this atom is 4 octets. The 237 Length MUST be a multiple of 4. 239 For consistent treatment, all AS numbers MUST be encoded as 4 octet 240 values. When encoding two octet ASes, the first two octets of this 241 four octet value MUST be filled with zeros. 243 Two special values are reserved for the Autonomous System atoms: 245 0x00000000 - to indicate "No Autonomous Systems". 246 0xFFFFFFFF - to indicate "All Autonomous Systems". 248 2.2. The IPv4 and IPv6 prefix list atoms 250 This atom represents a list of IPv4 or IPv6 prefix. IPv4 and IPv6 251 prefix atom values are encoded in the same format used by BGP NLRI in 252 Section 4.3 of [RFC4271]. 254 +---------------------------+ 255 | Prefix Length (1 octet) | 256 +---------------------------+ 257 | Prefix (variable) | 258 +---------------------------+ 260 The Prefix Length for IPv4 prefixes must be in the range of 0..32. 262 The Prefix Length for IPv6 prefixes must be in the range of 0..128. 264 The Length field must be able to accommodate the list of prefixes 265 according to the encoding rules. If the Length cannot fully 266 accommodate the required number of octets to encode the Prefix Length 267 and the Prefix, the atom is considered malformed. 269 2.3. The Integer list atom 271 This atom represents a list of Integers. Integers are a fixed Length 272 of 4 octets and are stored in network byte order. 274 The minimum Length of the Integer list atom is 4 octets. The Length 275 MUST be a multiple of 4. 277 2.4. The IEEE Floating Point Number list atom 279 This atom represents a list of floating point numbers. Floating 280 point numbers are a fixed Length of 4 octets and are stored in 281 [IEEE.754.1985] format. 283 This atom represents a list of floating point numbers. 285 The minimum Length of the Floating Point Number list atom is 4 286 octets. The Length MUST be a multiple of 4. 288 2.5. The Neighbor Class list atom 290 The Neighbor Class list atom represents a classification of a BGP 291 peering session, each 4 octets in size. This class currently can 292 contain three values: 294 1 - Peer: This class is typically applied to sessions where a 295 transit-free relationship exists between two 296 providers. 297 2 - Customer: This class is typically applied to sessions where 298 the remote end of the session is operated by a 299 customer. 300 3 - Upstream: This class is typically applied to sessions where the 301 remote end of the session is operated by a network 302 from which you receive transit routes. 304 The Neighbor Class list atom represents a classification of a BGP 305 peering session. 307 The minimum Length of the Neighbor Class list atom is 4 octets. The 308 Length MUST be a multiple of 4. 310 2.6. The User-defined Class list atom 312 Similar to the Neighbor Class atom, the User-defined Class list atom 313 represents a classification of a network property. The exact 314 property definition is up to the semantics of the defining Autonomous 315 System. The semantics governing a given User-defined Class list are 316 defined by the Context AS Number. 318 Examples of User-defined Class properties include geography (East, 319 West), continent (North America, Asia, Europe), etc. Similar to the 320 [RFC1997] BGP Communities, it is necessary that the Context AS 321 provide a registry of the value and the semantics of a given 322 community. 324 The minimum Length of the User-defined Class list atom is 4 octets. 325 The Length of this atom MUST be a multiple of 4. 327 2.7. The UTF-8 String atom 329 The UTF-8 String atom represents an arbitrary Unicode string in UTF-8 330 [RFC3629] format. The Length is required to be of sufficient size to 331 carry the UTF-8 string in the Value field. 333 Implementations MUST be prepared for truncated/improperly formed 334 UTF-8 strings. When detecting such a string, the implementation 335 should remove trailing octets of a multi-octet sequence in order to 336 have a well-formed string. 338 Implementations MUST be prepared to receive empty (zero-Length) UTF-8 339 String atoms as they may be used as Parameters. 341 3. Wide BGP Community Attribute 343 This document defines a new BGP Path Attribute, the Wide BGP 344 Community. The attribute type code is (TBA by IANA). 346 The Wide BGP Community Attribute is an optional, transitive BGP 347 attribute, and may be present only once in the BGP UPDATE message. 349 The attribute contains a number of typed containers. Any given 350 container type may appear multiple times, unless that container 351 type's definition specifies otherwise. 353 3.1. Wide BGP Community Attribute Container Header 355 Containers always start with the following header: 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Type | Flags | Hop Count | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Length | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 This document defines one Type code - Type 1. See the Section 11 for 366 information on additional type registration policies. 368 +------+-------+----------------------------------------------------+ 369 | Bit | Value | Meaning | 370 +------+-------+----------------------------------------------------+ 371 | 0 | 0 | Local community value. | 372 | | 1 | Registered community value. | 373 | 1 | 0 | Do not decrement Hop Count field across | 374 | | | confederation boundaries. | 375 | | 1 | Decrement Hop Count field across confederation | 376 | | | boundaries. | 377 | 2..7 | - | MUST be zero when sent and ignored upon receipt. | 378 +------+-------+----------------------------------------------------+ 380 Flags are defined globally, to apply to all wide community container 381 types. 383 Table 1: Flags 385 Bit 0 (aka R bit) set (value 1) indicates that the given container 386 carries a Wide BGP Community which is registered with IANA. When not 387 set (value 0) it indicates that community value which follows is 388 locally assigned with a local meaning. 390 Bit 1 (aka C bit) is used to manage the propagation scope of a given 391 Wide BGP Community across confederation boundaries. When not set 392 (value of 0), the Hop Count field is not considered at the sub-AS 393 boundaries. When set (value of 1), sub-AS border router follows the 394 same procedure regarding the handling of the Hop Count field as 395 applicable to ASBR at the domain boundary. 397 The Hop Count field represents the forwarding radius, in units of AS 398 hops, for the given Wide BGP Community. A Hop Count value of zero 399 indicates that this wide community must not cross any further AS 400 boundaries. At each AS boundary, when propagating a given wide 401 community over an EBGP session, the Hop Count field MUST be 402 decremented by the sending EBGP speaker. 404 The exact same decrement procedures described above apply also to 405 sub-confederation boundaries when the bit 1's flag is set to 1. 407 The special value of 0xFF indicates that the enclosed community may 408 always be propagated over an EBGP boundary. A Hop Count value of 409 0xFF MUST NOT be decremented during propagation. 411 The Length field represents the total length of a given container in 412 octets. 414 4. Container Type 1: Wide Community 416 The Wide BGP Community Type 1 container is of variable size (but 417 minimum length 12) and is encoded as follows: 419 0 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Registered/Local Community Value | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Source AS Number | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Context AS Number | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Wide Community Target(s) TLV (optional) | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Wide Community Exclude Target(s) TLV (optional) | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Wide Community Parameter(s) TLV (optional) | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 Figure 4: Wide BGP Community Type 1 437 4.1. Community Value 439 Community Value: 4 octets 441 The Wide BGP Community value indicates what set of actions a 442 router is requested to take upon reception of a route containing 443 this community. The semantics of this value depend on whether 444 this is a private/local community or registered. 446 4.2. Source AS Number 448 Source Autonomous System Number: 4 octets 450 The Autonomous System number which indicates the originator of 451 this Wide BGP Community. 453 When the Autonomous System is a two octet number the first two 454 octets of this 4 octet value MUST be filled with zeros. 456 4.3. Context AS Number 458 Context Autonomous System Number: 4 octets 459 The Autonomous System number that indicates the context of the 460 Registered/Local Value. For Wide Community Containers that are 461 Locally defined, the Context Autonomous System number provides the 462 context for the Community Value and thus the meaning of the community 463 as well as any User-defined Classes for that Context AS. 465 For Registered Community Containers, the Context Autonomous System 466 number MAY be utilized to provide specific meaning for that 467 Registered community. When no such context is implied, this field 468 MUST be 0. 470 When the wide community is locally registered, the Context Autonomous 471 System Number indicates the AS that defines the format of this wide 472 community for the given Local Value. (In other words, value 1 will 473 likely refer to different formats for AS 1 vs. AS 2.) 475 4.4. Wide Community Target(s) TLV 477 The Wide Community Target(s) TLV (Type 1) contains a list of a Wide 478 Community atoms. 480 Wide Community Targets define the matching criteria for the 481 community. A given wide community may have a number of targets that 482 it applies to. The semantics of these targets will vary on a per 483 community basis. Depending on the definition of the community, 484 targets may be optional. 486 The value field of the Wide Community Target(s) TLV is a series of 487 Wide Community Atom TLVs. The semantics of any given atom TLV MUST 488 be part of the definition of a given Wide Community. 490 Typically, Wide Community Targets consist of a series of atoms that 491 have "match any" semantics. Thus, if any given target matches per 492 the semantics of that atom for the community, the community is 493 considered to match and the action defined by the community should be 494 executed. 496 When no Target(s) TLV is specified, it is considered "match all". 498 If the semantics of a given atom is undefined for the community in 499 question, it MUST be ignored. 501 When no targets are required by the definition of a given Wide 502 Community, the Wide Community Target(s) TLV SHOULD NOT be encoded in 503 the community. Implementations MUST be prepared to accept a Wide 504 Community Target(s) TLV with an empty value field. 506 4.5. Wide Community Exclude Target(s) TLV 508 The Wide Community Exclude Target(s) TLV (Type 2) contains a list of 509 a Wide Community atoms. 511 Wide Community Exclude Targets define criteria by which the community 512 is considered to NOT match. Depending on the semantics of the Wide 513 Community, Exclude Target(s) may be optional. 515 The semantic of the Wide Community Exclude Target(s) is to match all 516 specified Target(s) with the exception of those listed in this TLV. 518 The value field of the Wide Community Exclude Target(s) TLV is a 519 series of Wide Community Atom TLVs. The semantics of any given atom 520 TLV MUST be part of the definition of a given Wide Community. 522 If the semantics of a given atom is undefined for the community in 523 question, it MUST be ignored. 525 If the Wide Community Target(s) TLV and the Wide Community Exclude 526 Target(s) TLV have conflicting semantics, priority MUST be given to 527 the Wide Community Exclude Target(s) TLV. 529 When no exclude targets are required by the definition of a given 530 Wide Community, the Wide Community Exclude Target(s) TLV SHOULD NOT 531 be encoded in the community. Implementations MUST be prepared to 532 accept a Wide Community Exclude Target(s) TLV with an empty value 533 field. 535 4.6. Wide Community Parameter(s) TLV 537 The Wide Community Parameter(s) TLV (Type 3) contains a list of a 538 Wide Community atoms. 540 A given wide community may have parameters which are used as inputs 541 for executing actions defined for that community. These parameters, 542 and any constraints implied by the parameters, MUST be defined by the 543 wide community definition. Parameters consist of an ordered set of 544 atom sub-TLVs. The semantics of any specific positional instance of 545 an atom MUST be defined by the wide community. 547 If it is the case that a parameter for a given community is of an 548 unexpected type or length, the community MUST be ignored. 550 If it is the case that there are too many or two few parameters for a 551 given community, the community MUST be ignored. 553 When no parameters are required by the definition of a given Wide 554 Community, the Wide Community Paramters TLV SHOULD NOT be encoded in 555 the community. Implementations MUST be prepared to accept a Wide 556 Community Parameter TLV with an empty value field. 558 4.7. Usage 560 The detailed interpretation of the targets or parameters SHALL be 561 provided when describing given community type in a separate document 562 or when locally defined by an operator. 564 5. The AS-4 List Generic Wide BGP Community 566 In standard [RFC1997] BGP Communities, a commonly deployed format is 567 AS:0x0000-0xFFFF. The left-hand-side AS is the context AS while the 568 right-hand-side represents an action intended to be taken upon that 569 AS. While the [I-D.ietf-idr-as4octet-extcomm-generic-subtype] 570 Extended Community format is intended to address the use cases where 571 the right-hand-side represents a semi-opaque integer value, operators 572 that desire to utilize the right-hand-side as an Autonomous System 573 Number have been unable to do so. 575 In the AS:0x0000-0xFFFF format, there are no explicit semantics on 576 the action for a given right-hand-side. The semantics are implicit 577 to the Autonomous System number itself. While such a format doesn't 578 take advantage of the more flexible semantics of Wide BGP 579 Communities, the format is capable of addressing this operational 580 need. 582 This document defines a Registered Wide BGP Community to address that 583 need. 585 5.1. Definition 587 Community Value: 1 - AS-4 List Generic Wide BGP Community 588 Source AS Number: 589 Context AS Number: 590 Wide Community Target(s): 591 Wide Community Exclude Target(s): 592 Wide Community Parameter(s): 594 6. Well Known Standard BGP Communities 596 According to RFC 1997, as well as IANA's Well-Known BGP Communities 597 registry, the following BGP communities are defined to have global 598 significance: 600 0xFFFF0000 planned-shut [draft-francois-bgp-gshut] 601 0xFFFFFF01 NO_EXPORT [RFC1997] 602 0xFFFFFF02 NO_ADVERTISE [RFC1997] 603 0xFFFFFF03 NO_EXPORT_SUBCONFED [RFC1997] 604 0xFFFFFF04 NOPEER [RFC3765] 606 This document recommends for simplicity as well as for avoidance of 607 backward compatibility issues the continued use of BGP Standard 608 Community Attribute type 8 as defined in RFC 1997 to distribute non 609 Autonomous System specific Well-Known BGP Communities. 611 For the same reason, this document does not intended to obsolete the 612 currently defined and deployed BGP Extended Communities. 614 7. Operational Considerations 616 Having two different ways to propagate locally assigned BGP 617 communities, one via the use of Standard BGP Communities and the 618 other one via the use of Wide BGP Communities, may seem to 619 potentially cause problems when considering propagation of 620 conflicting actions. However, even at present, an operator may 621 append Standard BGP Communities with conflicting information. It is 622 therefore recommended that any implementation, in supporting both 623 standard and Wide BGP communities, allow for their easy inbound and 624 outbound processing. The actual execution of all communities should 625 be treated as a union and, if supported by an implementation, their 626 execution permissions are to be a local configuration matter. 628 8. Error Handling 630 If any atom in a Wide Community container's Exclude Targets TLV is 631 unrecognized, no actions should be taken for that Wide Community. 632 While the Targets TLV is meant to be inclusive, the Exclude Targets 633 TLV is meant to be proscriptive of applying the action. 635 If any Wide Community container or atoms contained therein are 636 determined to be malformed, the Wide Community Path attribute must be 637 considered malformed. BGP implementations should use "treat-as- 638 withdraw" semantics as defined in [I-D.ietf-idr-error-handling]. 640 9. Example 642 9.1. Example Wide Community Definition 644 An operator of an AS 64496, wishes to locally define a Wide Community 645 with the semantics of permitting AS_PATH prepending with targets that 646 include AS numbers of peer ASes and peers who have been marked with a 647 set of enumerated city locations. 649 AS 64496 has established a registered set of values to use for its 650 User-defined Class: 652 100 - Amsterdam 653 101 - New York 654 102 - San Francisco 655 103 - Tokyo 656 104 - Moscow 658 Target semantics: 660 The Autonomous System Number list atom refers to the target peer 661 AS Numbers. 663 The User-defined Class for AS 64496 has been defined elsewhere and 664 the values 100..104 may be used for this locally defined Wide 665 Community. 667 The Targets TLV MUST contain at least one entry. 669 The Exclude Targets TLV MAY contain entries of the above supported 670 atoms. 672 The semantics of all other atoms are undefined for this community. 674 Parameter semantics: 676 The parameter TLV shall consist of exactly one Integer atom value 677 that is constrained to have a value of 2..8. 679 9.2. Example Wide Community Encoding 681 AS_PATH prepend 4 TIMES TO AS 2424, AS 8888, to peers marked as 682 Amsterdam (100) or to peers marked Moscow (104), but not to peers 683 in New York (101). 685 Use Hop Count 0 to request the receiving router to not propagate 686 this wide community. 688 Locally community value (flag bit 0 = 0). 689 Do not decrement Hop Count field across confederation boundaries 690 (0) 692 Local community 1 for sample AS 64496. 694 0 1 2 3 695 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 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Container Type 1 (1) | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 |0 0 0 0 0 0 0 0| 700 +-+-+-+-+-+-+-+-+ 701 | Hop Count: 0 | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Length: 57 | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Community: LOCAL PREPEND ACTION CATEGORY 1 | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Own ASN 64496 | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Context ASN# 64496 | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Target TLV (1)| Length: 22 | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | ASN List (2) | Length: 8 | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Target ASN# 2424 | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Target ASN# 8888 | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | User List(7) | Length: 8 | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | Amsterdam 100 | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Moscow 104 | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 |ExcTargetTLV(2)| Length: 7 | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | User List(7) | Length: 4 | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | New York 101 | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Param TLV (3) | Length: 7 | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Integer (4) | Length: 4 | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Prepend # 4 | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 10. Security considerations 740 All the security considerations for BGP Communities as well as for 741 BGP RFCs apply here. 743 Given the flexibility and power offered by Wide BGP communities, it 744 is important to consider the additional possibilities allowed by 745 their definition. In particular, for locally defined Wide BGP 746 Communities, it may be wise to restrict the range of parameters. For 747 registred Wide BGP Communities, the security considerations of the 748 document defining them MUST address issues specific to those newly 749 defined Wide Communities. 751 Security considerations specific to Wide BGP Communities will be 752 discussed in a later revision of this draft. 754 11. IANA Considerations 756 This document defines a new BGP Path Attribute called Wide BGP 757 Community Attribute. For this new type IANA is to allocate a new 758 value in the corresponding registry: 760 Registry Name: BGP Path Attributes 762 This document makes the following assignments for the optional, 763 transitive Wide BGP Communities Attribute: 765 Name Type Value 766 ---- ---------- 767 Wide BGP Community Attribute TBA 769 This document requests IANA to define and maintain a new registry 770 named: "Wide BGP Communities Attribute Container Types". 772 The pool of: 0x0000-0xFFFF has been defined for its allocations. The 773 allocation policy is on a first come, first served basis. 775 This document makes the following assignments for the Wide BGP 776 Communities Container Types values: 778 Name Type Value 779 ---- ---------- 780 Reserved 0x0000 781 Type 1, Wide BGP Community 0x0001 782 Types 2-1023 to be allocated using IETF Consensus 783 Types 1024-64511 to be allocated first come, first served 784 Types 64512-65534 are reserved for experimental use 785 Reserved 0xFFFF 787 This document requests IANA to define and maintain a new registry 788 named: "Wide BGP Communities Atom Types". The pool of 0x0000-0xFFFF 789 has been defined for its allocations. 791 This document makes the following assignments for the Wide BGP 792 Communities Atom Type values: 794 Name Type Value 795 ---- ---------- 796 Reserved 0x00 797 Autonomous System Number List 0x01 798 IPv4 Prefix list 0x02 799 IPv6 Prefix list 0x03 800 Integer list 0x04 801 IEEE Floating Point Number list 0x05 802 Neighbor Class list 0x06 803 User-defined Class list 0x07 804 UTF-8 string 0x08 805 Reserved 0xFF 807 This document requests IANA to define and maintain a new registry 808 named: "Registered Wide BGP Communities". The pool of 809 0x00000000-0FFFFFFFF has ben defined for its allocation. 811 This document makes the following assignments for the Registered Wide 812 BGP Communities: 814 Name Type Value 815 ---- ---------- 816 Reserved 0x00 817 AS-4 List Generic Wide BGP Community 0x01 818 Reserved 0xFFFFFFFF 820 Values 2-1023 are to be allocated using IETF Consensus. Values 821 64512-65534 are reserved for experimental use. All other values are 822 available on a first-come, first served basis. 824 12. Change History 826 Changes from -03 via -04 to -05: 828 Update the Introduction. 830 Substantial re-work of atom types removing proposed Group 831 container and moving atoms to be lists. 833 Added the Exclude Targets TLV to the Wide Community container. 835 Added a section on error handling. 837 Updated the example. 839 Changes from -02 to -03: 841 Removed C and R named bit fields originally from -00. 843 Rename Target AS field to Context AS. 845 Make Integer Atom a fixed 4 octets in length. 847 Add Neighbor Class Atom 849 Rename TTL to Hop Count 851 Changes from -01 to -02: 853 The Type field has been expanded to 2 octets. 855 The Length field has been moved to the common header. 857 Changed format to use TLVs. 859 Added atom TLV to define well defined syntactic items. 861 Added TLVs to distinguish targets from parameters. 863 Various editorial changes to language. 865 13. Outstanding Issues 867 The following are known issues that have yet to be resolved in this 868 draft: 870 o The interaction of the Container TTL field with VPN peers. 872 o The name Wide Communities is overloaded in this document. The 873 scope of this feature has evolved since the initial -00 of the 874 draft. The general feature of a containerized BGP Community 875 extension and the Type 1 container, the Wide community, currently 876 share names. "There are only two hard things in Computer Science: 877 cache invalidation and naming things." 879 14. Contributors 881 The following people contributed significantly to the content of the 882 document: 884 Shintaro Kojima 885 OTEMACHI 1st. SQUARE EAST TOWER, 3F 886 1-5-1, Otemachi, 887 Chiyoda-ku, Tokyo 100-0004 888 Japan 889 Email: koji@mfeed.ad.jp 891 Juan Alcaide 892 Cisco Systems 893 Research Triangle Park, NC 894 United States 895 Email: jalcaide@cisco.com 897 Burjiz Pithawala 898 Cisco Systems 899 170 West Tasman Dr 900 San Jose, CA 901 United States 902 Email: bpithaw@cisco.com 904 Saku Ytti 905 TDC Oy 906 Mechelininkatu 1a 907 00094 TDC 908 Finland 909 Email: ytti@tdc.net 911 15. Acknowledgments 913 This document owes draft-lange-flexible-bgp-communities a debt for 914 the inspiration of many features contained herein. 916 The authors would like to thank Enke Chen, Pedro Marques and Alton Lo 917 for their valuable input. 919 16. References 921 16.1. Normative References 923 [I-D.ietf-idr-error-handling] 924 Scudder, J., Chen, E., Mohapatra, P., and K. Patel, 925 "Revised Error Handling for BGP UPDATE Messages", draft- 926 ietf-idr-error-handling-05 (work in progress), February 927 2014. 929 [IEEE.754.1985] 930 Institute of Electrical and Electronics Engineers, 931 "Standard for Binary Floating-Point Arithmetic", IEEE 932 Standard 754, August 1985. 934 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 935 Requirement Levels", BCP 14, RFC 2119, March 1997. 937 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 938 10646", STD 63, RFC 3629, November 2003. 940 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 941 Protocol 4 (BGP-4)", RFC 4271, January 2006. 943 16.2. Informative References 945 [I-D.ietf-idr-as4octet-extcomm-generic-subtype] 946 Rao, D., Mohapatra, P., and J. Haas, "Generic Subtype for 947 BGP Four-octet AS specific extended community", draft- 948 ietf-idr-as4octet-extcomm-generic-subtype-06 (work in 949 progress), October 2012. 951 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 952 Communities Attribute", RFC 1997, August 1996. 954 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 955 Communities Attribute", RFC 4360, February 2006. 957 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 958 Number Space", RFC 4893, May 2007. 960 [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS 961 Specific BGP Extended Community", RFC 5668, October 2009. 963 Authors' Addresses 964 Robert Raszuk (editor) 965 Mirantis Inc. 966 615 National Ave. #100 967 Mt View, CA 94043 968 USA 970 Email: robert@raszuk.net 972 Jeffrey Haas (editor) 973 Juniper Networks 974 1194 N.Mathilda Ave 975 Sunnyvale, CA 94089 976 US 978 Email: jhaas@juniper.net 980 Andrew Lange (editor) 981 Alcatel-Lucent 982 777 E. Middlefield Road 983 Mountain View, CA 94043 984 US 986 Email: andrew.lange@alcatel-lucent.com 988 Shane Amante 989 Apple, Inc. 990 1 Infinite Loop 991 Cupertino, CA 95014 992 US 994 Email: amante@apple.com 996 Bruno Decraene 997 Orange 998 38-40 rue du General Leclerc 999 Issy Moulineaux cedex 9 92794 1000 France 1002 Email: bruno.decraene@orange.com 1003 Paul Jakma 1004 University of Glasgow 1005 School of Computing Science 1006 Sir Alwyn Williams Building 1007 University of Glasgow 1008 Glasgow G12 8QQ 1009 UK 1011 Email: paulj@dcs.gla.ac.uk 1013 Richard A Steenbergen 1014 nLayer Communications, Inc. 1015 209 W Jackson Blvd 1016 Chicago, IL 60606 1017 US 1019 Email: ras@nlayer.net