idnits 2.17.1 draft-ietf-idr-wide-bgp-communities-06.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 (10 January 2022) is 836 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 654, 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: 14 July 2022 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 10 January 2022 16 BGP Community Container Attribute 17 draft-ietf-idr-wide-bgp-communities-06 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 https://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 14 July 2022. 59 Copyright Notice 61 Copyright (c) 2022 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 (https://trustee.ietf.org/ 66 license-info) in effect on the date of publication of this document. 67 Please review these documents carefully, as they describe your rights 68 and restrictions with respect to this document. Code Components 69 extracted from this document must include Revised BSD License text as 70 described in Section 4.e of the Trust Legal Provisions and are 71 provided without warranty as described in the Revised BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . 4 77 2.1. BGP Community Container Common Header . . . . . . . . . . 4 78 2.2. Community Containers . . . . . . . . . . . . . . . . . . 5 79 2.2.1. Type 1: BGP Wide Community . . . . . . . . . . . . . 5 80 2.3. BGP Community Container Atoms . . . . . . . . . . . . . . 5 81 3. BGP Community Container Attribute . . . . . . . . . . . . . . 5 82 3.1. BGP Community Container Attribute Common Header . . . . . 6 83 4. BGP Community Container, Type 1: BGP Wide Community . . . . . 7 84 4.1. Community Value . . . . . . . . . . . . . . . . . . . . . 8 85 4.2. Source AS Number . . . . . . . . . . . . . . . . . . . . 8 86 4.3. Context AS Number . . . . . . . . . . . . . . . . . . . . 8 87 4.4. BGP Wide Community TLVs . . . . . . . . . . . . . . . . . 8 88 4.4.1. Sub-Type 1, BGP Wide Community Target(s) TLV . . . . 9 89 4.4.2. Sub-Type 2, BGP Wide Community Exclude Target(s) 90 TLV . . . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . 14 100 5.7. Atom Type 8, the UTF-8 String . . . . . . . . . . . . . . 14 101 6. Well Known Standard BGP Communities . . . . . . . . . . . . . 14 102 7. Operational Considerations . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 107 9.1. Example Type 1 Wide Community Definition . . . . . . . . 16 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 116 Types . . . . . . . . . . . . . . . . . . . . . . . . . 19 117 11.4. BGP Community Container Types . . . . . . . . . . . . . 19 118 11.5. Registered Type 1 BGP Wide Communities Community 119 Types . . . . . . . . . . . . . . . . . . . . . . . . . 20 120 11.6. Registered Type 1 BGP Wide Community Optional 121 Sub-Types . . . . . . . . . . . . . . . . . . . . . . . 20 122 12. Change History . . . . . . . . . . . . . . . . . . . . . . . 21 123 12.1. Working Group draft . . . . . . . . . . . . . . . . . . 21 124 12.2. Individual draft . . . . . . . . . . . . . . . . . . . . 22 125 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 126 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 127 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 128 15.1. Normative References . . . . . . . . . . . . . . . . . . 24 129 15.2. Informative References . . . . . . . . . . . . . . . . . 24 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 132 1. Introduction 134 RFC 1997 [RFC1997] defines the BGP Community Attribute. This 135 attribute is used as a tool to carry additional information in BGP 136 routes which may help to automate peering administration. The BGP 137 Communities Attribute consists of a set of one or more four-octet 138 values, where each specifies a different community. Except for two 139 reserved ranges, the encoding of community values mandates that the 140 first two octets are to contain the Autonomous System number, with 141 the next two octets containing some locally defined value. 143 Since the introduction of [RFC1997], numerous additional mechanisms 144 have been introduced to provide BGP Community-like functionality. 145 Each of these mechanisms introduce a new syntax, typically covered by 146 its encoding with the BGP Path Attribute that defines it, and a 147 semantic space. 149 The authors believe that defining a new BGP Path Attribute, with the 150 ability to contain locally defined parameters will enhance the 151 current level of network policies, as well as simplify BGP policy 152 management. The proposed encoding will also facilitate the delivery 153 of new network services without a need to define a new BGP extension 154 each time. 156 When defining any new type of tool there is always a unique 157 opportunity to specify a subset of well recognized behaviors. Lists 158 of the current most commonly used BGP communities, as well as 159 provision for a new registry for future definitions will be contained 160 in a separate document. 162 2. Protocol Summary 164 This specification defines a new BGP Path Attribute, the BGP 165 Community Container. It carries a series of BGP Community Container 166 types, each prefaced with the BGP Community Container Common Header. 168 This specification also defines the BGP Wide Community Container. 170 2.1. BGP Community Container Common Header 172 The BGP Community Container Common Header permits Community-like 173 attributes to be grouped under a single BGP Path Attribute. This 174 provides hierarchy for future Community-like features. It permits 175 implementations without knowledge of a specific Community Container's 176 format to address that Community Container by its code point. It 177 also permits common enforcement of the Community Container's 178 transitivity across AS boundaries without need for the implementation 179 to understand a specific Container's implementation. 181 The BGP Community Container Common Header is defined in Section 3.1 182 and contains following encoding: 184 Container Type: 185 Container Type 1, BGP Wide Community is defined in this document. 187 Flags: 188 Flags control common behavior including the transitivity of the 189 Container. 191 Length: 192 Length of the Container contents. 194 2.2. Community Containers 196 This document defines one Community Container with the following 197 encoding: 199 2.2.1. Type 1: BGP Wide Community 201 The container type 1 "BGP Wide Community TLVs" is defined in 202 Section 4. 204 Community Value: 205 This section defines the action that an operator wishes a router 206 to take. 208 Source AS: 209 This is the AS originating the community. 211 Context AS: 212 AS that defines and provides the semantics to interpret this 213 Community. 215 Target(s): 216 This is an optional list that encodes where the community's 217 action should be taken. 219 Exclude Target(s): 220 This is an optional list that encodes where the community's 221 actions should not be taken. 223 Parameters: 224 This is an optional list of Atoms that encodes additional 225 information that the community's action needs to execute 226 properly. 228 2.3. BGP Community Container Atoms 230 Atoms provide data types that can be used to encode contents of BGP 231 Community Containers. They are in the format of TLVs and are defined 232 later in this document in Section 5. 234 3. BGP Community Container Attribute 236 This document defines a new BGP Path Attribute, the BGP Community 237 Container. The attribute type code is TBD. 239 The BGP Community Container attribute is an optional, transitive BGP 240 attribute, and may be present only once in the BGP UPDATE message. 242 The attribute contains a set of typed containers. Any given 243 container type may appear multiple times, unless that container 244 type's definition specifies otherwise. 246 3.1. BGP Community Container Attribute Common Header 248 Containers always start with the following common header: 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Type | Flags |C|T| Reserved | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Length | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Figure 1: Common container header 260 This document defines container type 1. See the Section 11 for 261 information on additional type registration policies. 263 +======+=======+===================================================+ 264 | Bit | Value | Meaning | 265 +======+=======+===================================================+ 266 | T | 0 | Not Transitive across administrative boundary. | 267 +------+-------+---------------------------------------------------+ 268 | | 1 | Transitive across AS and administrative boundary. | 269 +------+-------+---------------------------------------------------+ 270 | C | 0 | Not transitive across confederation boundaries. | 271 +------+-------+---------------------------------------------------+ 272 | | 1 | Transitive across confederation boundaries. | 273 +------+-------+---------------------------------------------------+ 274 | 3..7 | - | RESERVED - MUST be zero when originated and | 275 | | | SHOULD be ignored upon receipt. | 276 +------+-------+---------------------------------------------------+ 278 Table 1: Flags 280 Flags are defined globally and apply to all container types. 282 Bit 0 (T bit) Transitivity bit: 284 When not set (value 0), the community in the container is 285 transitive across AS boundaries, but not across an administrative 286 boundary. 288 When set (value 1), the community in the container is transitive 289 across all ASes. An administrative boundary, in this sense, is an 290 arbitrary set of connected ASes, possibly under control of a 291 single entity. How such an administrative boundary is determined 292 is out of scope of this document. 294 Bit 1 (C bit) Confederation bit: 296 The confederation bit is used to manage the propagation scope of a 297 given BGP Wide Community across confederation boundaries. 299 When not set (value 0) community is not transitive across 300 confederation sub-AS boundary. When set (value of 1) indicates 301 that community in a given container is transitive across 302 confederation boundary. 304 The Reserved field MUST be set to zero when originated and SHOULD be 305 ignored upon receipt. 307 The Length field represents the total length of a given container's 308 contents in octets. 310 4. BGP Community Container, Type 1: BGP Wide Community 312 The Type 1 BGP Community Container, the BGP Wide Community, is of 313 variable size (but minimum length 12). It is composed of a fixed 314 12-octets - containing the Community Value, the Source AS Number, and 315 the Context AS Number - followed by optional TLVs: 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 |I| Community Value | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Source AS Number | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Context AS Number | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | | 327 | TLVs (optional) | 328 | | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Figure 2: Type 1, BGP Wide Community 333 4.1. Community Value 335 Community Value: 4 octets 337 The Community Value indicates what set of actions a router is 338 requested to take upon reception of a route containing this 339 community. The semantics of this value depend on whether this is a 340 private/local community or IANA registered. 342 When the high order bit of the Community Value field - I - is set, 343 the value is IANA Registered and has a well defined meaning with 344 underlying semantics. See the documentation for each Registered BGP 345 Wide Community for its semantics and validation requirements. 347 When the high order bit of the Community Value field is clear, the 348 value is Locally defined and has semantics solely within the control 349 of the AS defining that community. The Context AS Number provides 350 the namespace in which this Community Value is interpreted. It is 351 that AS's responsibility to provide the semantics and validation 352 requirements for that BGP Wide Community. 354 See Section 11.5 for code point space partitioning. 356 4.2. Source AS Number 358 Source Autonomous System Number: 4 octets 360 The Autonomous System number indicates the AS originating this BGP 361 Wide Community. 363 4.3. Context AS Number 365 Context Autonomous System Number: 4 octets 367 This identifies the AS that provides the semantics to interpret this 368 Community. 370 4.4. BGP Wide Community TLVs 372 Optional type 1 container TLVs are encoded in the following format: 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+ 377 | Sub-Type | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Length | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Value (variable) | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 Figure 3: Type 1 Container TLVs 386 Sub-Type: 387 The sub-type of the BGP Wide Community TLV. A given Sub-Type 388 MUST NOT appear more than once. 390 Length: 391 Length of the "Value" field in octets. 393 Value: 394 Specific to the underlying Sub-Type. 396 4.4.1. Sub-Type 1, BGP Wide Community Target(s) TLV 398 The value field of the Wide Community Target(s) TLV (Sub-Type 1) is a 399 series of Atom TLVs. The semantics of any given Atom TLV MUST be 400 part of the definition of a given Wide Community. 402 BGP Wide Community Targets define the matching criteria for the 403 community. A given wide community may have a number of targets that 404 it applies to. The semantics of these targets will vary on a per 405 community basis. Depending on the definition of the community, 406 targets may be optional. 408 Wide Community Targets consist of a series of Atoms that have "match 409 any" semantics. Thus, if any given target matches per the semantics 410 of that Atom for the community, the community is considered to match 411 and the action defined by the community should be executed. 413 When no Target(s) TLV is specified, it is considered "match all". 415 If the semantics of a given Atom is undefined for the community in 416 question, this Atom MUST be ignored. 418 When no targets are required by the definition of a given Wide 419 Community, the Wide Community Target(s) TLV SHOULD NOT be encoded in 420 the community. Implementations MUST be prepared to accept a Wide 421 Community Target(s) TLV with an empty value field. 423 4.4.2. Sub-Type 2, BGP Wide Community Exclude Target(s) TLV 425 The BGP Wide Community Exclude Target(s) TLV (Sub-Type 2) contains a 426 list of a Atoms. 428 Wide Community Exclude Targets define criteria by which the community 429 is considered to NOT match. Depending on the semantics of the BGP 430 Wide Community, Exclude Target(s) may be optional. 432 The semantic of the BGP Wide Community Exclude Target(s) is to match 433 all specified Target(s) with the exception of those listed in this 434 TLV. 436 The value field of the BGP Wide Community Exclude Target(s) TLV is a 437 series of BGP Wide Community Atom TLVs. The semantics of any given 438 Atom TLV MUST be part of the definition of a given Wide Community. 440 If the semantics of a given Atom is undefined for the community in 441 question, this Atom MUST be ignored. 443 If the BGP Wide Community Target(s) TLV and the BGP Wide Community 444 Exclude Target(s) TLV have conflicting semantics, priority MUST be 445 given to the Wide Community Exclude Target(s) TLV. 447 When no exclude targets are required by the definition of a given BGP 448 Wide Community, the BGP Wide Community Exclude Target(s) TLV SHOULD 449 NOT be encoded in the community. Implementations MUST be prepared to 450 accept a BGP Wide Community Exclude Target(s) TLV with an empty value 451 field. 453 4.4.3. Sub-Type 3, BGP Wide Community Parameter(s) TLV 455 The BGP Wide Community Parameter(s) TLV (Sub-Type 3) contains a list 456 of a Atoms. 458 A given BGP Wide Community may have parameters that are used as 459 inputs for executing actions defined for that community. These 460 parameters, and any constraints implied by the parameters, MUST be 461 defined by the wide community definition. Parameters consist of an 462 ordered set of Atom sub-TLVs. The semantics of any specific 463 positional instance of an Atom MUST be defined by the wide community. 465 Care must be taken when using Atoms with list semantics. If the 466 desired behavior is a single or limited number of instances of that 467 type, this should be documented as part of the use case of that BGP 468 Wide Community. 470 If it is the case that a parameter for a given community is of an 471 unexpected type or length, the BGP Wide Community MUST be ignored. 473 If it is the case that there are too many or two few parameters for a 474 given community, the BGP Wide Community MUST be ignored. 476 When no parameters are required by the definition of a given Wide 477 Community, the Wide Community Parameters TLV SHOULD NOT be encoded in 478 the community. Implementations MUST be prepared to accept a Wide 479 Community Parameter TLV with an empty value field. 481 4.4.4. Usage 483 The detailed interpretation of the targets or parameters SHALL be 484 provided when describing given community type in a separate document 485 or when locally defined by an operator. 487 5. BGP Community Container Atoms 489 Some types of BGP Community Contaners, for example BGP Wide 490 Communities, will act on and hence need to encode some distinct Atoms 491 of data. Use of Atoms is solely subject to definition of the 492 specific BGP Container type. Atoms are encoded as TLVs, where each 493 TLV has the following format: 495 0 1 2 3 496 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 497 +-+-+-+-+-+-+-+-+ 498 | Type | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Length | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Value (variable) | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 Figure 4: Atoms TLVs 507 The Type field contains a value of 1-254. The values 0 and 255 are 508 reserved for future use. The TLV types are to be assigned and 509 maintained by IANA registry; see Section 11.2. 511 The Length represents the length of the "Value" field in octets. 513 The Value field contains the TLV value. 515 Supported format of the TLVs can be: 517 Type 1: Autonomous System Number List. 518 Type 2: IPv4 Prefix (1 octet prefix length + prefix) List. 519 Type 3: IPv6 Prefix (1 octet prefix length + prefix) List. 520 Type 4: Integer32 List. 521 Type 5: IEEE Floating Point Number List. 522 Type 6: Neighbor Class List. 523 Type 7: User-defined Class List. 524 Type 8: UTF-8 String. 526 The semantics of a given Atom will depend upon the context in which 527 it is used, as defined by the containing wide community. 529 In the following sections defining the different Atoms, validation 530 rules for the Length of the Atom will be presented. If the Length of 531 the Atom does not match the rules for that Atom, it SHALL be 532 considered malformed. (See Section 8.) 534 In general, Atoms of List type have the semantics of sets. Duplicate 535 entries SHOULD NOT be present and MAY be removed by BGP Speaker 536 propagating the Lists. The presence of duplicate entries have no 537 additional semantics. 539 5.1. Atom Type 1, The Autonomous System Number List 541 This Atom represents a list of Autonomous System numbers, each 4 542 octets in size. When encoding two octet ASes, the first two octets 543 of this four octet value MUST be filled with zeros. The minimum 544 Length of this Atom is 4 octets. The Length MUST be a multiple of 4. 546 Two special values are reserved for the Autonomous System Atoms: 548 0x00000000 - to indicate "No Autonomous Systems". 549 0xFFFFFFFF - to indicate "All Autonomous Systems". 551 5.2. Atom Types 2 and 3, The IPv4 and IPv6 Prefix Lists 553 This Atom represents a list of IPv4 or IPv6 prefixes. IPv4 and IPv6 554 Prefix Atom values are encoded in the same format used by BGP NLRI in 555 Section 4.3 of [RFC4271]. 557 +---------------------------+ 558 | Prefix Length (1 octet) | 559 +---------------------------+ 560 | Prefix (variable) | 561 +---------------------------+ 563 Figure 5: IP prefix atoms 565 The Prefix Length for IPv4 prefixes MUST be in the range of 0..32. 567 The Prefix Length for IPv6 prefixes MUST be in the range of 0..128. 569 The Length field must be able to accommodate the list of prefixes 570 according to the encoding rules. If the Length cannot fully 571 accommodate the required number of octets to encode the Prefix Length 572 and the Prefix, the Atom is considered malformed. 574 5.3. Atom Type 4, The Integer32 List 576 This Atom represents a list of four-octet Integers. These Integers 577 are stored in network byte order. 579 The minimum Length of the Integer32 list Atom is 4 octets. The 580 Length MUST be a multiple of 4. 582 5.4. Atom Type 5, The IEEE Floating Point Number List 584 This Atom represents a list of floating point numbers. Floating 585 point numbers are a fixed Length of 4 octets and are stored in 586 [IEEE.754.1985] format. 588 The minimum Length of the Floating Point Number list Atom is 4 589 octets. The Length MUST be a multiple of 4. 591 5.5. Atom Type 6, The Neighbor Class List 593 The Neighbor Class list Atom represents a list of Neighbor classes, 594 each 4 octets in size. Neighbor class currently can contain three 595 values: 597 Peer (1): 598 This class is typically applied to sessions where a transit-free 599 relationship exists between two providers. 601 Customer (2): 602 This class is typically applied to sessions where the remote end 603 of the session is operated by a customer. 605 Upstream (3): 606 This class is typically applied to sessions where the remote end 607 of the session is operated by a network from which you receive 608 transit routes. 610 The minimum Length of the Neighbor Class list Atom is 4 octets. The 611 Length MUST be a multiple of 4. 613 5.6. Atom Type 7, The User-defined Class List 615 The User-defined Class list Atom represents a list of user-defined 616 class, each 4 octets in size. The exact property definition is up to 617 the semantics of the defining Autonomous System. The semantics 618 governing a given User-defined Class list are defined by the Context 619 AS Number and the Community Value. 621 Examples of User-defined Class properties include geography (East, 622 West), continent (North America, Asia, Europe), etc. Similar to the 623 [RFC1997] BGP Communities, it is necessary that the Context AS 624 provide a registry of the value and the semantics of a given 625 community. 627 The minimum Length of the User-defined Class list Atom is 4 octets. 628 The Length of this Atom MUST be a multiple of 4. 630 5.7. Atom Type 8, the UTF-8 String 632 The UTF-8 String Atom represents an arbitrary Unicode string in UTF-8 633 [RFC3629] format. The Length is required to be of sufficient size to 634 carry the UTF-8 string in the Value field. 636 Implementations MUST be prepared for truncated/improperly formed 637 UTF-8 strings. When detecting such a string, the implementation 638 should remove trailing octets of a multi-octet sequence in order to 639 have a well-formed string. 641 Implementations MUST be prepared to receive empty (zero-Length) UTF-8 642 String Atoms as they may be used as Parameters. 644 6. Well Known Standard BGP Communities 646 According to RFC 1997, as well as IANA's Well-Known BGP Communities 647 registry, the following BGP communities are defined to have global 648 significance: 650 0xFFFF0000 planned-shut [draft-francois-bgp-gshut] 651 0xFFFFFF01 NO_EXPORT [RFC1997] 652 0xFFFFFF02 NO_ADVERTISE [RFC1997] 653 0xFFFFFF03 NO_EXPORT_SUBCONFED [RFC1997] 654 0xFFFFFF04 NOPEER [RFC3765] 656 This document recommends for simplicity as well as for avoidance of 657 backward compatibility issues the continued use of BGP Standard 658 Community Path Attribute, type 8, as defined in RFC 1997 to 659 distribute non-Autonomous System specific Well-Known BGP Communities. 661 For the same reason, this document does not intend to obsolete the 662 currently defined and deployed BGP Extended Communities. 664 7. Operational Considerations 666 Having multiple ways to propagate locally assigned BGP Communities - 667 via the use of Standard, Extended or Large BGP Communities versus the 668 use of BGP Wide Communities - may seem to potentially cause problems 669 when considering propagation of conflicting actions. However, even 670 at present, an operator may append such Communities with conflicting 671 information. It is therefore recommended that any implementation, in 672 supporting both standard and BGP Wide Communities, allow for their 673 easy inbound and outbound processing. The actual execution of all 674 communities should be treated as a union and, if supported by an 675 implementation, their execution permissions are to be a local 676 configuration matter. 678 8. Error Handling 680 8.1. General Error Handling for BGP Community Containers 682 [RFC7606] "treat as withdraw" behavior is expected for any malformed 683 Community Containers or malformation of their contents. 685 Each Community Container type may have additional validation rules, 686 including permitted length of Atoms. Failure to conform to those 687 additional rules MUST also be treated as a malformed Community 688 Container. 690 8.2. BGP Wide Community Container Error Handling 692 If any Atom in a BGP Wide Community container's Exclude Targets TLV 693 is unrecognized, that Wide Community MUST NOT be considered a match 694 and no actions for that community should be processed. While the 695 Targets TLV is meant to be inclusive, the Exclude Targets TLV is 696 meant to be proscriptive of applying the action. 698 9. Example 700 9.1. Example Type 1 Wide Community Definition 702 An operator of an AS 64496, wishes to locally define a Wide Community 703 with the semantics of permitting AS_PATH prepending with targets that 704 include AS numbers of peer ASes and peers who have been marked with a 705 set of enumerated city locations. AS 64496 has selected Community 706 Value 1 to represent this functionality. 708 AS 64496 has established a registered set of values to use for its 709 User-defined Class: 711 100 - Amsterdam 712 101 - New York 713 102 - San Francisco 714 103 - Tokyo 715 104 - Moscow 717 Target semantics: 719 The Autonomous System Number list Atom refers to the target peer 720 AS Numbers. 722 The User-defined Class for AS 64496 has been defined elsewhere and 723 the values 100..104 may be used for this locally defined Wide 724 Community. 726 The Targets TLV MUST contain at least one entry. 728 The Exclude Targets TLV MAY contain entries of the above supported 729 Atoms. 731 The semantics of all other Atoms are undefined for this community. 733 Parameter semantics: 735 The parameter TLV shall consist of exactly one Integer32 Atom 736 value that is constrained to have a value of 2..8. 738 9.2. Example Type 1 BGP Wide Community Encoding 740 AS_PATH prepend 4 TIMES TO AS 2424, AS 8888, to peers marked as 741 Amsterdam (100) or to peers marked Moscow (104), but not to peers in 742 New York (101). 744 The T Flag (transitive) is set to prevent propagation of this 745 community. 747 0 1 2 3 748 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 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | Type (1, Wide) | Flags |0|1| Reserved(0) | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | Length: 53 | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Community: LOCAL PREPEND ACTION CATEGORY 1 | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Source AS 64496 | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Context AS 64496 | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Target TLV (1)| Length: 18 | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | ASN List (1) | Length: 8 | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Target ASN# 2424 | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Target ASN# 8888 | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | User List(7) | Length: 8 | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Amsterdam (100) | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Moscow (104) | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 |ExcTargetTLV(2)| Length: 5 | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | User List(7) | Length: 4 | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | New York (101) | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Param TLV (3) | Length: 5 | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Integer32 (4) | Length: 4 | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | Prepend # 4 | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 Figure 6: Example 1 789 10. Security considerations 790 10.1. BGP Community Container Security Considerations 792 Transitive BGP Community Container communities could unintentionally 793 spread far from their origin. If a router receives many routes from 794 multiple sources on the Internet with different communities, it could 795 cause significant memory usage. To prevent excessive memory usage, 796 routers should be configured to strip unexpected communities from 797 received routes. 799 All the security considerations for BGP Communities [RFC1997] or BGP 800 Extended Communities [RFC4360] apply to BGP Community Containers. 802 10.2. BGP Wide Community Security Considerations 804 For BGP Wide Communities, the Community Value the Source AS may 805 provide sufficient context to strip unwanted or unexpected 806 communities. 808 Given the flexibility and power offered by BGP Wide communities, it 809 is important to consider the additional possibilities allowed by 810 their definition. In particular, for locally defined BGP Wide 811 Communities, it may be wise to restrict the range of parameters. For 812 registered BGP Wide Communities, the security considerations of the 813 document defining them MUST address issues specific to those newly 814 defined Communities. 816 11. IANA Considerations 818 11.1. BGP Community Container Attribute 820 This document defines a new BGP Path Attribute called BGP Community 821 Container Attribute. For this new type IANA is requested to allocate 822 a new value in the corresponding registry: 824 Registry Name: BGP Path Attributes 826 This document makes the following assignments for the optional, 827 transitive BGP Community Container Attribute: 829 Name Type Value 830 ---- ---------- 831 BGP Community Container Attribute TBD 833 11.2. BGP Community Container Atoms Types 835 This document requests IANA to define and maintain a new registry 836 named: "BGP Community Container Atom Types". The pool of 0x00-0xFF 837 has been defined for its allocations. 839 Registration procedures: 841 0x00: Reserved. 842 0x01-0x08: Defined in this document. 843 0x09-0xFE: IETF Consensus. 844 0xFF: Reserved. 846 This document makes the following assignments for the BGP Community 847 Container Atom Type values registry: 849 Name Type Value 850 ---- ---------- 851 Autonomous System Number List 0x01 852 IPv4 Prefix list 0x02 853 IPv6 Prefix list 0x03 854 Integer32 list 0x04 855 IEEE Floating Point Number list 0x05 856 Neighbor Class list 0x06 857 User-defined Class list 0x07 858 UTF-8 string 0x08 860 11.3. BGP Community Container Neighbor Class List Atom Types 862 This document requests IANA to define and maintain a new registry 863 named: "BGP Community Container Neighbor Class List Atom Types". The 864 pool of 0x00000000-0xFFFFFFFF has been defined for its allocations. 866 Registration procedures: 868 0x00000000 : Reserved. 869 0x00000001-0x00000003 : Defined in this document. 870 0x00000004-0xFFFFFFFE : IETF Consensus. 871 0xFFFFFFFF : Reserved. 873 This document makes the following assignments for the BGP Community 874 Container Neighbor Class List Atom Types registry: 876 Name Type Value 877 ---- ---------- 878 Peer 1 879 Customer 2 880 Upstream 3 882 11.4. BGP Community Container Types 884 This document requests IANA to define and maintain a new registry 885 named: "BGP Community Container Types". 887 The pool of: 0x0000..0xFFFF has been defined for its allocations. 889 Registration procedures: 891 0x0000 : Reserved. 892 0x0001 : BGP Wide Community (defined in this 893 document). 894 0x0002-0x0004 : Reserved. 895 0x0005-0x00FF : IETF Consensus. 896 0x0100-0xFF00 : First Come, First Served. 897 0xFF01-0xFFFE : Experimental. 898 0xFFFF : Reserved. 900 11.5. Registered Type 1 BGP Wide Communities Community Types 902 This document requests IANA to define and maintain a new registry 903 named: "Registered Type 1 BGP Wide Community Community Types". The 904 pool of 0x00000000..0xFFFFFFFF has been defined for its allocation. 906 Registration procedures: 908 0x00000000 : Reserved. 909 0x00000001-0x7FFFFFFF : Available for private/local use. 910 0x80000000 : Reserved. 911 0x80000001-0xFFFFFEFF : First Come, First Served for 912 registered use. 913 0xFFFFFF00-0xFFFFFFFE : Experimental. 914 0xFFFFFFFF : Reserved. 916 11.6. Registered Type 1 BGP Wide Community Optional Sub-Types 918 This document requests IANA to define and maintain a new registry 919 named: "Registered Type 1 BGP Wide Community Optional Sub-Types". 920 The pool of 0x00..0xFF has been defined for its allocation. 922 Registration procedures: 924 0 : Reserved. 925 1..3 : Defined in this document. 926 4..254 : IETF Consensus. 927 255 : Reserved. 929 This document makes the following assignments for the Registered Type 930 1 BGP Wide Community Optional Sub-Types registry: 932 Name Type Value 933 ---- ---------- 934 Targets 1 935 Exclude Targets 2 936 Parameters 3 938 12. Change History 940 12.1. Working Group draft 942 Changes from -03 to -04: 944 Many editorial changes. 946 Restored the structure of the common header to accommodate prior 947 implementations from Huawei. However, do not keep the Hop count 948 per prior IDR and author discussion. 950 Adopt the name BGP Community Container for the general feature and 951 common header after discussion on IDR regarding Large BGP 952 Communities. Wide communities now specifically refer to the Type 953 1 container. 955 Updated the Common Container Header's definition of Length to only 956 cover the length of the contents, and not the header. 958 Hide the Type 2 (4:4), Type 3 (Nx4), Type 4 (16+Nx4) containers 959 for now. 961 Outstanding issues addresses and section removed. 963 Type 1 container renamed from "Wide community" to "Wide community 964 TLVs". 966 Rename Integer Atom to Integer32. 968 Example changed, following previous specification change. 970 Changes from -02 to -03: 972 Many editorial change. 974 Introduction of new type of containers: Type 2 (4:4), Type 3 975 (Nx4), Type 4 (16+Nx4) 977 Common container header: Type length changed from 2-octets to 1 978 octet, "Hop Count" removed, "Context AS number" moved from type 1 979 to the generic header. 981 Remove community "AS-4 List Generic Wide BGP Community" 983 Changes from -00 to -02: no change 985 00: no change 987 12.2. Individual draft 989 Changes from -03 via -04 to -05: 991 Update the Introduction. 993 Substantial re-work of Atom types removing proposed Group 994 container and moving Atoms to be lists. 996 Added the Exclude Targets TLV to the Wide Community container. 998 Added a section on error handling. 1000 Updated the example. 1002 Changes from -02 to -03: 1004 Removed C and R named bit fields originally from -00. 1006 Rename Target AS field to Context AS. 1008 Make Integer Atom a fixed 4 octets in length. 1010 Add Neighbor Class Atom 1012 Rename TTL to Hop Count 1014 Changes from -01 to -02: 1016 The Type field has been expanded to 2 octets. 1018 The Length field has been moved to the common header. 1020 Changed format to use TLVs. 1022 Added Atom TLV to define well defined syntactic items. 1024 Added TLVs to distinguish targets from parameters. 1026 Various editorial changes to language. 1028 13. Contributors 1030 The following people contributed significantly to the content of the 1031 document: 1033 Shintaro Kojima 1034 OTEMACHI 1st. SQUARE EAST TOWER, 3F 1035 1-5-1, Otemachi, 1036 Chiyoda-ku, Tokyo 100-0004 1037 Japan 1038 Email: koji@mfeed.ad.jp 1040 Juan Alcaide 1041 Cisco Systems 1042 Research Triangle Park, NC 1043 United States 1044 Email: jalcaide@cisco.com 1046 Burjiz Pithawala 1047 Cisco Systems 1048 170 West Tasman Dr 1049 San Jose, CA 1050 United States 1051 Email: bpithaw@cisco.com 1053 Saku Ytti 1054 TDC Oy 1055 Mechelininkatu 1a 1056 00094 TDC 1057 Finland 1058 Email: ytti@tdc.net 1060 14. Acknowledgments 1062 This document owes draft-lange-flexible-bgp-communities a debt for 1063 the inspiration of many features contained herein. 1065 The authors would like to thank Enke Chen, Pedro Marques, Alton Lo, 1066 Igor Gashinsky and Job Snijders for their valuable input. 1068 15. References 1070 15.1. Normative References 1072 [IEEE.754.1985] 1073 Institute of Electrical and Electronics Engineers, 1074 "Standard for Binary Floating-Point Arithmetic", 1075 IEEE Standard 754, August 1985. 1077 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1078 Requirement Levels", BCP 14, RFC 2119, 1079 DOI 10.17487/RFC2119, March 1997, 1080 . 1082 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1083 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1084 2003, . 1086 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1087 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1088 DOI 10.17487/RFC4271, January 2006, 1089 . 1091 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1092 Patel, "Revised Error Handling for BGP UPDATE Messages", 1093 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1094 . 1096 15.2. Informative References 1098 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 1099 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 1100 . 1102 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1103 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1104 February 2006, . 1106 Authors' Addresses 1108 Robert Raszuk (editor) 1109 Bloomberg LP 1110 731 Lexington Ave 1111 New York City, NY 10022 1112 United States of America 1114 Email: robert@raszuk.net 1115 Jeffrey Haas (editor) 1116 Juniper Networks 1117 1194 N.Mathilda Ave 1118 Sunnyvale, CA 94089 1119 United States of America 1121 Email: jhaas@juniper.net 1123 Andrew Lange (editor) 1124 Nokia 1125 777 E. Middlefield Road 1126 Mountain View, CA 94043 1127 United States of America 1129 Email: andrew.lange@nokia.com 1131 Bruno Decraene (editor) 1132 Orange 1134 Email: bruno.decraene@orange.com 1136 Shane Amante 1137 Apple, Inc. 1138 1 Infinite Loop 1139 Cupertino, CA 95014 1140 United States of America 1142 Email: amante@apple.com 1144 Paul Jakma 1145 Hewlett Packard Enterprise 1146 CSA02, Erskine Ferry Road 1147 Bishopton 1149 Email: paul.jakma@hpe.com