idnits 2.17.1 draft-ietf-idr-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 (July 2, 2018) is 2117 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 647, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754.1985' Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 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 Bloomberg LP 4 Intended status: Standards Track J. Haas, Ed. 5 Expires: January 3, 2019 Juniper Networks 6 A. Lange, Ed. 7 Nokia 8 B. Decraene, Ed. 9 Orange 10 S. Amante 11 Apple, Inc. 12 P. Jakma 13 Hewlett Packard Enterprise 14 July 2, 2018 16 BGP Community Container Attribute 17 draft-ietf-idr-wide-bgp-communities-05 19 Abstract 21 Route tagging plays an important role in external BGP [RFC4271] 22 relations, in communicating various routing policies between peers. 23 It is also a very common best practice among operators to propagate 24 various additional information about routes intra-domain. The most 25 common tool used today to attach various information about routes is 26 through the use of BGP communities [RFC1997]. 28 This document defines a new encoding which will enhance and simplify 29 what can be accomplished today with the use of BGP communities. The 30 most important addition this specification makes over currently 31 defined BGP communities is the ability to specify, carry as well as 32 use for execution an operator's defined set of parameters. It also 33 provides an extensible platform for any new community encoding needs 34 in the future. 36 Requirements Language 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in RFC 2119 [RFC2119]. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on January 3, 2019. 59 Copyright Notice 61 Copyright (c) 2018 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . 4 78 2.1. BGP Community Container Common Header . . . . . . . . . . 4 79 2.2. Community Containers . . . . . . . . . . . . . . . . . . 5 80 2.2.1. Type 1: BGP Wide Community . . . . . . . . . . . . . 5 81 2.3. BGP Community Container Atoms . . . . . . . . . . . . . . 5 82 3. BGP Community Container Attribute . . . . . . . . . . . . . . 5 83 3.1. BGP Community Container Attribute Common Header . . . . . 6 84 4. BGP Community Container, Type 1: BGP Wide Community . . . . . 7 85 4.1. Community Value . . . . . . . . . . . . . . . . . . . . . 7 86 4.2. Source AS Number . . . . . . . . . . . . . . . . . . . . 8 87 4.3. Context AS Number . . . . . . . . . . . . . . . . . . . . 8 88 4.4. BGP Wide Community TLVs . . . . . . . . . . . . . . . . . 8 89 4.4.1. Sub-Type 1, BGP Wide Community Target(s) TLV . . . . 9 90 4.4.2. Sub-Type 2, BGP Wide Community Exclude Target(s) TLV 9 91 4.4.3. Sub-Type 3, BGP Wide Community Parameter(s) TLV . . . 10 92 4.4.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . 11 93 5. BGP Community Container Atoms . . . . . . . . . . . . . . . . 11 94 5.1. Atom Type 1, The Autonomous System Number List . . . . . 12 95 5.2. Atom Types 2 and 3, The IPv4 and IPv6 Prefix Lists . . . 12 96 5.3. Atom Type 4, The Integer32 List . . . . . . . . . . . . . 13 97 5.4. Atom Type 5, The IEEE Floating Point Number List . . . . 13 98 5.5. Atom Type 6, The Neighbor Class List . . . . . . . . . . 13 99 5.6. Atom Type 7, The User-defined Class List . . . . . . . . 13 100 5.7. Atom Type 8, the UTF-8 String . . . . . . . . . . . . . . 14 101 6. Well Known Standard BGP Communities . . . . . . . . . . . . . 14 102 7. Operational Considerations . . . . . . . . . . . . . . . . . 14 103 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 15 104 8.1. General Error Handling for BGP Community Containers . . . 15 105 8.2. BGP Wide Community Container Error Handling . . . . . . . 15 106 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 107 9.1. Example Type 1 Wide Community Definition . . . . . . . . 15 108 9.2. Example Type 1 BGP Wide Community Encoding . . . . . . . 16 109 10. Security considerations . . . . . . . . . . . . . . . . . . . 17 110 10.1. BGP Community Container Security Considerations . . . . 18 111 10.2. BGP Wide Community Security Considerations . . . . . . . 18 112 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 113 11.1. BGP Community Container Attribute . . . . . . . . . . . 18 114 11.2. BGP Community Container Atoms Types . . . . . . . . . . 18 115 11.3. BGP Community Container Neighbor Class List Atom Types . 19 116 11.4. BGP Community Container Types . . . . . . . . . . . . . 19 117 11.5. Registered Type 1 BGP Wide Communities Community Types . 20 118 11.6. Registered Type 1 BGP Wide Community Optional Sub-Types 20 119 12. Change History . . . . . . . . . . . . . . . . . . . . . . . 21 120 12.1. Working Group draft . . . . . . . . . . . . . . . . . . 21 121 12.2. Individual draft . . . . . . . . . . . . . . . . . . . . 22 122 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 123 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 124 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 125 15.1. Normative References . . . . . . . . . . . . . . . . . . 24 126 15.2. Informative References . . . . . . . . . . . . . . . . . 24 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 129 1. Introduction 131 RFC 1997 [RFC1997] defines the BGP Community Attribute. This 132 attribute is used as a tool to carry additional information in BGP 133 routes which may help to automate peering administration. The BGP 134 Communities Attribute consists of a set of one or more four-octet 135 values, where each specifies a different community. Except for two 136 reserved ranges, the encoding of community values mandates that the 137 first two octets are to contain the Autonomous System number, with 138 the next two octets containing some locally defined value. 140 Since the introduction of [RFC1997], numerous additional mechanisms 141 have been introduced to provide BGP Community-like functionality. 142 Each of these mechanisms introduce a new syntax, typically covered by 143 its encoding with the BGP Path Attribute that defines it, and a 144 semantic space. 146 The authors believe that defining a new BGP Path Attribute, with the 147 ability to contain locally defined parameters will enhance the 148 current level of network policies, as well as simplify BGP policy 149 management. The proposed encoding will also facilitate the delivery 150 of new network services without a need to define a new BGP extension 151 each time. 153 When defining any new type of tool there is always a unique 154 opportunity to specify a subset of well recognized behaviors. Lists 155 of the current most commonly used BGP communities, as well as 156 provision for a new registry for future definitions will be contained 157 in a separate document. 159 2. Protocol Summary 161 This specification defines a new BGP Path Attribute, the BGP 162 Community Container. It carries a series of BGP Community Container 163 types, each prefaced with the BGP Community Container Common Header. 165 This specification also defines the BGP Wide Community Container. 167 2.1. BGP Community Container Common Header 169 The BGP Community Container Common Header permits Community-like 170 attributes to be grouped under a single BGP Path Attribute. This 171 provides hierarchy for future Community-like features. It permits 172 implementations without knowledge of a specific Community Container's 173 format to address that Community Container by its code point. It 174 also permits common enforcement of the Community Container's 175 transitivity across AS boundaries without need for the implementation 176 to understand a specific Container's implementation. 178 The BGP Community Container Common Header is defined in Section 3.1 179 and contains following encoding: 181 Container Type: 182 Container Type 1, BGP Wide Community is defined in this document. 184 Flags: 185 Flags control common behavior including the transitivity of the 186 Container. 188 Length: 189 Length of the Container contents. 191 2.2. Community Containers 193 This document defines one Community Container with the following 194 encoding: 196 2.2.1. Type 1: BGP Wide Community 198 The container type 1 "BGP Wide Community TLVs" is defined in 199 Section 4. 201 Community Value: 202 This section defines the action that an operator wishes a router 203 to take. 205 Source AS: 206 This is the AS originating the community. 208 Context AS: 209 AS that defines and provides the semantics to interpret this 210 Community. 212 Target(s): 213 This is an optional list that encodes where the community's 214 action should be taken. 216 Exclude Target(s): 217 This is an optional list that encodes where the community's 218 actions should not be taken. 220 Parameters: 221 This is an optional list of Atoms that encodes additional 222 information that the community's action needs to execute 223 properly. 225 2.3. BGP Community Container Atoms 227 Atoms provide data types that can be used to encode contents of BGP 228 Community Containers. They are in the format of TLVs and are defined 229 later in this document in Section 5. 231 3. BGP Community Container Attribute 233 This document defines a new BGP Path Attribute, the BGP Community 234 Container. The attribute type code is TBD. 236 The BGP Community Container attribute is an optional, transitive BGP 237 attribute, and may be present only once in the BGP UPDATE message. 239 The attribute contains a set of typed containers. Any given 240 container type may appear multiple times, unless that container 241 type's definition specifies otherwise. 243 3.1. BGP Community Container Attribute Common Header 245 Containers always start with the following common header: 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Type | Flags |C|T| Reserved | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Length | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Figure 1: Common container header 257 This document defines container type 1. See the Section 11 for 258 information on additional type registration policies. 260 +------+-------+----------------------------------------------------+ 261 | Bit | Value | Meaning | 262 +------+-------+----------------------------------------------------+ 263 | T | 0 | Not Transitive across administrative boundary. | 264 | | 1 | Transitive across AS and administrative boundary. | 265 | C | 0 | Not transitive across confederation boundaries. | 266 | | 1 | Transitive across confederation boundaries. | 267 | 3..7 | - | RESERVED - MUST be zero when originated and SHOULD | 268 | | | be ignored upon receipt. | 269 +------+-------+----------------------------------------------------+ 271 Table 1: Flags 273 Flags are defined globally and apply to all container types. 275 Bit 0 (T bit) Transitivity bit: 277 When not set (value 0), the community in the container is 278 transitive across AS boundaries, but not across an administrative 279 boundary. 281 When set (value 1), the community in the container is transitive 282 across all ASes. An administrative boundary, in this sense, is an 283 arbitrary set of connected ASes, possibly under control of a 284 single entity. How such an administrative boundary is determined 285 is out of scope of this document. 287 Bit 1 (C bit) Confederation bit: 289 The confederation bit is used to manage the propagation scope of a 290 given BGP Wide Community across confederation boundaries. 292 When not set (value 0) community is not transitive across 293 confederation sub-AS boundary. When set (value of 1) indicates 294 that community in a given container is transitive across 295 confederation boundary. 297 The Reserved field MUST be set to zero when originated and SHOULD be 298 ignored upon receipt. 300 The Length field represents the total length of a given container's 301 contents in octets. 303 4. BGP Community Container, Type 1: BGP Wide Community 305 The Type 1 BGP Community Container, the BGP Wide Community, is of 306 variable size (but minimum length 12). It is composed of a fixed 307 12-octets - containing the Community Value, the Source AS Number, and 308 the Context AS Number - followed by optional TLVs: 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 |I| Community Value | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Source AS Number | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Context AS Number | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | | 320 | TLVs (optional) | 321 | | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 Figure 2: Type 1, BGP Wide Community 326 4.1. Community Value 328 Community Value: 4 octets 330 The Community Value indicates what set of actions a router is 331 requested to take upon reception of a route containing this 332 community. The semantics of this value depend on whether this is a 333 private/local community or IANA registered. 335 When the high order bit of the Community Value field - I - is set, 336 the value is IANA Registered and has a well defined meaning with 337 underlying semantics. See the documentation for each Registered BGP 338 Wide Community for its semantics and validation requirements. 340 When the high order bit of the Community Value field is clear, the 341 value is Locally defined and has semantics solely within the control 342 of the AS defining that community. The Context AS Number provides 343 the namespace in which this Community Value is interpreted. It is 344 that AS's responsibility to provide the semantics and validation 345 requirements for that BGP Wide Community. 347 See Section 11.5 for code point space partitioning. 349 4.2. Source AS Number 351 Source Autonomous System Number: 4 octets 353 The Autonomous System number indicates the AS originating this BGP 354 Wide Community. 356 4.3. Context AS Number 358 Context Autonomous System Number: 4 octets 360 This identifies the AS that provides the semantics to interpret this 361 Community. 363 4.4. BGP Wide Community TLVs 365 Optional type 1 container TLVs are encoded in the following format: 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+ 370 | Sub-Type | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Length | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Value (variable) | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 Figure 3: Type 1 Container TLVs 379 Sub-Type: 380 The sub-type of the BGP Wide Community TLV. A given Sub-Type 381 MUST NOT appear more than once. 383 Length: 384 Length of the "Value" field in octets. 386 Value: 387 Specific to the underlying Sub-Type. 389 4.4.1. Sub-Type 1, BGP Wide Community Target(s) TLV 391 The value field of the Wide Community Target(s) TLV (Sub-Type 1) is a 392 series of Atom TLVs. The semantics of any given Atom TLV MUST be 393 part of the definition of a given Wide Community. 395 BGP Wide Community Targets define the matching criteria for the 396 community. A given wide community may have a number of targets that 397 it applies to. The semantics of these targets will vary on a per 398 community basis. Depending on the definition of the community, 399 targets may be optional. 401 Wide Community Targets consist of a series of Atoms that have "match 402 any" semantics. Thus, if any given target matches per the semantics 403 of that Atom for the community, the community is considered to match 404 and the action defined by the community should be executed. 406 When no Target(s) TLV is specified, it is considered "match all". 408 If the semantics of a given Atom is undefined for the community in 409 question, this Atom MUST be ignored. 411 When no targets are required by the definition of a given Wide 412 Community, the Wide Community Target(s) TLV SHOULD NOT be encoded in 413 the community. Implementations MUST be prepared to accept a Wide 414 Community Target(s) TLV with an empty value field. 416 4.4.2. Sub-Type 2, BGP Wide Community Exclude Target(s) TLV 418 The BGP Wide Community Exclude Target(s) TLV (Sub-Type 2) contains a 419 list of a Atoms. 421 Wide Community Exclude Targets define criteria by which the community 422 is considered to NOT match. Depending on the semantics of the BGP 423 Wide Community, Exclude Target(s) may be optional. 425 The semantic of the BGP Wide Community Exclude Target(s) is to match 426 all specified Target(s) with the exception of those listed in this 427 TLV. 429 The value field of the BGP Wide Community Exclude Target(s) TLV is a 430 series of BGP Wide Community Atom TLVs. The semantics of any given 431 Atom TLV MUST be part of the definition of a given Wide Community. 433 If the semantics of a given Atom is undefined for the community in 434 question, this Atom MUST be ignored. 436 If the BGP Wide Community Target(s) TLV and the BGP Wide Community 437 Exclude Target(s) TLV have conflicting semantics, priority MUST be 438 given to the Wide Community Exclude Target(s) TLV. 440 When no exclude targets are required by the definition of a given BGP 441 Wide Community, the BGP Wide Community Exclude Target(s) TLV SHOULD 442 NOT be encoded in the community. Implementations MUST be prepared to 443 accept a BGP Wide Community Exclude Target(s) TLV with an empty value 444 field. 446 4.4.3. Sub-Type 3, BGP Wide Community Parameter(s) TLV 448 The BGP Wide Community Parameter(s) TLV (Sub-Type 3) contains a list 449 of a Atoms. 451 A given BGP Wide Community may have parameters that are used as 452 inputs for executing actions defined for that community. These 453 parameters, and any constraints implied by the parameters, MUST be 454 defined by the wide community definition. Parameters consist of an 455 ordered set of Atom sub-TLVs. The semantics of any specific 456 positional instance of an Atom MUST be defined by the wide community. 458 Care must be taken when using Atoms with list semantics. If the 459 desired behavior is a single or limited number of instances of that 460 type, this should be documented as part of the use case of that BGP 461 Wide Community. 463 If it is the case that a parameter for a given community is of an 464 unexpected type or length, the BGP Wide Community MUST be ignored. 466 If it is the case that there are too many or two few parameters for a 467 given community, the BGP Wide Community MUST be ignored. 469 When no parameters are required by the definition of a given Wide 470 Community, the Wide Community Parameters TLV SHOULD NOT be encoded in 471 the community. Implementations MUST be prepared to accept a Wide 472 Community Parameter TLV with an empty value field. 474 4.4.4. Usage 476 The detailed interpretation of the targets or parameters SHALL be 477 provided when describing given community type in a separate document 478 or when locally defined by an operator. 480 5. BGP Community Container Atoms 482 Some types of BGP Community Contaners, for example BGP Wide 483 Communities, will act on and hence need to encode some distinct Atoms 484 of data. Use of Atoms is solely subject to definition of the 485 specific BGP Container type. Atoms are encoded as TLVs, where each 486 TLV has the following format: 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+ 491 | Type | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Length | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Value (variable) | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 Figure 4: Atoms TLVs 500 The Type field contains a value of 1-254. The values 0 and 255 are 501 reserved for future use. The TLV types are to be assigned and 502 maintained by IANA registry; see Section 11.2. 504 The Length represents the length of the "Value" field in octets. 506 The Value field contains the TLV value. 508 Supported format of the TLVs can be: 510 Type 1: Autonomous System Number List. 511 Type 2: IPv4 Prefix (1 octet prefix length + prefix) List. 512 Type 3: IPv6 Prefix (1 octet prefix length + prefix) List. 513 Type 4: Integer32 List. 514 Type 5: IEEE Floating Point Number List. 515 Type 6: Neighbor Class List. 516 Type 7: User-defined Class List. 517 Type 8: UTF-8 String. 519 The semantics of a given Atom will depend upon the context in which 520 it is used, as defined by the containing wide community. 522 In the following sections defining the different Atoms, validation 523 rules for the Length of the Atom will be presented. If the Length of 524 the Atom does not match the rules for that Atom, it SHALL be 525 considered malformed. (See Section 8.) 527 In general, Atoms of List type have the semantics of sets. Duplicate 528 entries SHOULD NOT be present and MAY be removed by BGP Speaker 529 propagating the Lists. The presence of duplicate entries have no 530 additional semantics. 532 5.1. Atom Type 1, The Autonomous System Number List 534 This Atom represents a list of Autonomous System numbers, each 4 535 octets in size. When encoding two octet ASes, the first two octets 536 of this four octet value MUST be filled with zeros. The minimum 537 Length of this Atom is 4 octets. The Length MUST be a multiple of 4. 539 Two special values are reserved for the Autonomous System Atoms: 541 0x00000000 - to indicate "No Autonomous Systems". 542 0xFFFFFFFF - to indicate "All Autonomous Systems". 544 5.2. Atom Types 2 and 3, The IPv4 and IPv6 Prefix Lists 546 This Atom represents a list of IPv4 or IPv6 prefixes. IPv4 and IPv6 547 Prefix Atom values are encoded in the same format used by BGP NLRI in 548 Section 4.3 of [RFC4271]. 550 +---------------------------+ 551 | Prefix Length (1 octet) | 552 +---------------------------+ 553 | Prefix (variable) | 554 +---------------------------+ 556 Figure 5: IP prefix atoms 558 The Prefix Length for IPv4 prefixes MUST be in the range of 0..32. 560 The Prefix Length for IPv6 prefixes MUST be in the range of 0..128. 562 The Length field must be able to accommodate the list of prefixes 563 according to the encoding rules. If the Length cannot fully 564 accommodate the required number of octets to encode the Prefix Length 565 and the Prefix, the Atom is considered malformed. 567 5.3. Atom Type 4, The Integer32 List 569 This Atom represents a list of four-octet Integers. These Integers 570 are stored in network byte order. 572 The minimum Length of the Integer32 list Atom is 4 octets. The 573 Length MUST be a multiple of 4. 575 5.4. Atom Type 5, The IEEE Floating Point Number List 577 This Atom represents a list of floating point numbers. Floating 578 point numbers are a fixed Length of 4 octets and are stored in 579 [IEEE.754.1985] format. 581 The minimum Length of the Floating Point Number list Atom is 4 582 octets. The Length MUST be a multiple of 4. 584 5.5. Atom Type 6, The Neighbor Class List 586 The Neighbor Class list Atom represents a list of Neighbor classes, 587 each 4 octets in size. Neighbor class currently can contain three 588 values: 590 Peer (1): 591 This class is typically applied to sessions where a transit-free 592 relationship exists between two providers. 594 Customer (2): 595 This class is typically applied to sessions where the remote end 596 of the session is operated by a customer. 598 Upstream (3): 599 This class is typically applied to sessions where the remote end 600 of the session is operated by a network from which you receive 601 transit routes. 603 The minimum Length of the Neighbor Class list Atom is 4 octets. The 604 Length MUST be a multiple of 4. 606 5.6. Atom Type 7, The User-defined Class List 608 The User-defined Class list Atom represents a list of user-defined 609 class, each 4 octets in size. The exact property definition is up to 610 the semantics of the defining Autonomous System. The semantics 611 governing a given User-defined Class list are defined by the Context 612 AS Number and the Community Value. 614 Examples of User-defined Class properties include geography (East, 615 West), continent (North America, Asia, Europe), etc. Similar to the 616 [RFC1997] BGP Communities, it is necessary that the Context AS 617 provide a registry of the value and the semantics of a given 618 community. 620 The minimum Length of the User-defined Class list Atom is 4 octets. 621 The Length of this Atom MUST be a multiple of 4. 623 5.7. Atom Type 8, the UTF-8 String 625 The UTF-8 String Atom represents an arbitrary Unicode string in UTF-8 626 [RFC3629] format. The Length is required to be of sufficient size to 627 carry the UTF-8 string in the Value field. 629 Implementations MUST be prepared for truncated/improperly formed 630 UTF-8 strings. When detecting such a string, the implementation 631 should remove trailing octets of a multi-octet sequence in order to 632 have a well-formed string. 634 Implementations MUST be prepared to receive empty (zero-Length) UTF-8 635 String Atoms as they may be used as Parameters. 637 6. Well Known Standard BGP Communities 639 According to RFC 1997, as well as IANA's Well-Known BGP Communities 640 registry, the following BGP communities are defined to have global 641 significance: 643 0xFFFF0000 planned-shut [draft-francois-bgp-gshut] 644 0xFFFFFF01 NO_EXPORT [RFC1997] 645 0xFFFFFF02 NO_ADVERTISE [RFC1997] 646 0xFFFFFF03 NO_EXPORT_SUBCONFED [RFC1997] 647 0xFFFFFF04 NOPEER [RFC3765] 649 This document recommends for simplicity as well as for avoidance of 650 backward compatibility issues the continued use of BGP Standard 651 Community Path Attribute, type 8, as defined in RFC 1997 to 652 distribute non-Autonomous System specific Well-Known BGP Communities. 654 For the same reason, this document does not intend to obsolete the 655 currently defined and deployed BGP Extended Communities. 657 7. Operational Considerations 659 Having multiple ways to propagate locally assigned BGP Communities - 660 via the use of Standard, Extended or Large BGP Communities versus the 661 use of BGP Wide Communities - may seem to potentially cause problems 662 when considering propagation of conflicting actions. However, even 663 at present, an operator may append such Communities with conflicting 664 information. It is therefore recommended that any implementation, in 665 supporting both standard and BGP Wide Communities, allow for their 666 easy inbound and outbound processing. The actual execution of all 667 communities should be treated as a union and, if supported by an 668 implementation, their execution permissions are to be a local 669 configuration matter. 671 8. Error Handling 673 8.1. General Error Handling for BGP Community Containers 675 [RFC7606] "treat as withdraw" behavior is expected for any malformed 676 Community Containers or malformation of their contents. 678 Each Community Container type may have additional validation rules, 679 including permitted length of Atoms. Failure to conform to those 680 additional rules MUST also be treated as a malformed Community 681 Container. 683 8.2. BGP Wide Community Container Error Handling 685 If any Atom in a BGP Wide Community container's Exclude Targets TLV 686 is unrecognized, that Wide Community MUST NOT be considered a match 687 and no actions for that community should be processed. While the 688 Targets TLV is meant to be inclusive, the Exclude Targets TLV is 689 meant to be proscriptive of applying the action. 691 9. Example 693 9.1. Example Type 1 Wide Community Definition 695 An operator of an AS 64496, wishes to locally define a Wide Community 696 with the semantics of permitting AS_PATH prepending with targets that 697 include AS numbers of peer ASes and peers who have been marked with a 698 set of enumerated city locations. AS 64496 has selected Community 699 Value 1 to represent this functionality. 701 AS 64496 has established a registered set of values to use for its 702 User-defined Class: 704 100 - Amsterdam 705 101 - New York 706 102 - San Francisco 707 103 - Tokyo 708 104 - Moscow 710 Target semantics: 712 The Autonomous System Number list Atom refers to the target peer 713 AS Numbers. 715 The User-defined Class for AS 64496 has been defined elsewhere and 716 the values 100..104 may be used for this locally defined Wide 717 Community. 719 The Targets TLV MUST contain at least one entry. 721 The Exclude Targets TLV MAY contain entries of the above supported 722 Atoms. 724 The semantics of all other Atoms are undefined for this community. 726 Parameter semantics: 728 The parameter TLV shall consist of exactly one Integer32 Atom 729 value that is constrained to have a value of 2..8. 731 9.2. Example Type 1 BGP Wide Community Encoding 733 AS_PATH prepend 4 TIMES TO AS 2424, AS 8888, to peers marked as 734 Amsterdam (100) or to peers marked Moscow (104), but not to peers in 735 New York (101). 737 The T Flag (transitive) is set to prevent propagation of this 738 community. 740 0 1 2 3 741 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 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Type (1, Wide) | Flags |0|1| Reserved(0) | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Length: 53 | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Community: LOCAL PREPEND ACTION CATEGORY 1 | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Source AS 64496 | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Context AS 64496 | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Target TLV (1)| Length: 18 | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | ASN List (1) | Length: 8 | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Target ASN# 2424 | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Target ASN# 8888 | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | User List(7) | Length: 8 | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Amsterdam (100) | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Moscow (104) | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 |ExcTargetTLV(2)| Length: 5 | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | User List(7) | Length: 4 | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | New York (101) | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | Param TLV (3) | Length: 5 | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | Integer32 (4) | Length: 4 | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Prepend # 4 | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 Figure 6: Example 1 782 10. Security considerations 783 10.1. BGP Community Container Security Considerations 785 Transitive BGP Community Container communities could unintentionally 786 spread far from their origin. If a router receives many routes from 787 multiple sources on the Internet with different communities, it could 788 cause significant memory usage. To prevent excessive memory usage, 789 routers should be configured to strip unexpected communities from 790 received routes. 792 All the security considerations for BGP Communities [RFC1997] or BGP 793 Extended Communities [RFC4360] apply to BGP Community Containers. 795 10.2. BGP Wide Community Security Considerations 797 For BGP Wide Communities, the Community Value the Source AS may 798 provide sufficient context to strip unwanted or unexpected 799 communities. 801 Given the flexibility and power offered by BGP Wide communities, it 802 is important to consider the additional possibilities allowed by 803 their definition. In particular, for locally defined BGP Wide 804 Communities, it may be wise to restrict the range of parameters. For 805 registered BGP Wide Communities, the security considerations of the 806 document defining them MUST address issues specific to those newly 807 defined Communities. 809 11. IANA Considerations 811 11.1. BGP Community Container Attribute 813 This document defines a new BGP Path Attribute called BGP Community 814 Container Attribute. For this new type IANA is requested to allocate 815 a new value in the corresponding registry: 817 Registry Name: BGP Path Attributes 819 This document makes the following assignments for the optional, 820 transitive BGP Community Container Attribute: 822 Name Type Value 823 ---- ---------- 824 BGP Community Container Attribute TBD 826 11.2. BGP Community Container Atoms Types 828 This document requests IANA to define and maintain a new registry 829 named: "BGP Community Container Atom Types". The pool of 0x00-0xFF 830 has been defined for its allocations. 832 Registration procedures: 834 0x00: Reserved. 835 0x01-0x08: Defined in this document. 836 0x09-0xFE: IETF Consensus. 837 0xFF: Reserved. 839 This document makes the following assignments for the BGP Community 840 Container Atom Type values registry: 842 Name Type Value 843 ---- ---------- 844 Autonomous System Number List 0x01 845 IPv4 Prefix list 0x02 846 IPv6 Prefix list 0x03 847 Integer32 list 0x04 848 IEEE Floating Point Number list 0x05 849 Neighbor Class list 0x06 850 User-defined Class list 0x07 851 UTF-8 string 0x08 853 11.3. BGP Community Container Neighbor Class List Atom Types 855 This document requests IANA to define and maintain a new registry 856 named: "BGP Community Container Neighbor Class List Atom Types". The 857 pool of 0x00000000-0xFFFFFFFF has been defined for its allocations. 859 Registration procedures: 861 0x00000000 : Reserved. 862 0x00000001-0x00000003 : Defined in this document. 863 0x00000004-0xFFFFFFFE : IETF Consensus. 864 0xFFFFFFFF : Reserved. 866 This document makes the following assignments for the BGP Community 867 Container Neighbor Class List Atom Types registry: 869 Name Type Value 870 ---- ---------- 871 Peer 1 872 Customer 2 873 Upstream 3 875 11.4. BGP Community Container Types 877 This document requests IANA to define and maintain a new registry 878 named: "BGP Community Container Types". 880 The pool of: 0x0000..0xFFFF has been defined for its allocations. 882 Registration procedures: 884 0x0000 : Reserved. 885 0x0001 : BGP Wide Community (defined in this 886 document). 887 0x0002-0x0004 : Reserved. 888 0x0005-0x00FF : IETF Consensus. 889 0x0100-0xFF00 : First Come, First Served. 890 0xFF01-0xFFFE : Experimental. 891 0xFFFF : Reserved. 893 11.5. Registered Type 1 BGP Wide Communities Community Types 895 This document requests IANA to define and maintain a new registry 896 named: "Registered Type 1 BGP Wide Community Community Types". The 897 pool of 0x00000000..0xFFFFFFFF has been defined for its allocation. 899 Registration procedures: 901 0x00000000 : Reserved. 902 0x00000001-0x7FFFFFFF : Available for private/local use. 903 0x80000000 : Reserved. 904 0x80000001-0xFFFFFEFF : First Come, First Served for 905 registered use. 906 0xFFFFFF00-0xFFFFFFFE : Experimental. 907 0xFFFFFFFF : Reserved. 909 11.6. Registered Type 1 BGP Wide Community Optional Sub-Types 911 This document requests IANA to define and maintain a new registry 912 named: "Registered Type 1 BGP Wide Community Optional Sub-Types". 913 The pool of 0x00..0xFF has been defined for its allocation. 915 Registration procedures: 917 0 : Reserved. 918 1..3 : Defined in this document. 919 4..254 : IETF Consensus. 920 255 : Reserved. 922 This document makes the following assignments for the Registered Type 923 1 BGP Wide Community Optional Sub-Types registry: 925 Name Type Value 926 ---- ---------- 927 Targets 1 928 Exclude Targets 2 929 Parameters 3 931 12. Change History 933 12.1. Working Group draft 935 Changes from -03 to -04: 937 Many editorial changes. 939 Restored the structure of the common header to accommodate prior 940 implementations from Huawei. However, do not keep the Hop count 941 per prior IDR and author discussion. 943 Adopt the name BGP Community Container for the general feature and 944 common header after discussion on IDR regarding Large BGP 945 Communities. Wide communities now specifically refer to the Type 946 1 container. 948 Updated the Common Container Header's definition of Length to only 949 cover the length of the contents, and not the header. 951 Hide the Type 2 (4:4), Type 3 (Nx4), Type 4 (16+Nx4) containers 952 for now. 954 Outstanding issues addresses and section removed. 956 Type 1 container renamed from "Wide community" to "Wide community 957 TLVs". 959 Rename Integer Atom to Integer32. 961 Example changed, following previous specification change. 963 Changes from -02 to -03: 965 Many editorial change. 967 Introduction of new type of containers: Type 2 (4:4), Type 3 968 (Nx4), Type 4 (16+Nx4) 969 Common container header: Type length changed from 2-octets to 1 970 octet, "Hop Count" removed, "Context AS number" moved from type 1 971 to the generic header. 973 Remove community "AS-4 List Generic Wide BGP Community" 975 Changes from -00 to -02: no change 977 00: no change 979 12.2. Individual draft 981 Changes from -03 via -04 to -05: 983 Update the Introduction. 985 Substantial re-work of Atom types removing proposed Group 986 container and moving Atoms to be lists. 988 Added the Exclude Targets TLV to the Wide Community container. 990 Added a section on error handling. 992 Updated the example. 994 Changes from -02 to -03: 996 Removed C and R named bit fields originally from -00. 998 Rename Target AS field to Context AS. 1000 Make Integer Atom a fixed 4 octets in length. 1002 Add Neighbor Class Atom 1004 Rename TTL to Hop Count 1006 Changes from -01 to -02: 1008 The Type field has been expanded to 2 octets. 1010 The Length field has been moved to the common header. 1012 Changed format to use TLVs. 1014 Added Atom TLV to define well defined syntactic items. 1016 Added TLVs to distinguish targets from parameters. 1018 Various editorial changes to language. 1020 13. Contributors 1022 The following people contributed significantly to the content of the 1023 document: 1025 Shintaro Kojima 1026 OTEMACHI 1st. SQUARE EAST TOWER, 3F 1027 1-5-1, Otemachi, 1028 Chiyoda-ku, Tokyo 100-0004 1029 Japan 1030 Email: koji@mfeed.ad.jp 1032 Juan Alcaide 1033 Cisco Systems 1034 Research Triangle Park, NC 1035 United States 1036 Email: jalcaide@cisco.com 1038 Burjiz Pithawala 1039 Cisco Systems 1040 170 West Tasman Dr 1041 San Jose, CA 1042 United States 1043 Email: bpithaw@cisco.com 1045 Saku Ytti 1046 TDC Oy 1047 Mechelininkatu 1a 1048 00094 TDC 1049 Finland 1050 Email: ytti@tdc.net 1052 14. Acknowledgments 1054 This document owes draft-lange-flexible-bgp-communities a debt for 1055 the inspiration of many features contained herein. 1057 The authors would like to thank Enke Chen, Pedro Marques, Alton Lo, 1058 Igor Gashinsky and Job Snijders for their valuable input. 1060 15. References 1061 15.1. Normative References 1063 [IEEE.754.1985] 1064 Institute of Electrical and Electronics Engineers, 1065 "Standard for Binary Floating-Point Arithmetic", 1066 IEEE Standard 754, August 1985. 1068 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1069 Requirement Levels", BCP 14, RFC 2119, 1070 DOI 10.17487/RFC2119, March 1997, . 1073 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1074 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1075 2003, . 1077 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1078 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1079 DOI 10.17487/RFC4271, January 2006, . 1082 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1083 Patel, "Revised Error Handling for BGP UPDATE Messages", 1084 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1085 . 1087 15.2. Informative References 1089 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 1090 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 1091 . 1093 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1094 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1095 February 2006, . 1097 Authors' Addresses 1099 Robert Raszuk (editor) 1100 Bloomberg LP 1101 731 Lexington Ave 1102 New York City, NY 10022 1103 USA 1105 EMail: robert@raszuk.net 1106 Jeffrey Haas (editor) 1107 Juniper Networks 1108 1194 N.Mathilda Ave 1109 Sunnyvale, CA 94089 1110 US 1112 EMail: jhaas@juniper.net 1114 Andrew Lange (editor) 1115 Nokia 1116 777 E. Middlefield Road 1117 Mountain View, CA 94043 1118 US 1120 EMail: andrew.lange@nokia.com 1122 Bruno Decraene (editor) 1123 Orange 1125 EMail: bruno.decraene@orange.com 1127 Shane Amante 1128 Apple, Inc. 1129 1 Infinite Loop 1130 Cupertino, CA 95014 1131 US 1133 EMail: amante@apple.com 1135 Paul Jakma 1136 Hewlett Packard Enterprise 1137 CSA02, Erskine Ferry Road 1138 Bishopton PA7 5PP 1139 Scotland 1141 EMail: paul.jakma@hpe.com