idnits 2.17.1 draft-keyupate-evpn-virtual-hub-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 2, 2015) is 3218 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: 'I-D.EVPN-overlay' is mentioned on line 203, but not defined == Unused Reference: 'I-D.ietf-l2vpn-evpn' is defined on line 413, but no explicit reference was found in the text == Unused Reference: 'RFC1771' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'RFC2784' is defined on line 424, but no explicit reference was found in the text == Unused Reference: 'RFC3484' is defined on line 428, but no explicit reference was found in the text == Unused Reference: 'RFC3931' is defined on line 431, but no explicit reference was found in the text == Unused Reference: 'RFC4213' is defined on line 434, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 437, but no explicit reference was found in the text == Unused Reference: 'RFC4374' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'RFC6459' is defined on line 443, but no explicit reference was found in the text == Unused Reference: 'I-D.drao-bgp-l3vpn-virtual-network-overlays' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bess-evpn-overlay' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'RFC4389' is defined on line 470, but no explicit reference was found in the text == Unused Reference: 'RFC7080' is defined on line 477, but no explicit reference was found in the text == Unused Reference: 'RFC7209' is defined on line 481, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Downref: Normative reference to an Informational RFC: RFC 4374 ** Downref: Normative reference to an Informational RFC: RFC 6459 == Outdated reference: A later version (-12) exists of draft-ietf-bess-evpn-overlay-01 Summary: 4 errors (**), 0 flaws (~~), 18 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L2VPNs K. Patel 3 Internet-Draft A. Sajassi 4 Intended status: Standards Track Cisco Systems 5 Expires: January 3, 2016 J. Drake 6 Juniper Networks, Inc. 7 W. Henderickx 8 Alcatel-Lucent 9 July 2, 2015 11 Virtual Hub-and-Spoke in BGP EVPNs 12 draft-keyupate-evpn-virtual-hub-00 14 Abstract 16 Ethernet Virtual Private Network (EVPN) solution is becoming 17 pervasive for Network Virtualization Overlay (NVO) services in data 18 center (DC) applications and as the next generation virtual private 19 LAN services in service provider (SP) applications. 21 The use of host IP default route and host unknown MAC route within a 22 DC is well understood in order to ensure that leaf nodes within a DC 23 only learn and store host MAC and IP addresses for that DC. All 24 other host MAC and IP addresses from remote DCs are learned and 25 stored in DC GW nodes thus alleviating leaf nodes from learning host 26 MAC and IP addresses from the remote DCs. 28 This draft further optimizes the MAC and IP address learning at the 29 leaf nodes such that a leaf node within a DC only needs to learn and 30 store MAC and IP addresses associated with the sites directly 31 connected to it. A leaf node does not need to learn and store MAC 32 and IP addresses from any other leaf nodes thus reducing the number 33 of learned MACs and IP addresses per EVI substantially. 35 The modifications provided by this draft updates and extends RFC7024 36 for BGP EVPN Address Family. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on January 3, 2016. 55 Copyright Notice 57 Copyright (c) 2015 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 74 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 4. Routing Information Exchange for EVPN routes . . . . . . . . 4 76 5. EVPN unknown MAC Route . . . . . . . . . . . . . . . . . . . 5 77 5.1. Originating EVPN Unknown MAC Route by a V-Hub . . . . . . 5 78 5.2. Processing VPN-MAC EVPN unknown Route by a V-SPOKE . . . 5 79 5.3. Aliasing . . . . . . . . . . . . . . . . . . . . . . . . 5 80 5.4. Split-Horizon And Mass Withdraw . . . . . . . . . . . . . 6 81 6. Forwarding Considerations . . . . . . . . . . . . . . . . . . 7 82 6.1. IP-only Forwarding . . . . . . . . . . . . . . . . . . . 7 83 6.2. MAC-only Forwarding - Bridging . . . . . . . . . . . . . 7 84 6.3. MAC and IP Forwarding - IRB . . . . . . . . . . . . . . . 7 85 7. Handling of the Broadcast and Multicast traffic . . . . . . . 8 86 8. ARP/ND Suppression . . . . . . . . . . . . . . . . . . . . . 8 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 88 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 89 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 90 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 9 91 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 92 13.1. Normative References . . . . . . . . . . . . . . . . . . 9 93 13.2. Informative References . . . . . . . . . . . . . . . . . 10 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 96 1. Introduction 98 Ethernet Virtual Private Network (EVPN) solution is becoming 99 pervasive for Network Virtualization Overlay (NVO) services in data 100 center (DC) applications and as the next generation virtual private 101 LAN services in service provider (SP) applications. 103 With EVPN, providing any-to-any connectivity among sites of a given 104 EVPN Instance (EVI) would require each Provider Edge (PE) router 105 connected to one or more of these sites to hold all the host MAC and 106 IP addresses for that EVI. The use of host IP default route and host 107 unknown MAC route within a DC is well understood in order to 108 alleviate the learning of host MAC and IP addresses to only leaf 109 nodes (PEs) within that DC. All other host MAC and IP addresses from 110 remote DCs are learned and stored in DC GW nodes thus alleviating 111 leaf nodes from learning host MAC and IP addresses from the remote 112 DCs. 114 This draft further optimizes the MAC and IP address learning at the 115 leaf nodes such that a leaf node within a DC only needs to learn and 116 store MAC and IP addresses associated with the sites directly 117 connected to it. A leaf node does not need to learn and store MAC 118 and IP addresses from any other leaf nodes thus reducing the number 119 of learned MACs and IP addresses per EVI substantially. 121 [RFC7024] provides rules for Hub and Spoke VPNs for BGP L3VPNs. This 122 draft updates and extends [RFC7024] for BGP EVPN Address Family. 123 This draft provides rules for Originating and Processing of the EVPN 124 host unknown MAC route and host default IP route by EVPN Virtual Hub 125 (V-HUB). This draft also provides rules for the handling of the BUM 126 traffic in Hub and Spoke EVPNs and handling of ARP suppression. 128 The leaf nodes and DC GW nodes in a data center are referred to as 129 Virtual Spokes (V-spokes) and Virtual Hubs (V-hubs) respectively. A 130 set of V-spoke can be associated with one or more V-hubs. If a V- 131 spokes is associated with more than one V-hubs, then it can load 132 balanced traffic among these V-hubs. Different V-spokes can be 133 associated with different sets of V-hubs such that at one extreme 134 each V-spoke can have a different V-hub set although this may not be 135 desirable and a more typical scenario may be to associate a set of V- 136 spokes to a set of V-hubs - e.g., topology for a DC POD where a set 137 of V-spokes are associated with a set of spine nodes or DC GW nodes. 139 In order to avoid repeating many of the materials covered in 140 [RFC7024], this draft is written as a delta document with its 141 sections organized to follow those of that RFC with only delta 142 description pertinent to EVPN operation in each section. Therefore, 143 it is assumed that the readers are very familiar with [RFC7024] and 144 EVPN. 146 2. Requirements Language 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 150 be interpreted as described in [RFC2119] only when they appear in all 151 upper case. They may also appear in lower or mixed case as English 152 words, without any normative meaning. 154 3. Terminology 156 ARP: Address Resolution Protocol 157 BEB: Backbone Edge Bridge 158 B-MAC: Backbone MAC Address 159 CE: Customer Edge 160 C-MAC: Customer/Client MAC Address 161 ES: Ethernet Segment 162 ESI: Ethernet Segment Identifier 163 IRB: Integrated Routing and Bridging 164 LSP: Label Switched Path 165 MP2MP: Multipoint to Multipoint 166 MP2P: Multipoint to Point 167 ND: Neighbor Discovery 168 NA: Neighbor Advertisement 169 P2MP: Point to Multipoint 170 P2P: Point to Point 171 PE: Provider Edge 172 EVPN: Ethernet VPN 173 EVI: EVPN Instance 174 RT: Route Target 176 Single-Active Redundancy Mode: When only a single PE, among a group 177 of PEs attached to an Ethernet segment, is allowed to forward traffic 178 to/from that Ethernet Segment, then the Ethernet segment is defined 179 to be operating in Single-Active redundancy mode. 181 All-Active Redundancy Mode: When all PEs attached to an Ethernet 182 segment are allowed to forward traffic to/from that Ethernet Segment, 183 then the Ethernet segment is defined to be operating in All-Active 184 redundancy mode. 186 4. Routing Information Exchange for EVPN routes 188 [RFC7024] defines multiple Route Types NLRI along with procedures for 189 advertisements and processing of these routes. Some of these 190 procedures are impacted as the result of hub-and-spoke architecture. 192 The routing information exchange among the hub, spoke, and vanilla 193 PEs are subject to the same rules as described in section 3 of 194 [RFC7024]. Furthermore, if there are any changes to the EVPN route 195 advisements and processing from advertisements and processing from 196 [RFC7024], they are described below. 198 5. EVPN unknown MAC Route 200 Section 3 of [RFC7024] talks about how a V-hub of a given VPN must 201 export a VPN-IP default route for that VPN and this route must be 202 exported to only the V-spokes of that VPN associated with that V-hub. 203 [I-D.EVPN-overlay] defines the notion of the unknown MAC route for an 204 EVI which is analogous to a VPN-IP default route for a VPN. This 205 unknown MAC route is exported by a V-hub to its associated V-spokes. 206 If multiple V-hubs are associated with a set of V-spokes, then each 207 V- hub advertises it with a distinct RD when originating this route. 208 If a V-spoke imports several of these unknown MAC routes and they all 209 have the same preference, then traffic from the V-spoke to other 210 sites of that EVI would be load balanced among the V-hubs. 212 5.1. Originating EVPN Unknown MAC Route by a V-Hub 214 Section 7.3 of the [RFC7024] defines procedures for originating a 215 VPN-IP default route for a VPN. The same procuedures apply when a 216 V-hub wants to originate EVPN unknown MAC route for a given EVI. The 217 V-hub MUST announce unknown MAC route using the MAC/IP advertisement 218 route along with the Default Gateway extended community as defined in 219 section 10.1 of the [RFC7432]. 221 5.2. Processing VPN-MAC EVPN unknown Route by a V-SPOKE 223 Within a given EVPN, a V-spoke MUST import all the unknown MAC routes 224 unless the route-target mismatch happens. The processing of the 225 received VPN-MAC EVPN default route follows the rules explained in 226 the section 3 of the [RFC7024]. The unknown MAC route MUST be 227 installed according to the rules of MAC/IP Advertisement route 228 installation rules in section 9.2.2 of [RFC7024]. 230 In absense of any more specific VPN-MAC EVPN routes, V-spokes 231 installing the unknown MAC route MUST use the route when performing 232 ARP proxy. This behavior would allow V-Spokes to forward the traffic 233 towards V-Hub. 235 5.3. Aliasing 237 [RFC7432] describes the concept and procedures for Aliasing where a 238 station is multi-homed to multiple PEs operating in an All-Active 239 redundancy mode, it is possible that only a single PE learns a set of 240 MAC addresses associated with traffic transmitted by the station. 241 [RFC7432] describes the concepts and procedures for Aliasing, which 242 occurs when a CE is multi-homed to multiple PE nodes, operating in 243 all-active redundancy mode, but not all of the PEs learn the CE's set 244 of MAC addresses. This leads to a situation where remote PEs receive 245 MAC advertisement routes, for these addresses, from a single NVE even 246 though multiple NVEs are connected to the multi-homed station. As a 247 result, the remote NVEs are not able to effectively load-balance 248 traffic among the NVEs connected to the multi-homed Ethernet segment. 250 To alleviate this issue, EVPN introduces the concept of Aliasing. 251 This refers to the ability of a PE to signal that it has reachability 252 to a given locally attached Ethernet segment, even when it has learnt 253 no MAC addresses from that segment. The Ethernet A-D per-EVI route 254 is used to that end. Remote PEs which receive MAC advertisement 255 routes with non-zero ESI SHOULD consider the MAC address as reachable 256 via all NVEs that advertise reachability to the relevant Segment 257 using Ethernet A-D routes with the same ESI and with the Single- 258 Active flag reset. 260 This procedure is impacted for virtual hub-and-spoke topology because 261 a given V-spoke does not receive any MAC/IP advertisements from 262 remote V-spokes; therefore, there is no point in propagating Ethernet 263 A-D per-EVI route to the remote V-spokes. In this solution, the V- 264 hubs terminate the Ethernet A-D per-EVI route (used for Aliasing) and 265 follows the procedures described in [RFC7432] for handling this 266 route. 268 There are scenarios for which it is desirable to establish direct 269 communication path between a pair of V-spokes for a given host MAC 270 address. In such scenario, the advertising V-spoke advertises both 271 the MAC/IP route and Ethernet A-D per-EVI route with the RT of V-hub 272 (RT-VH) per section 3 of [RFC7024]. The use of RT-VH, ensures that 273 these routes are received by the V-spokes associated with that V-hub 274 set and thus enables the V-spokes to perform the Aliasing procedure. 276 In summary, PE devices (V-hubs in general and V-spokes occasionally) 277 that receive EVPN MAC/IP route advertisements (associated with a 278 multi-homed site) need to also receive the associated Ethernet A-D 279 per-EVI route advertisement(s) in order for them to perform Aliasing 280 procedure. 282 5.4. Split-Horizon And Mass Withdraw 284 [RFC7432] uses Ethernet A-D per-ES route to a) signal to remote PEs 285 the multi-homing redundancy type (Single-Active versus All-Active), 286 b) advertise ESI label for split-horizon filtering when MPLS 287 encapsulation is used, and c) advertise mass-withdraw when a failure 288 of an access interface impacts many MAC addresses. This route does 289 not need to be advertise from a V-spoke to any remote V-spoke unless 290 a direct communication path between a pair of spoke is needed for a 291 given flow. 293 Even if communication between a pair of V-spoke is needed for just a 294 single flow, the Ethernet A-D per ES route needs to be advertised 295 from the originating V-spoke for that ES which may handle tens or 296 hundreds of thousands of flows. This is because in order to perform 297 Aliasing function for a given flow, the Ethernet A-D per-EVI route is 298 needed and this route itself is dependent on the Ethernet A-D per-ES 299 route. In such scenario, the advertising V-spoke advertises the 300 Ethernet A-D per-ES route with the RT of V-hub (RT-VH) per section 3 301 of [RFC7024]. 303 In summary, PE devices (V-hubs in general and V-spokes occasionally) 304 that receive EVPN MAC/IP route advertisements (associated with a 305 multi-homed site) need to also receive the associated Ethernet A-D 306 per-ES route advertisement(s). 308 6. Forwarding Considerations 310 6.1. IP-only Forwarding 312 When EVPN operates in IP-only forwarding mode using EVPN Route Type 313 5, then all forwarding considerations in section 4 of [RFC7024] are 314 directly applicable here. 316 6.2. MAC-only Forwarding - Bridging 318 When EVPN operates in MAC-only forwarding mode (i.e., bridging mode), 319 then for a given EVI, the MPLS label that a V-hub advertises with an 320 Unknown MAC address MUST be the label that identifies the MAC-VRF of 321 the V-hub in absense of a more specific MAC route. When the V-hub 322 receives a packet with such label, the V- hub pops the label and 323 determines further disposition of the packet based on the lookup in 324 the MAC-VRF. Otherwise, the MPLS label of the matching more specific 325 route is used and packet is is forwarded towards the associated 326 NEXTHOP of the more specific route. 328 6.3. MAC and IP Forwarding - IRB 330 When a EVPN speaker operates in IRB mode, it implements both the "IP 331 and MAC forwarding Modes" (aka Integrated Routing and Bridging - 332 IRB). On a packet by packet basis, the V-spoke decides whether to do 333 forwarding based on a MAC address lookup (bridge) or based on a IP 334 address lookup (route). If the host destination MAC address is that 335 of the IRB interface (i.e., if the traffic is inter-subnet), then the 336 V-spoke performs an additional IP lookup in the IP-VRF. However, if 337 the host destination MAC address is that of an actual host MAC 338 address (i.e., the traffic is intra-subnet) , then the V-spoke only 339 performs a MAC lookup in the MAC-VRF. The procedure specified in 340 Section 6.1 and Section 6.2 are applicable to inter-subnet and intra- 341 subnet forwarding respectively. For intra-subnet traffic, if the MAC 342 address is not found in the MAC-VRF, then the V-spoke forwards the 343 traffic to the V-hub with the MPLS label received from the V-hub for 344 the unknown MAC address. For the Inter-subnet traffic, if the IP 345 prefix is not found in the IP-VRF, then the V-spoke forwards the 346 traffic to the V-hub with the MPLS label received from the V-hub for 347 the default IP address. 349 7. Handling of the Broadcast and Multicast traffic 351 The handling of the Broadcast and Multicast traffic should be done 352 according to the EVPN rules described in [RFC7432]. 354 8. ARP/ND Suppression 356 [RFC7432] defines the procedures for ARP/ND suppression where a PE 357 can terminate gratuitous ARP/ND request message from directly 358 connected site and advertises the associated MAC and IP addresses in 359 an EVPN MAC/IP advertisement route to all other remote PEs. The 360 remote PEs that receive this EVPN route advertisement, install the 361 MAC/IP pair in their ARP/ND cache table thus enabling them to 362 terminate ARP/ND requests and generate ARP/ND responses locally thus 363 suppressing the flooding of ARP/ND requests over the EVPN network. 365 In this hub-and-spoke approach, the ARP suppression needs to be 366 performed by both the EVPN V-hubs as well V-spokes as follow. When a 367 V-Spoke receives a gratuitous ARP/ND request, it terminates it and 368 stores the source MAC/IP pair in its ARP/ND cache table. Then, it 369 advertises the source MAC/IP pair to its associated V-Hubs using EVPN 370 MAC/IP advertisement route. The V-Hubs upon receiving this EVPN 371 route advertisement, create an entry in their ARP/ND cache table for 372 this MAC/IP pair. 374 Now when a V-Spoke receives an ARP/ND request, it first looks up its 375 ARP cache table, if an entry for that MAC/IP pair is found, then an 376 ARP/ND response is generated locally and sent to the CE. However, if 377 an entry is not found, then the ARP/ND request is unicasted to one of 378 the V-hub associated with this V-spoke. Since, the associated V-hub 379 keeps all the MAC/IP ARP entries in its cache table, it can formulate 380 and ARP/ND response and forward it to that CE via the corresponding 381 V-spoke. 383 9. IANA Considerations 385 This document does NOT make any new requests for IANA allocations. 387 10. Security Considerations 389 All the security considerations in [RFC7432] apply directly to this 390 document because this document leverages [RFC7432] control plane and 391 their associated procedures - although not the complete set but 392 rather a subset. 394 This draft does not introduce any new security considerations beyond 395 that of [RFC7432] and [RFC4761] because advertisements and processing 396 of B-MAC addresses follow that of [RFC7432] and processing of C-MAC 397 addresses follow that of [RFC4761] - i.e, B-MAC addresses are learned 398 in control plane and C-MAC addresses are learned in data plane. 400 11. Acknowledgements 402 The authors would like to thank Yakov Rekhter for initial idea 403 discussions. 405 12. Change Log 407 Initial Version: Sep 21 2014 409 13. References 411 13.1. Normative References 413 [I-D.ietf-l2vpn-evpn] 414 Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J. 415 Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn- 416 evpn-11 (work in progress), October 2014. 418 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- 419 4)", RFC 1771, March 1995. 421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 422 Requirement Levels", BCP 14, RFC 2119, March 1997. 424 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 425 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 426 March 2000. 428 [RFC3484] Draves, R., "Default Address Selection for Internet 429 Protocol version 6 (IPv6)", RFC 3484, February 2003. 431 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 432 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 434 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 435 for IPv6 Hosts and Routers", RFC 4213, October 2005. 437 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 438 Protocol 4 (BGP-4)", RFC 4271, January 2006. 440 [RFC4374] McCobb, G., "The application/xv+xml Media Type", RFC 4374, 441 January 2006. 443 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 444 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 445 Partnership Project (3GPP) Evolved Packet System (EPS)", 446 RFC 6459, January 2012. 448 [RFC7024] Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, 449 Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS 450 VPNs", RFC 7024, October 2013. 452 [RFC7432] Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, 453 J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet 454 VPN", RFC 7432, February 2015. 456 13.2. Informative References 458 [I-D.drao-bgp-l3vpn-virtual-network-overlays] 459 Rao, D., Mullooly, J., and R. Fernando, "Layer-3 virtual 460 network overlays based on BGP Layer-3 VPNs", draft-drao- 461 bgp-l3vpn-virtual-network-overlays-03 (work in progress), 462 July 2014. 464 [I-D.ietf-bess-evpn-overlay] 465 Sajassi, A., Drake, J., Bitar, N., Isaac, A., Uttaro, J., 466 and W. Henderickx, "A Network Virtualization Overlay 467 Solution using EVPN", draft-ietf-bess-evpn-overlay-01 468 (work in progress), February 2015. 470 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 471 Proxies (ND Proxy)", RFC 4389, April 2006. 473 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 474 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 475 4761, January 2007. 477 [RFC7080] Sajassi, A., Salam, S., Bitar, N., and F. Balus, "Virtual 478 Private LAN Service (VPLS) Interoperability with Provider 479 Backbone Bridges", RFC 7080, December 2013. 481 [RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N., 482 Henderickx, W., and A. Isaac, "Requirements for Ethernet 483 VPN (EVPN)", RFC 7209, May 2014. 485 Authors' Addresses 487 Keyur Patel 488 Cisco Systems 489 170 W. Tasman Drive 490 San Jose, CA 95124 95134 491 USA 493 Email: keyupate@cisco.com 495 Ali Sajassi 496 Cisco Systems 497 170 W. Tasman Drive 498 San Jose, CA 95124 95134 499 USA 501 Email: sajassi@cisco.com 503 John E. Drake 504 Juniper Networks, Inc. 506 Email: jdrake@juniper.net 508 Wim Henderickx 509 Alcatel-Lucent 511 Email: wim.henderickx@alcatel-lucent.com