idnits 2.17.1 draft-heitz-idr-extra-extended-community-02.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC4684, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: To be not transitive means that a sending speaker MUST not send the community. A speaker that receives an XXC across an AS boundary not allowed by the transitivity of that XXC MUST treat the containing UPDATE message as malformed. (Using the creation date from RFC4684, updated by this document, for RFC5378 checks: 2004-06-02) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 14, 2019) is 1900 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) == Outdated reference: A later version (-21) exists of draft-ietf-bess-evpn-igmp-mld-proxy-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR J. Heitz 3 Internet-Draft A. Sajassi 4 Updates: 4684 (if approved) Cisco 5 Intended status: Standards Track I. Bagdonas 6 Expires: July 18, 2019 Equinix 7 January 14, 2019 9 BGP Extra Extended Community 10 draft-heitz-idr-extra-extended-community-02 12 Abstract 14 Auto-derived identifiers are used by applications to enable zero 15 configuration features. Such identifiers are often a combination of 16 primitive identifiers and are thus longer. In addition, existing 17 identifiers have grown longer. IP addresses have grown from 4 octets 18 to 16. AS numbers have grown from 2 octets to 4. In order to 19 accommodate such longer identifiers in BGP extended communities, this 20 document defines a new BGP path attribute, the Extra Extended 21 Communities attribute. It is similar to the Extended Community, but 22 is 24 octets long. Communities are mostly used within ASes under a 23 single administration or between neighboring ASes. Limiting the 24 spread of communities beyond their intended reach and polluting the 25 internet at large is complex and error prone. To simplify this, 26 enhanced transitivity options are provided. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 18, 2019. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. BGP Extra Extended Community Attribute . . . . . . . . . . . 3 69 3. Transitivity . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Capability . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 5. Constrained Route Distribution . . . . . . . . . . . . . . . 5 72 6. IPv6-Address-Specific Extra Extended Community type . . . . . 7 73 7. IPv4-Address-Specific Extra Extended Community type . . . . . 7 74 8. AS-Specific Extra Extended Community type . . . . . . . . . . 8 75 9. Route Target Extra Extended Community Sub-Type . . . . . . . 9 76 10. EVPN Extra Extended Community type . . . . . . . . . . . . . 10 77 11. EVPN Route Target Extra Extended Community sub-types . . . . 10 78 12. EVPN ES-Import Route Target Extra Extended Community sub-type 11 79 13. EVPN ESI-EVI Route Target Extra Extended Community sub-type . 11 80 14. EVPN Overlay Route Target Extra Extended Community sub-type . 12 81 15. Duplicate XXC . . . . . . . . . . . . . . . . . . . . . . . . 14 82 16. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 14 83 17. Security Considerations . . . . . . . . . . . . . . . . . . . 15 84 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 18.1. Registry: BGP Extra Extended Community Types . . . . . . 15 86 18.2. Registry: IPv6-Address-Specific Extra Extended Community 87 Sub-Types . . . . . . . . . . . . . . . . . . . . . . . 15 88 18.3. Registry: IPv4-Address-Specific Extra Extended Community 89 Sub-Types . . . . . . . . . . . . . . . . . . . . . . . 16 90 18.4. Registry: AS-Specific Extra Extended Community Sub-Types 16 91 18.5. Registry: EVPN Extra Extended Community Sub-Types . . . 16 92 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 19.1. Normative References . . . . . . . . . . . . . . . . . . 17 94 19.2. Informative References . . . . . . . . . . . . . . . . . 18 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 97 1. Introduction 99 A BGP Extended Community attribute is defined that encodes 24 octet 100 communities. It is similar to the Extended Communities attribute 101 defined in [RFC4360], but larger. To simplify the IANA registries, 102 the transitivity of a Extra Extended Community is not part of the 103 IANA registered type. Any type can be encoded with any transitivity. 104 BGP autonomous system (AS) relationships have become more complex. 105 Several contiguous ASes may be under a common administration. A 106 transitivity is defined that allows a XXC to be sent among these ASes 107 only. Some XXCs may be required to be transferred only between 108 neighboring ASes, even though they are under a different 109 administration. A transitivity type to allow this is defined. Up to 110 now, the range of ASes among which a community is distributed is 111 enforced by routing policies. These policies are sometimes executed 112 in the receiving AS, not under the control of the sending AS. The 113 enhanced transitivity options offerend in this document will simplify 114 policies that are used to distribute communities. 116 2. BGP Extra Extended Community Attribute 118 The Extra Extended Communities Attribute is a transitive optional BGP 119 attribute, with the Type Code [to be assigned by IANA]. The 120 attribute consists of a set of "Extra Extended Communities" (XXC). 121 The attribute SHOULD contain at least one XXC. 123 Each XXC is encoded as a 24-octet quantity, as follows: 125 0 1 2 3 126 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 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | T | Type | Sub-Type | | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value + 130 | | 131 + + 132 | | 133 + + 134 | | 135 + + 136 | | 137 + + 138 | | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 The fields are as shown below: 143 T - Transitivity field (2 bits). This is further 144 described below. 146 Type - 6 bits. IANA will maintain a registry of types. 147 Four types are described in this document. 149 Sub-type - 8 bits. IANA will maintain a registry of sub-types 150 for each registered type. 152 Value - The actual information according to the type and 153 sub-type. 155 Two XXCs are considered equal when all the 24 octets of the XXCs are 156 equal, except the Transitivity field.. 158 3. Transitivity 160 The transitivity field determines how BGP speakers transfer the XXC 161 across real Autonomous System (AS) boundaries. The XXC is always 162 transitive between Member-ASes in an AS confederation [RFC5065]. The 163 values are: 165 0 - Transitive: The XXC is transitive across ASes. 167 1 - Non-transitive: The XXC is not transitive across ASes. 169 2 - Administration Transitive: The XXC is transitive across 170 ASes under the same administration only. 172 3 - One-time Transitive: The XXC is transitive across ASes 173 under the same administration and into an AS under the 174 neighboring administration, but not into an AS under a 175 further administration. 177 To be not transitive means that a sending speaker MUST not send the 178 community. A speaker that receives an XXC across an AS boundary not 179 allowed by the transitivity of that XXC MUST treat the containing 180 UPDATE message as malformed. 182 A single administration may own a multitude of contiguous ASes. XXCs 183 with transitivity types 2 and 3 are transitive between these ASes. 184 By default, an EBGP neighbor is assumed to be under a different 185 administration. If an EBGP neighbor session is to a speaker in the 186 same administration, then it needs to be configured as such. No 187 Administration identifiers are required. The configuration just 188 needs to specify "Same Administration". There is no new field in the 189 BGP OPEN message to indicate administration membership. 191 A BGP speaker that receives a XXC with transitivity 3 from a neighbor 192 in an AS under a different administration SHOULD change the 193 transitivity field of the XXC to 2. 195 The transitivity of an XXC is intended to limit the travel of the XXC 196 in default conditions. It prevents an XXC from traveling far beyond 197 its intended reach if nothing else is done. That means a speaker is 198 free to change the transitivity of an XXC according to local policy 199 to support specific use cases. As an example, a route server as 200 defined in [RFC7947] MAY choose not to change transitivity from 3 to 201 2. The definition of an XXC type MAY include a specification of the 202 default transitivity for the type. 204 The Transitivity field is not implicitly associated with the Type and 205 Sub-Type fields the way they are in Extended Communities. The 206 Transitivity field should be set by the originator based upon 207 individual circumstances at the originator. The transitivity is not 208 assigned by IANA. 210 4. Capability 212 BGP speakers that do not implement Extra Extended Communities will 213 transfer XXCs even though they may not be transitive across their AS 214 boundaries. To prevent this, a BGP capability as defined in 215 [RFC5492] is required. The length of the capability is 0. A BGP 216 speaker SHOULD NOT send a XXC, the transitivity of which is not 0, to 217 a speaker from which it has not received the Extra Extended Community 218 Capability in its OPEN message. A BGP speaker SHOULD withdraw a 219 route from a neighbor if that neighbor does not advertise this 220 capability and the route contanis an XXC. These rules are intended 221 to prevent XXCs from leaking outside their intended range. There may 222 be cases where such leaking causes no ill effects and the rules can 223 be safely ignored. Such cases are beyond the scope of this document. 225 A transitive XXC may be sent to a neighbor that has not sent the 226 capability. 228 5. Constrained Route Distribution 230 [RFC4684] defines Constrained Route Distribution. That document is 231 updated as follows: 233 The Extra Constrained Route Distribution SAFI is defined, the NLRI of 234 which is as follows: 236 +-------------------------------+ 237 | AFI (2 octets) | 238 +-------------------------------+ 239 | SAFI (1 octets) | 240 +-------------------------------+ 241 | origin AS (4 octets) | 242 +-------------------------------+ 243 | XXC value (24 octets) | 244 + + 245 | | 246 +-------------------------------+ 248 The fields are as shown below: 250 AFI - The filter specified in this NLRI applies only to 251 prefixes with this AFI. 253 SAFI - The filter specified in this NLRI applies only to 254 prefixes with this SAFI. 256 origin AS - Routes that do not have this origin AS will be 257 blocked by the filter. 259 XXC value - Routes that do not have this XXC will be blocked by 260 the filter. 262 This works the same way as [RFC4684] with the following differences: 264 - The maximum prefix size of this NLRI is 248 bits. 266 - The minimum prefix size of this NLRI is 56 bits except for the 267 default route, which is 0 bits long. 269 - The filter applies only to prefixes that have the specified AFI/ 270 SAFI. 272 - The filter applies to any XXC values. The filtered XXC does not 273 need to be designated a "Route Target". 275 Route targets can be expressed as prefixes, where, for instance, a 276 prefix would encompass all route target extended communities assigned 277 by a given Global Administrator. Route Target prefixes can be 278 aggregated. However if done so, then AFI, SAFI, Transitivity, Route 279 Target Type, Sub-Type and the Global Administrator Route Target 280 fields MUST NOT be aggregated. 282 The address family "Extra Constrained Route Distribution" cannot 283 filter itself. 285 6. IPv6-Address-Specific Extra Extended Community type 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | T | 0 | Sub-Type | | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 292 | | 293 + + 294 | Global Administrator | 295 + + 296 | | 297 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | | | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 300 | Local Administrator | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 The Type field is 0. The Sub-Type is to be assigned by IANA as 304 detailed in the IANA Considerations section. 306 The Value field consists of 2 sub-fields: 308 Global Administrator sub-field: 16 octets 310 This sub-field contains an IPv6 unicast address assigned by one 311 of the Internet registries to the administration of the service 312 using the XXC. 314 Local Administrator sub-field: 6 octets 316 The organization identified by the IP address in the Global 317 Administrator sub-field can encode any information in this sub- 318 field. The format and meaning of the value encoded in this 319 sub-field should be defined by the sub-type of the XXC. 321 7. IPv4-Address-Specific Extra Extended Community type 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | T | 1 | Sub-Type | Global Administrator : 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 : Global Administrator (cont.) | | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 329 | | 330 + + 331 | Local Administrator | 332 + + 333 | | 334 + + 335 | | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 The Type field is 1. The Sub-Type is to be assigned by IANA for 339 individual functions. 341 The Value field consists of 2 sub-fields: 343 Global Administrator sub-field: 4 octets 345 This sub-field contains an IPv4 unicast address assigned by one 346 of the Internet registries to the administration of the service 347 using the XXC. 349 Local Administrator sub-field: 18 octets 351 The organization identified by the IP address in the Global 352 Administrator sub-field can encode any information in this sub- 353 field. The format and meaning of the value encoded in this 354 sub-field should be defined by the sub-type of the XXC. 356 8. AS-Specific Extra Extended Community type 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 | T | 2 | Sub-Type | Global Administrator : 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 : Global Administrator (cont.) | | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 364 | Local Administrator | 365 + + 366 | | 367 + + 368 | | 369 + + 370 | | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 The Type field is 2. The Sub-Type is to be assigned by IANA for 374 individual functions. 376 The Value field consists of 2 sub-fields: 378 Global Administrator sub-field: 4 octets 380 This sub-field contains a 4-octet Autonomous System number 381 assigned by IANA. Note that an ASN that is less than 65536 in 382 value is represented in 4 octets by setting the higher two 383 octets to 0. 385 Local Administrator sub-field: 18 octets 387 The organization identified by the Autonomous System number in 388 the Global Administrator sub-field can encode any information 389 in this sub-field. The format and meaning of the value encoded 390 in this sub-field should be defined by the sub-type of the XXC. 392 9. Route Target Extra Extended Community Sub-Type 394 For each of the Types of XXC: IPv4-Address-Specific, IPv6-Address- 395 Specific and AS-Specific, the Sub-Type 2 denotes a Route-Target. It 396 has the same use as the Route Target defined in [RFC4360] Sec. 4. 397 The XXC route targets are independent of the RFC4360 Route Targets. 398 There is no way to convert between the two. Either or both may be 399 used in any deployment. 401 10. EVPN Extra Extended Community type 403 This is a Extra Extended Community type with a Value field comprising 404 22 octets. 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | T | 6 | Sub-Type | | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value + 411 | | 412 + + 413 | | 414 + + 415 | | 416 + + 417 | | 418 + + 419 | | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 The Type field is 6. The Sub-Type is to be assigned by IANA for 423 individual functions. Three functions are defined in this document. 425 11. EVPN Route Target Extra Extended Community sub-types 427 Auto-derivation of EVPN Route Targets is described in [RFC7432] Sec. 428 7.10.1. Because of the limited size of Route Targets using Extended 429 Communities, the auto-derivation is limited to using the 12 bit VLAN 430 ID. With the larger size of the RT-XXC, the complete 32 bits of the 431 Ethernet Tag ID can be used. 433 EVPN XXC route targets have a Type value of 6. The value of the Sub- 434 Type is 436 1 - AS-Specific: The most significant 4 octets of the Value 437 field are the Autonomous System Number of the AS where this 438 RT is assigned. 440 2 - IPv4 Address Specific: The most significant 4 octets of the 441 Value field are an IPv4 unicast address assigned by one of 442 the Internet registries to the administration of the 443 service using the XXC. 445 3 - IPv6 Address Specific: The most significant 16 octets of 446 the Value field are an IPv6 unicast address assigned by one 447 of the Internet registries to the administration of the 448 service using the XXC. 450 The Ethernet Tag ID is placed into the least significant octets of 451 the Value field. The remaining octets are 0. 453 12. EVPN ES-Import Route Target Extra Extended Community sub-type 455 The ES-Import Route Target as specified in [RFC7432] Sec. 7.6 limits 456 the ESI to 6 octets. Thus it cannot be automatically derived for all 457 ESI types. This ES-Import RT-XXC allows the use of the full 10 458 octets of ESI. The ES-Import Route Target XXC and the ES-Import 459 Route Target extended community are independent. Either or both may 460 be used in any deployment. There is no conversion from one to the 461 other. 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | T | 6 | 4 | GA : 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 : GA (Cont.) | | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 470 | | 471 + ESI + 472 | | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | | 475 + Zero + 476 | | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 The Type field is 6. The Sub-Type is 4. The fields are as follows: 481 GA - 4 octets. Global Administrator. This is the 482 Autonomous System Number of the AS where this RT is 483 assigned. 485 ESI - 10 octets. Ethernet Segment Identifier. 487 Zero - 8 octets filled with 0. Must be ignored by the 488 receiver. 490 13. EVPN ESI-EVI Route Target Extra Extended Community sub-type 492 The ESI-EVI Route Target is used in EVPN route types 7 and 8 to 493 filter routes by both ESI and Ethernet Tag ID. More details are in 494 [I-D.ietf-bess-evpn-igmp-mld-proxy]. 496 0 1 2 3 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | T | 6 | 5 | GA : 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 : GA (Cont.) | | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 503 | | 504 + ESI + 505 | | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | EVI-RT | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Zero | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 The Type field is 6. The Sub-Type is 5. The fields are as follows: 514 GA - 4 octets. Global Administrator. This is the 515 Autonomous System Number of the AS where this RT is 516 assigned. 518 ESI - 10 octets. Ethernet Segment Identifier. 520 EVI-RT - 4 octets. The least significant 4 octets of the 521 Local Administrator field of the route target 522 associated with the EVI. 524 Zero - 4 octets filled with 0. Must be ignored by the 525 receiver. 527 14. EVPN Overlay Route Target Extra Extended Community sub-type 529 This EVPN Overlay Route Target Extra Extended Community type is used 530 to filter routes based upon the identifier used in the specified 531 overlay protocol. It works the same way as the RT described in 532 [RFC8365] Sec. 5.1.2.1. It simply provides more room in the fields 533 to allow auto-derivation for more cases. First, it allows a 4 octet 534 AS number. Second, the Service ID is large enough to fit any of the 535 selected IDs. 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | T | 6 | 6 | GA : 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 : GA (Cont.) |A| Space | D-ID | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | | 545 + + 546 | | 547 + + 548 | | 549 + + 550 | Service-ID | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 The Type field is 6. The Sub-Type is 6. The fields are as follows: 555 GA - 4 octets. Global Administrator. This is the 556 Autonomous System Number of the AS where this RT is 557 assigned. 559 A - A single bit indicating if this RT is auto-derived 561 0 : auto-derived 563 1 : manually derived 565 Space - 7 bits. The identifier space appropriate to the 566 service. The following spaces are defined: 568 0 : VID (802.1Q VLAN ID) 570 1 : VXLAN 572 2 : NVGRE 574 3 : I-SID 576 4 : EVI 578 5 : dual-VID (QinQ VLAN ID) 580 D-ID - 1 octet. The default value of domain-id is zero 581 indicating that only a single numbering space exists 582 for a given technology. However, if there is more 583 than one number space for a given technology (e.g., 584 overlapping VXLAN spaces), then each of the number 585 spaces need to be identified by their corresponding 586 domain-id starting from 1. 588 Service-ID - 16 octets. VNI, VSID, I-SID, VID or other identifier 589 as appropriate for the service specified in the Space 590 field. If the contained identifier is less than 16 591 octets long, then it is placed in the least 592 significant octets of the Service-ID field with the 593 higher octets being filled with 0. 595 15. Duplicate XXC 597 Two XXCs are considered duplicate if the values of each field except 598 the Transitivity field match. 600 A BGP speaker SHOULD NOT send a duplicate XXC. However, this is not 601 an error, but merely suboptimal. The duplication of a XXC has no 602 meaning. A receiver of a duplicate XXC SHOULD silently discard the 603 duplicate. The duplication of a XXC cannot be used to compound its 604 effect. For example if one XXC causes the local preference to be 605 incremented by 5, the presence of two of the same XXC will not 606 increment the LP by 10. OTOH, if one XXC increments the LP by 5 and 607 a different XXC increments it by 10, then the combination will cause 608 an increment of 15. 610 A BGP speaker that receives duplicate XXCs that differ in the 611 Transitivity MAY silently discard the XXC with the more restrictive 612 transitivity. 614 16. Error Handling 616 A BGP Extra Extended Communities attribute SHALL be considered 617 malformed if the length of the BGP Extra Extended Communities 618 Attribute value, expressed in octets, is not a multiple of 24. The 619 error SHALL be handled using the approach of "treat-as-withdraw" as 620 described in Section 2 of [RFC7606]. Receipt of a zero length Extra 621 Extended Communities attribute SHALL be treated as "attribute- 622 discard". 624 The order in which the XXCs appear in the XXC attribute is not 625 significant. It is not an error for a BGP speaker to propagate a set 626 of XXCs in a different order than in which they were received. 628 If a field in a specific type of XXC is invalid in another setting, 629 it is not necessarily to be considered invalid in a XXC. For 630 example, 0 is an invalid AS number when used in an AS path attribute. 631 That does not make it invalid as an ASN in the AS-Specific XXC. The 632 behavior and validity of fields in XXCs are to be defined by a 633 specification of the specific type and sub-type of the XXC. 635 The receipt of an XXC that violates the transitivity rules SHALL be 636 handled using the approach of "treat-as-withdraw". 638 17. Security Considerations 640 TBD 642 18. IANA Considerations 644 IANA is requested to assign a SAFI for the Extra Constrained Route 645 Distribution address family. 647 IANA is requested to assign a BGP path attribute value for the Extra 648 Extended Community attribute. 650 IANA is requested to create and maintain registries as detailed in 651 the following sections. For each registry, the allocation policies 652 as per [RFC8126] are stated for the ranges of values and some values 653 are allocated by this document. 655 18.1. Registry: BGP Extra Extended Community Types 657 Range Allocation Policy 658 --------- ------------------------------ 659 0-31 First Come First Served 660 32-47 Experimental 661 48-63 Standards Action 663 Value Description Reference 664 --------- ------------------------------ --------- 665 0 IPv6-Address-Specific This RFC 666 1 IPv4-Address-Specific This RFC 667 2 AS-Specific This RFC 668 6 EVPN This RFC 670 18.2. Registry: IPv6-Address-Specific Extra Extended Community Sub- 671 Types 672 Range Allocation Policy 673 --------- ------------------------------ 674 0-191 First Come First Served 675 192-255 IETF Review 677 Value Description Reference 678 --------- ------------------------------ --------- 679 2 Route Target RFC4360 681 18.3. Registry: IPv4-Address-Specific Extra Extended Community Sub- 682 Types 684 Range Allocation Policy 685 --------- ------------------------------ 686 0-191 First Come First Served 687 192-255 IETF Review 689 Value Description Reference 690 --------- ------------------------------ --------- 691 2 Route Target RFC4360 693 18.4. Registry: AS-Specific Extra Extended Community Sub-Types 695 Range Allocation Policy 696 --------- ------------------------------ 697 0-191 First Come First Served 698 192-255 IETF Review 700 Value Description Reference 701 --------- ------------------------------ --------- 702 2 Route Target RFC4360 704 18.5. Registry: EVPN Extra Extended Community Sub-Types 706 Range Allocation Policy 707 --------- ------------------------------ 708 0-191 First Come First Served 709 192-255 IETF Review 711 Value Description Reference 712 --------- ------------------------------ --------- 713 1 EVPN AS-Specific Route Target This RFC 714 2 EVPN IPv4-Specific Route Target This RFC 715 3 EVPN IPv6-Specific Route Target This RFC 716 4 EVPN ES-Import Route Target This RFC 717 5 EVPN ESI-EVI Route Target This RFC 718 6 EVPN Overlay Route Target This RFC 720 19. References 722 19.1. Normative References 724 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 725 Requirement Levels", BCP 14, RFC 2119, 726 DOI 10.17487/RFC2119, March 1997, 727 . 729 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 730 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 731 February 2006, . 733 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 734 R., Patel, K., and J. Guichard, "Constrained Route 735 Distribution for Border Gateway Protocol/MultiProtocol 736 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 737 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 738 November 2006, . 740 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 741 System Confederations for BGP", RFC 5065, 742 DOI 10.17487/RFC5065, August 2007, 743 . 745 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 746 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 747 2009, . 749 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 750 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 751 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 752 2015, . 754 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 755 Patel, "Revised Error Handling for BGP UPDATE Messages", 756 RFC 7606, DOI 10.17487/RFC7606, August 2015, 757 . 759 [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 760 "Internet Exchange BGP Route Server", RFC 7947, 761 DOI 10.17487/RFC7947, September 2016, 762 . 764 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 765 Writing an IANA Considerations Section in RFCs", BCP 26, 766 RFC 8126, DOI 10.17487/RFC8126, June 2017, 767 . 769 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 770 Uttaro, J., and W. Henderickx, "A Network Virtualization 771 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 772 DOI 10.17487/RFC8365, March 2018, 773 . 775 19.2. Informative References 777 [I-D.ietf-bess-evpn-igmp-mld-proxy] 778 Sajassi, A., Thoria, S., Patel, K., Yeung, D., Drake, J., 779 and W. Lin, "IGMP and MLD Proxy for EVPN", draft-ietf- 780 bess-evpn-igmp-mld-proxy-00 (work in progress), March 781 2017. 783 Authors' Addresses 785 Jakob Heitz 786 Cisco 787 170 West Tasman Drive 788 San Jose, CA, CA 95134 789 USA 791 Email: jheitz@cisco.com 793 Ali Sajassi 794 Cisco 795 170 West Tasman Drive 796 San Jose, CA, CA 95134 797 USA 799 Email: sajassi@cisco.com 801 Ignas Bagdonas 802 Equinix 803 London 804 UK 806 Email: ibagdona.ietf@gmail.com