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