idnits 2.17.1 draft-sajassi-bess-evpn-ac-aware-bundling-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7432]), 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 == 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: 3. From Figure-2 PE3 receives MAC route for MAC-1. It MUST not ignore AC information in Attachment Circuit ID Extended Community (Section 6.1) which was received with RT-2. -- The document date (August 18, 2020) is 1319 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: 'RFC4364' is mentioned on line 258, but not defined == Missing Reference: 'GENEVE' is mentioned on line 305, but not defined == Missing Reference: 'EVPN-PREFIX' is mentioned on line 313, but not defined == Unused Reference: 'I-D.ietf-bess-evpn-prefix-advertisement' is defined on line 572, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-tunnel-encaps' is defined on line 578, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-bess-evpn-igmp-mld-proxy-00 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-10 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS WorkGroup A. Sajassi 3 Internet-Draft M. Mishra 4 Intended status: Standards Track S. Thoria 5 Expires: February 19, 2021 P. Brissette 6 Cisco Systems 7 J. Rabadan 8 Nokia 9 J. Drake 10 Juniper Networks 11 August 18, 2020 13 AC-Aware Bundling Service Interface in EVPN 14 draft-sajassi-bess-evpn-ac-aware-bundling-02 16 Abstract 18 EVPN provides an extensible and flexible multi-homing VPN solution 19 over an MPLS/IP network for intra-subnet connectivity among Tenant 20 Systems and End Devices that can be physical or virtual. 22 EVPN multihoming with IRB is one of the common deployment scenarios. 23 There are deployments which requires capability to have multiple 24 subnets designated with multiple VLAN IDs in single bridge domain. 26 [RFC7432] defines three different type of service interface which 27 serve different requirements but none of them address the requirement 28 to be able to support multiple subnets within single bridge domain. 29 In this draft we define new service interface type to support 30 multiple subnets in single bridge domain. Service interface proposed 31 in this draft will be applicable to multihoming case only. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on February 19, 2021. 50 Copyright Notice 52 Copyright (c) 2020 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 1.1. Problem with Unicast MAC route processing for multihome 69 case . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 1.2. Problem with Multicast route synchronization . . . . . . 6 71 1.3. Potential Security concern caused by misconfiguration . . 6 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8 74 4. Solution Description . . . . . . . . . . . . . . . . . . . . 9 75 4.1. Control Plane Operation . . . . . . . . . . . . . . . . . 11 76 4.1.1. MAC/IP Address Advertisement . . . . . . . . . . . . 11 77 4.1.1.1. Local Unicast MAC learning . . . . . . . . . . . 11 78 4.1.1.2. Remote Unicast MAC learning . . . . . . . . . . . 11 79 4.1.2. Multicast route Advertisement . . . . . . . . . . . . 11 80 4.1.2.1. Local multicast state . . . . . . . . . . . . . . 11 81 4.1.2.2. Remote multicast state . . . . . . . . . . . . . 12 82 4.2. Data Plane Operation . . . . . . . . . . . . . . . . . . 12 83 4.2.1. Unicast Forwarding . . . . . . . . . . . . . . . . . 12 84 4.2.2. Multicast Forwarding . . . . . . . . . . . . . . . . 13 85 5. Mis-configuration of VLAN ranges across multihoming peer . . 13 86 6. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . 13 87 6.1. Attachment Circuit ID Extended Community . . . . . . . . 13 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 90 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 93 10.2. Informative References . . . . . . . . . . . . . . . . . 14 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 96 1. Introduction 98 EVPN based All-Active multi-homing is becoming the basic building 99 block for providing redundancy in next generation data center 100 deployments as well as service provider access/aggregation network. 101 For EVPN IRB mode, there are deployments which expect to be able to 102 support multiple subnets within single Bridge Domain. Each subnet 103 would be differentiated by VLAN. Thus, single IRB interface can 104 still serve multiple subnet. 106 Motivation behind such deployments are 108 1. Manageability: If there is support to have multiple subnets using 109 single bridge domain, it would require only one Bridge domain and 110 one IRB for "N" subnets compare to "N" Bridge domain and "N" IRB 111 interface to manage. 113 2. Simplicity: It avoids extra configuration by configuring Vlan 114 Range as compare to individual VLAN, BD and IRB interface per 115 subnet. 117 Multiple subnet per bridge domain deployments guarantee that there 118 would not be duplicate MAC address across subnet. 120 [RFC7432] defines three types of service interface. None of them 121 provide flexibility to achieve multiple subnet within single bridge 122 domain. Brief about existing service interface from [RFC7432] are , 124 1. VLAN-Based Service Interface: With this service interface, an 125 EVPN instance consists of only a single broadcast domain (e.g., a 126 single VLAN). Therefore, there is a one-to-one mapping between a 127 VID on this interface and a MAC-VRF. 129 2. VLAN Bundle Service Interface: With this service interface, an 130 EVPN instance corresponds to multiple broadcast domains (e.g., 131 multiple VLANs); however, only a single bridge table is 132 maintained per MAC-VRF, which means multiple VLANs share the same 133 bridge table. The MPLS-encapsulated frames MUST remain tagged 134 with the originating VID. Tag translation is NOT permitted. The 135 Ethernet Tag ID in all EVPN routes MUST be set to 0. 137 3. VLAN-Aware Bundle Service Interface: With this service interface, 138 an EVPN instance consists of multiple broadcast domains (e.g., 139 multiple VLANs) with each VLAN having its own bridge table -- 140 i.e., multiple bridge tables (one per VLAN) are maintained by a 141 single MAC-VRF corresponding to the EVPN instance. 143 Though from definition it looks like VLAN Bundle Service Interface 144 does provide flexibility to support multiple subnet within single 145 bridge domain. But it requirement is to have multiple subnet from 146 same ES on multi-homing all active mode, it would not work. For 147 example, lets take the case from Figure-1, If PE1 learns MAC of H1 on 148 Vlan 1 (subnet S1). When MAC route is originated , as per [RFC7432] 149 ether tag would be set to 0. If there is packet coming from IRB 150 interface which is untagged packet, and it reaches to PE2, PE2 does 151 not have associated AC information. In this case PE2 can not forward 152 traffic which is destined to H1. 154 This draft proposes an extension to existing service interface types 155 defined in [RFC7432] and defines AC-aware Bundling service interface. 156 AC-aware Bundling service interface would provide mechanism to have 157 multiple subnets in single bridge domain. This extension is 158 applicable only for multi-homed EVPN peers.. 160 H3 161 | 162 +----+-----+ 163 | | 164 | PE3 | EVI-1 165 | | 166 +-----------------+----------+----------------------+ 167 | | 168 | | 169 | | 170 | IP MPLS core | 171 | | 172 | | 173 | | 174 | | 175 +------+----------------------------------------+--+ 176 | | 177 +--------------+----+ +------------+------+ 178 | | | | 179 | PE1 | | PE2 | 180 | | | | 181 | +-----+ | | +-----+ | 182 | | IRB | | | | IRB | | 183 | +--+-----+--+ | | +--+-----+--+ | 184 | | BD & EVI | | | | BD & EVI | | 185 | +--+--+--+--+ | | +-----------+ | 186 | |S1|S2|S3|S4| | | |S1|S2|S3|S4| | 187 +---+--+-X+--+--+---+ +---+--+-X+--+--+---+ 188 X X 189 X X 190 X X ESI-100 191 X X EVI-1 192 X X BD-1 193 X X 194 XX 195 +-------+ 196 | CE | 197 +-+--+--+ 198 | | 199 H1 H2 201 Figure 1: EVPN topology with multi-homing and non multihoming peer 203 The above figure shows sample EVPN topology, PE1 and PE2 are 204 multihomed peers. PE3 is remote peer which is part of same EVPN 205 instance (evi1). It is showing four subnets S1, S2, S3, S4 where 206 numeric value provides associated Vlan information. 208 1.1. Problem with Unicast MAC route processing for multihome case 210 BD-1 has multiple subnet where each subnet is distinguished by Vlan 211 1, 2 ,3 and 4. PE1 learns MAC address MAC-1 from AC associated with 212 subnet S1. PE1 uses MAC route to advertise MAC-1 presence to peer 213 PEs. As per [RFC7432] MAC route advertisement from PE1 does not 214 carry any context which can provide information about MAC address 215 association with AC. When PE2 receives MAC route with MAC-2 it can 216 not determine which AC this MAC belongs too. 218 Since PE2 could not bind MAC-1 with correct AC, when it receives data 219 traffic destined to MAC-1, it can not find correct AC where data MUST 220 be forwarded. 222 1.2. Problem with Multicast route synchronization 224 [I-D.ietf-bess-evpn-igmp-mld-proxy] defines mechanism to synchronize 225 multicast routes between multihome peer. In above case if Receiver 226 behind S1 send IGMP membership request, CE could hash it to either of 227 the PE. When Multicast route is originated, it does not contain any 228 AC information. Once it reaches to remote PE, it does not have any 229 information about which subnet this IGMP membership request belong 230 to. 232 1.3. Potential Security concern caused by misconfiguration 234 In case of single subnet per bridge domain, there is potential case 235 of security issue. For example if PE1 , BD1 is configured with 236 Vlan-1 where as multihome peer PE2 has configured Vlan-2. Now each 237 of the IGMP membership request on PE1 would be synchronized to PE2. 238 and PE2 would process multicast routes and start forwarding multicast 239 traffic on Vlan-2, which was not intended. 241 2. Terminology 243 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 244 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 245 document are to be interpreted as described in [RFC2119] . 247 AC: Attachment Circuit. 249 ARP: Address Resolution Protocol. 251 BD: Broadcast Domain. As per [RFC7432], an EVI consists of a single 252 or multiple BDs. In case of VLAN-bundle and VLAN-based service 253 models (see [RFC7432]), a BD is equivalent to an EVI. In case of 254 VLAN-aware bundle service model, an EVI contains multiple BDs. Also, 255 in this document, BD and subnet are equivalent terms. 257 BD Route Target: refers to the Broadcast Domain assigned Route Target 258 [RFC4364]. In case of VLAN-aware bundle service model, all the BD 259 instances in the MAC-VRF share the same Route Target. 261 BT: Bridge Table. The instantiation of a BD in a MAC-VRF, as per 262 [RFC7432]. 264 DGW: Data Center Gateway. 266 Ethernet A-D route: Ethernet Auto-Discovery (A-D) route, as per 267 [RFC7432]. 269 Ethernet NVO tunnel: refers to Network Virtualization Overlay tunnels 270 with Ethernet payload. Examples of this type of tunnels are VXLAN or 271 GENEVE. 273 EVI: EVPN Instance spanning the NVE/PE devices that are participating 274 on that EVPN, as per [RFC7432]. 276 EVPN: Ethernet Virtual Private Networks, as per [RFC7432]. 278 GRE: Generic Routing Encapsulation. 280 GW IP: Gateway IP Address. 282 IPL: IP Prefix Length. 284 IP NVO tunnel: it refers to Network Virtualization Overlay tunnels 285 with IP payload (no MAC header in the payload) 287 IP-VRF: A VPN Routing and Forwarding table for IP routes on an NVE/ 288 PE. The IP routes could be populated by EVPN and IP-VPN address 289 families. An IP-VRF is also an instantiation of a layer 3 VPN in an 290 NVE/PE. 292 IRB: Integrated Routing and Bridging interface. It connects an IP- 293 VRF to a BD (or subnet). 295 MAC-VRF: A Virtual Routing and Forwarding table for Media Access 296 Control (MAC) addresses on an NVE/PE, as per [RFC7432]. A MAC-VRF is 297 also an instantiation of an EVI in an NVE/PE. 299 ML: MAC address length. 301 ND: Neighbor Discovery Protocol. 303 NVE: Network Virtualization Edge. 305 GENEVE: Generic Network Virtualization Encapsulation, [GENEVE]. 307 NVO: Network Virtualization Overlays. 309 RT-2: EVPN route type 2, i.e., MAC/IP advertisement route, as defined 310 in [RFC7432]. 312 RT-5: EVPN route type 5, i.e., IP Prefix route. As defined in 313 Section 3 of [EVPN-PREFIX]. 315 SBD: Supplementary Broadcast Domain. A BD that does not have any 316 ACs, only IRB interfaces, and it is used to provide connectivity 317 among all the IP-VRFs of the tenant. The SBD is only required in IP- 318 VRF- to-IP-VRF use-cases (see Section 4.4.). 320 SN: Subnet. 322 TS: Tenant System. 324 VA: Virtual Appliance. 326 VNI: Virtual Network Identifier. As in [RFC8365], the term is used 327 as a representation of a 24-bit NVO instance identifier, with the 328 understanding that VNI will refer to a VXLAN Network Identifier in 329 VXLAN, or Virtual Network Identifier in GENEVE, etc. unless it is 330 stated otherwise. 332 VTEP: VXLAN Termination End Point, as in [RFC7348]. 334 VXLAN: Virtual Extensible LAN, as in [RFC7348]. 336 This document also assumes familiarity with the terminology of 337 [RFC7432],[RFC8365], [RFC7365]. 339 3. Requirements 341 1. Service interface MUST be able to support multiple subnets 342 designated by Vlan under single bridge domain. 344 2. Service interface MUST be applicable to Multihomed peers only 346 3. New Service interface handling procedure MUST make sure to have 347 backward compatibility with implementation procedures defined in 348 [RFC7432] 350 4. New Service interface MUST be extendible to multicast routes 351 defined in [I-D.ietf-bess-evpn-igmp-mld-proxy] too. 353 4. Solution Description 354 H3 355 | 356 +----+-----+ 357 | | 358 | PE3 | EVI-1 359 | | 360 +-----------------+----------+----------------------+ 361 | | 362 | | 363 | | 364 | IP MPLS core | 365 | | 366 | | 367 | | 368 | | 369 +------+----------------------------------------+--+ 370 | | 371 +--------------+----+ +------------+------+ 372 | | | | 373 | PE1 | | PE2 | 374 | | | | 375 | +-----+ | | +-----+ | 376 | | IRB | | | | IRB | | 377 | +--+-----+--+ | | +--+-----+--+ | 378 | | BD & EVI | | | | BD & EVI | | 379 | +--+--+--+--+ | | +-----------+ | 380 | |S1|S2|S3|S4| | | |S1|S2|S3|S4| | 381 +---+--+-X+--+--+---+ +---+--+-X+--+--+---+ 382 X X 383 X X 384 X X ESI-100 385 X X EVI-1 386 X X BD-1 387 X X 388 XX 389 +-------+ 390 | CE | 391 +-+--+--+ 392 | | 393 H1 H2 394 MAC-1 MAC-2 395 Vlan-1 Vlan-2 396 (S,G) (S,G) ------> Multicast receiver 398 Figure 2: AC aware bundling procedures 399 Consider the above topology, where AC aware bundling service 400 interface is supported. Host H1 on Vlan-1 has MAC address as MAC-1 401 and Host H2 on Vlan 2 has MAC address as MAC-2. 403 4.1. Control Plane Operation 405 4.1.1. MAC/IP Address Advertisement 407 4.1.1.1. Local Unicast MAC learning 409 1. [RFC7432] section 9.1 describes different mechanism to learn 410 Unicast MAC address locally. PEs where AC aware bundling is 411 supported, MAC address is learnt along with Vlan associated with 412 AC. 414 2. MAC/IP route construction follows mechanism defined in [RFC7432] 415 section 9.2.1. Along with RT-2 it must attach Attachment Circuit 416 ID Extended Community (Section 6.1). 418 3. From Figure-2 PE1 learns MAC-1 on S1. It MUST construct MAC 419 route with procedure defined in [RFC7432] section 9.2.1. It MUST 420 attach Attachment Circuit ID Extended Community (Section 6.1). 422 4.1.1.2. Remote Unicast MAC learning 424 1. Presence of Attachment Circuit ID Extended Community 425 (Section 6.1) MUST be ignored by non multihoming PEs. Remote PE 426 (Non Multihome PE) MUST process MAC route as defined in [RFC7432] 428 2. Multihoming peer MUST process Attachment Circuit ID Extended 429 Community (Section 6.1) to attach remote MAC address to 430 appropriate AC. 432 3. From Figure-2 PE3 receives MAC route for MAC-1. It MUST not 433 ignore AC information in Attachment Circuit ID Extended Community 434 (Section 6.1) which was received with RT-2. 436 4. PE2 receives MAC route for MAC-1. It MUST get Attachment Circuit 437 ID from Attachment Circuit ID Extended Community (Section 6.1) in 438 RT-2 and associate MAC address with specific subnet. 440 4.1.2. Multicast route Advertisement 442 4.1.2.1. Local multicast state 444 When a local multihomed bridge port in given BD receives IGMP 445 membership request and ES is operating in All-active or Single-Active 446 redundancy mode, it MUST synchronize multicast state by originating 447 multicast route defined in section 7 of 448 [I-D.ietf-bess-evpn-igmp-mld-proxy]. When Service interface is AC 449 aware it MUST attach Attachment Circuit ID Extended Community 450 (Section 6.1) along with multicast route. For example in Figure-2 451 when H2 sends IGMP membership request for (S,G) , CE hashed it to one 452 of the PE. Lets say PE1 received IGMP membership request, now PE1 453 MUST originate multicast route to synchronize multicast state with 454 PE2. Multicast route MUST contain Attachment Circuit ID Extended 455 Community (Section 6.1) along with multicast route. 457 If PE1 had already originated multicast route for (S,G) from subnet 458 S2. Now if host H1 also sends IGMP membership request for (S,G) on 459 subnet S1, PE1 MUST originate route update with Attachment Circuit ID 460 Extended Community (Section 6.1). 462 4.1.2.2. Remote multicast state 464 If multihomed PE receives remote multicast route on Bridge Domain for 465 given ES, route MUST be programmed to correct subnet. Subnet 466 information MUST be get from Attachment Circuit ID Extended 467 Community. For example PE2 receives multicast route on Bridge Domain 468 BD-1 for ES ESI-100, From Attachment Circuit ID Extended Community 469 (Section 6.1) it receives AC information and associates multicast 470 route (S,G) to subnet S2. 472 When PE2 receives route update with Attachment Circuit ID Extended 473 Community added for subnet S1, port associated with subnet S1 MUST be 474 added for multicast route. 476 4.2. Data Plane Operation 478 4.2.1. Unicast Forwarding 480 1. Packet received from CE must follow same procedure as defined in 481 [RFC7432] section 13.1 483 2. Unknown Unicast packets from a Remote PE MUST follow procedure as 484 per [RFC7432] section 13.2.1. 486 3. Known unicast Received on a Remote PE MUST follow procedure as 487 per [RFC7432] section 13.2.2. So in Figure-2 if PE3 receives 488 known unicast packet for destination MAC MAC-1, it MUST follow 489 procedure defined in [RFC7432] section 13.2.2. 491 4. If destination MAC lookup is performed on known unicast packet, 492 destination MAC lookup MUST provide Vlan and Port tuple. For 493 example if PE2 receives unicast packet which is destined to MAC-1 494 (packet might be coming from IRB or remote PE with EVPN tunnel), 495 destination MAC lookup on PE2 MUST provide outgoing port along 496 with associated MAC address. In this case traffic MUST be 497 forwarded to S1 with Vlan 1. 499 4.2.2. Multicast Forwarding 501 1. Multicast traffic from CE and remote PE MUST follow procedure 502 defined in [RFC7432] 504 2. Multicast traffic received from IRB interface or EVPN tunnel, 505 route lookup would be performed based on IGMP snooping state and 506 traffic would be forwarded to appropriate AC. 508 5. Mis-configuration of VLAN ranges across multihoming peer 510 If there is mis-configuration of Vlan or Vlan range across 511 multihoming peer, same MAC address would be learnt with different 512 Vlan in Bridge Domain. In this case Error message MUST be thrown for 513 operator to make configuration changes. errored MAC route MUST be 514 ignored. 516 6. BGP Encoding 518 This document defines one new BGP Extended Community for EVPN. 520 6.1. Attachment Circuit ID Extended Community 522 A new EVPN BGP Extended Community called Attachment Circuit ID is 523 introduced here. This new extended community is a transitive 524 extended community with the Type field of 0x06 (EVPN) and the Sub- 525 Type of TBD. It is advertised along with EVPN MAC/IP Advertisement 526 Route (Route Type 2) per [RFC7432] for AC-Aware Bundling Service 527 Interface. 529 The Attachment Circuit ID Extended Community is encoded as an 8-octet 530 value as follows: 532 0 1 2 3 533 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 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Type=0x06 | Sub-Type=TBD | Reserved (16 bits) | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Attachment Circuit ID (32 bits) | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 Figure 2: Attachment Circuit ID Extended Community 542 This extended community is used to carry the Attachment Circuit ID 543 associated with the received MAC address and it is advertised along 544 with EVPN MAC/IP Advertisement route. The receiving PE who is a 545 member of an All-Active multi-homing group uses this information to 546 not only synchronize the MAC address but also the associated AC over 547 which the MAC addresses is received. 549 7. Security Considerations 551 The same Security Considerations described in [RFC7432] are valid for 552 this document. 554 8. IANA Considerations 556 A new transitive extended community Type of 0x06 and Sub-Type of TBD 557 for EVPN Attachment Circuit Extended Community needs to be allocated 558 by IANA. 560 9. Acknowledgement 562 10. References 564 10.1. Normative References 566 [I-D.ietf-bess-evpn-igmp-mld-proxy] 567 Sajassi, A., Thoria, S., Patel, K., Yeung, D., Drake, J., 568 and W. Lin, "IGMP and MLD Proxy for EVPN", draft-ietf- 569 bess-evpn-igmp-mld-proxy-00 (work in progress), March 570 2017. 572 [I-D.ietf-bess-evpn-prefix-advertisement] 573 Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. 574 Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf- 575 bess-evpn-prefix-advertisement-11 (work in progress), May 576 2018. 578 [I-D.ietf-idr-tunnel-encaps] 579 Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel 580 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-10 581 (work in progress), August 2018. 583 10.2. Informative References 585 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 586 Requirement Levels", BCP 14, RFC 2119, 587 DOI 10.17487/RFC2119, March 1997, 588 . 590 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 591 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 592 eXtensible Local Area Network (VXLAN): A Framework for 593 Overlaying Virtualized Layer 2 Networks over Layer 3 594 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 595 . 597 [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 598 Rekhter, "Framework for Data Center (DC) Network 599 Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 600 2014, . 602 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 603 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 604 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 605 2015, . 607 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 608 Uttaro, J., and W. Henderickx, "A Network Virtualization 609 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 610 DOI 10.17487/RFC8365, March 2018, 611 . 613 Authors' Addresses 615 Ali Sajassi 616 Cisco Systems 617 821 Alder Drive, 618 MILPITAS, CALIFORNIA 95035 619 UNITED STATES 621 Email: sajassi@cisco.com 623 Mankamana Mishra 624 Cisco Systems 625 821 Alder Drive, 626 MILPITAS, CALIFORNIA 95035 627 UNITED STATES 629 Email: mankamis@cisco.com 630 Samir Thoria 631 Cisco Systems 632 821 Alder Drive, 633 MILPITAS, CALIFORNIA 95035 634 UNITED STATES 636 Email: sthoria@cisco.com 638 Patrice Brissette 639 Cisco Systems 641 Email: pbrisset@cisco.com 643 Jorge Rabadan 644 Nokia 645 777 E. Middlefield Road 646 Mountain View, CA 94043 647 UNITED STATES 649 Email: jorge.rabadan@nokia.com 651 John Drake 652 Juniper Networks 654 Email: jdrake@juniper.net