idnits 2.17.00 (12 Aug 2021) /tmp/idnits8087/draft-sajassi-l2vpn-evpn-ipvpn-interop-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 : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 21, 2013) is 3127 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: 'E-VPN' is mentioned on line 102, but not defined == Missing Reference: 'RFC4862' is mentioned on line 211, but not defined == Missing Reference: 'L3VPN-ENDSYSTEM' is mentioned on line 288, but not defined == Missing Reference: 'EVPN-REQ' is mentioned on line 385, but not defined == Unused Reference: 'EVPN' is defined on line 547, but no explicit reference was found in the text == Outdated reference: draft-ietf-l2vpn-evpn has been published as RFC 7432 == Outdated reference: A later version (-07) exists of draft-raggarwa-data-center-mobility-03 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L2VPN Workgroup Ali Sajassi 3 INTERNET-DRAFT Samer Salam 4 Intended Status: Standards Track Keyur Patel 5 Cisco 6 Wim Henderickx 7 Alcatel-Lucent Nabil Bitar 8 Verizon 9 Yakov Rekhter 10 John Drake Aldrin Isaac 11 Juniper Bloomberg 13 Dennis Cai Jim Uttaro 14 Cisco AT&T 16 Expires: April 21, 2014 October 21, 2013 18 E-VPN and IP-VPN Integrated Solution 19 draft-sajassi-l2vpn-evpn-ipvpn-interop-02 21 Abstract 23 E-VPN can be an integral part of an Integrated Routing and Bridging 24 (IRB) solution which is capable of performing optimum unicast and 25 multicast forwarding not just for L2 traffic but also for L3 traffic. 26 This document describes how an IRB solution based on E-VPN can 27 interoperate seamlessly with the IP-VPN solution over MPLS and IP 28 networks. 30 Status of this Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as 38 Internet-Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/1id-abstracts.html 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 Copyright and License Notice 52 Copyright (c) 2012 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 (http://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 0 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1 Shortcomings of L2-Only Solution . . . . . . . . . . . . . . 4 70 1.2 Shortcomings of L3-Only Solution . . . . . . . . . . . . . . 5 71 1.3 Combined L2 & L3 Solution: IRB . . . . . . . . . . . . . . . 7 72 2 Seamless Interoperability with IP-VPN PEs . . . . . . . . . . . 7 73 2.1 Interoperability Use-Cases . . . . . . . . . . . . . . . . . 7 74 2.1.1 IP-VPN Clients Access to Cloud Services . . . . . . . . 8 75 2.1.2 Communication with IP-VPN NVEs . . . . . . . . . . . . . 8 76 2.1.3 Communication with IP-VPN GWs . . . . . . . . . . . . . 9 77 2.2 Characteristics of Seamless Interoperability . . . . . . . . 9 78 3 An IRB Solution Based on E-VPN . . . . . . . . . . . . . . . . 10 79 3.1 E-VPN PE Model for Seamless Interoperability . . . . . . . 10 80 3.2 IP-VPN BGP support on E-VPN PEs . . . . . . . . . . . . . . 13 81 3.3 Handling Multi-Destination Traffic: . . . . . . . . . . . . 13 82 3.2.1 Further optimization on RR . . . . . . . . . . . . . . . 14 83 5 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 14 84 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 14 85 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 86 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 8.1 Normative References . . . . . . . . . . . . . . . . . . . 14 88 8.2 Informative References . . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 91 0 Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 1 Introduction 99 E-VPN can be an integral part of an Integrated Routing and Bridging 100 (IRB) solution which is capable of performing optimum unicast and 101 multicast forwarding not just for L2 traffic (intra-subnet 102 forwarding), as described in the baseline draft [E-VPN], but also is 103 capable of performing optimum unicast and multicast forwarding for L3 104 traffic (inter-subnet forwarding) as described in [DC-MOBILITY]. 106 Such IRB capability is of high relevance in data center applications 107 where performing either L2 or L3 forwarding alone may not be 108 sufficient. 110 1.1 Shortcomings of L2-Only Solution 112 Figure-1 depicts a Data Center Network (DCN) using IP overlay where 113 the PE functionality (and IP tunnel encapsulation) are either 114 residing on physical Top of Rack (ToR) switches or on virtual 115 hypervisor-based switches. In this document, we refer to these PE 116 devices (either physical or virtual) that provide IP overlay 117 tunneling as Network Virtualized Endpoints (NVEs). The DCN is 118 connected to the outside world via Data Center gateway (DC GW) nodes. 119 These nodes provide Data Center Interconnect and connectivity to 120 Internet and VPN customers. 122 ,---------. 123 ,' `. 124 ( IP/MPLS ) 125 `. ,' 126 `-+------+' 127 +--+--+ +-+---+ 128 |DC GW|+-+|DC GW| 129 +-+---+ +-----+ 130 / 131 +----+---+ +---+-----+ 132 | Core | | Core | 133 | IP SW | | IP SW | 134 +-+----`.+ +-+---+---+ 135 / .' 136 +---+--+ +-`.+--+ +--+----+ 137 | ToR | | ToR | | ToR | 138 +-+--`.+ +-+-`.-+ +-+--+--+ 139 / / / 140 __/_ / /_ ____ 141 :VSw : :VSw : :VSw : :VSw : 142 '----' '----' '----' '----' 143 | | | | 144 VM1 VM2 VM3 VM4 146 Figure 1: A typical DC network 148 If Network Virtualization Endpoints (NVEs) were only to provide L2 149 service (and forwarding), then for two VMs on two different subnets, 150 which need to communicate with each other, their packets need to be 151 forwarded to a router (either physical or virtual). In the above 152 diagram, the packets from the VMs need to be forwarded all the way to 153 one of the DC GW devices to perform L3 forwarding (based on end-host 154 IP header). This is generally sub-optimal because because the NVEs 155 associated with these two VMs may reside on the same physical device 156 (either the same server or the same ToR), in which case IP forwarding 157 can be performed locally within that device. Even if the two VMs are 158 located in different PODs within the same DC, and the traffic between 159 the two VMs requires transitioning a core switch, adding a GW for L3 160 switching adds additional hops to the data path. However, if an NVE 161 has IRB capability, then it can perform optimum L2 forwarding for 162 VMs' intra-subnet traffic and optimum L3 forwarding for VMs' inter- 163 subnet traffic, delivering optimum forwarding of unicast and 164 multicast packets at all time. 166 1.2 Shortcomings of L3-Only Solution 167 Consider the scenario where a server is multi-homed to several ToR 168 devices using an Ethernet Link Aggregation Group with LACP [802.1AX] 169 and the VMs are connected to a virtual bridge on the server - i.e., 170 there is an Ethernet bridge on the data path between the VMs and the 171 TORs. The ToRs are acting as NVEs. In this scenario, the LAG spans 172 across multiple PE devices (NVEs) and IGMP joins for the same 173 multicast group can arrives at both PEs. As such, DF election and 174 split-horizon filtering functions are required on the ToRs belonging 175 to the same LAG in order to avoid loops and packet duplication. 176 However, the existing IP-VPN solution does not provide such 177 capabilities that are available in the E-VPN solution. Therefore, 178 these ToR devices cannot be simple L3VPN PEs. 180 Assuming that the above shortcoming is addressed by adding DF 181 election and split-horizon filtering to IP-VPN, several other issues 182 will continue to exist with L3-only solution, particularly when 183 attempting to rely on L3 forwarding for intra-subnet traffic: 185 1. With L3 forwarding, in the absence of a default route, unknown IP 186 destination addresses are dropped. Furthermore, an IP default route 187 directs a particular traffic flow to a single next-hop or outbound 188 interface. This means that L3 forwarding cannot support the 189 forwarding semantics of a subnet broadcast. 191 2. With L3 forwarding, the MAC header is link-local and MAC addresses 192 are swapped on a hop-by-hop basis. This means that if an NVE resorts 193 to L3 forwarding of intra-subnet traffic, then all hosts within the 194 same subnet will receive traffic with the source MAC addresses set to 195 the NVE's address(es) instead of the originating hosts' MAC 196 addresses. As a result, any higher layer application which relies on 197 the source MAC address for identifying the communicating endpoint 198 will break, as it will no longer be able to tell apart the hosts 199 within the subnet based on their MAC addresses. This essentially 200 creates an address aliasing problem. A related issue, that results 201 from the MAC address being rewritten by the NVE, is that the hosts 202 can no longer perform duplicate MAC address detection. 204 3. With L3 forwarding, the IP TTL is decremented with every routed 205 hop. Some applications rely on this fundamental behavior to confine 206 traffic to the originating subnet, by setting the TTL to 1 on 207 transmission. Such applications will no longer work when intra-subnet 208 traffic is L3 forwarded. 210 4. IPv6 link-local addressing and duplicate address detection 211 [RFC4862] assumes and relies upon L2 connectivity within the subnet. 212 These mechanisms will break if the NVE performs L3 intra-subnet 213 forwarding. 215 5. Finally last but not least, there are non-IP applications that 216 require L2 forwarding or there are applications that rely on end host 217 MAC addresses. 219 1.3 Combined L2 & L3 Solution: IRB 221 An IRB solution based on E-VPN can address the shortcomings of L2- 222 only as well as L3-only solutions, and provide optimum forwarding for 223 both inter and intra subnet switching, not only within a DCN but 224 across different DCNs. This E-VPN based solution fits well for DCN 225 overlay and DCI applications, but typical deployments will include 226 IP-VPN PEs that E-VPN PEs need to inter-operate with, such as: 228 1) IP-VPN client sites accessing cloud services 229 2) Communication with IP-VPN ToRs/VSw 230 3) Communication with IP-VPN GWs 232 Therefore, interoperability with IP-VPN PEs is of paramount 233 importance. 235 2 Seamless Interoperability with IP-VPN PEs 237 2.1 Interoperability Use-Cases 239 There are three use-cases that require interoperability between E-VPN 240 and IP-VPN. Those are discussed next. 242 +---+ Enterprise Site 1 243 |PE1|----- H1 244 +---+ 245 / 246 ,---------. Enterprise Site 2 247 ,' `. +---+ 248 ( MPLS/IP )---|PE2|----- H2 249 `. Core ,' +---+ 250 `-+------+' 251 / / \ \ 252 +---+ \ \ 253 ,----|GW |. \ \ 254 ,' +---+ `. ,---------. 255 ( DCN 1 ) ,' `. 256 `. ,' ( DCN2 ) 257 `-+------+' `. ,' 258 __/__ `-+------+' 259 :NVE1 : __/__ __\__ 260 '-----' :NVE2 : :NVE3 : 261 | | '-----' '-----' 262 VM1 VM | | | 263 VM3 VM4 VM5 265 Figure 2: Interoperability Use-Cases 267 2.1.1 IP-VPN Clients Access to Cloud Services 269 An SP offering IP-VPN services to an enterprise may wish to expand 270 its service offering to include Cloud services, while leveraging its 271 existing MPLS/IP infrastructure. The SP may deploy E-VPN on the NVE 272 in order to support L2 connectivity between VMs. The NVE function 273 could be implemented either on ToR switches or on servers. For this 274 scenario, interoperability between the E-VPN NVE and IP-VPN PE is 275 required in order to enable the new service offering. For example., 276 consider Figure 2 where an IP-VPN service is being offered between 277 Enterprise sites 1 and 2. PE1 and PE2 act as IP-VPN PEs. Furthermore, 278 assume that DCN2 employ E-VPN (i.e. NVE2 and NVE3 are E-VPN PEs). For 279 the SP to offer Cloud service, interoperability between the IP-VPN 280 PEs and E-VPN NVEs is required. 282 2.1.2 Communication with IP-VPN NVEs 284 In certain deployments, where only L3 connectivity is required by 285 certain hosts (e.g. VMs), the NVEs associated with those hosts may 286 employ IP-VPN functionality only. An example of this would be running 287 the IP-VPN PE functionality on the hypervisor using the mechanisms of 288 [L3VPN-ENDSYSTEM]. Other VMs may require both L2 as well as L3 289 connectivity. The NVEs associated with those latter VMs would employ 290 E-VPN. In order to allow for inter subnet communication between both 291 categories of VMs (i.e. those which require L3 connectivity only and 292 those requiring both L2 as well as L3 connectivity), interoperability 293 is required between the IP-VPN and the E-VPN NVEs. 295 To illustrate this with an example, consider the network of Figure 2. 296 VM5 requires L3 connectivity only, and subsequently NVE3 employs IP- 297 VPN PE functionality solely. VM3 requires both L2 and L3 298 connectivity, hence, NVE2 is employing E-VPN PE functionality. For 299 VM3 to be able to optimally communicate with VM5, seamless 300 interoperability between IP-VPN and E-VPN is required. 302 2.1.3 Communication with IP-VPN GWs 304 The DCN may be connected to the outside world via IP-VPN GW nodes. 305 These nodes provide Data Center Interconnect and connectivity to 306 Internet and VPN customers. The NVEs, in such scenarios, may have 307 default routes pointing to the GW. When the NVEs need to provide L2 308 as well as L3 connectivity to the associated VMs, they must run E-VPN 309 PE functionality. In order for the IP-VPN GW to learn reachability to 310 the VMs local to the DCN, interoperability is required between E-VPN 311 NVEs and the IP-VPN GW. 313 As an example, consider the network of Figure 2 where the GW of DCN1 314 is an IP-VPN gateway. If NVE1 employs E-VPN PE functionality, then 315 interoperability between E-VPN and IP-VPN is required for 316 connectivity between NVE1 and the GW. 318 2.2 Characteristics of Seamless Interoperability 320 Seamless interoperability between E-VPN and IP-VPN must meet the 321 following characteristics: 323 - Be completely transparent to the operation of the IP-VPN PE. In 324 other words, the IP-VPN PE would not even be aware that it is 325 communicating with an E-VPN endpoint. As such, no upgrade to the IP- 326 VPN nodes is required, not even a software upgrade. 328 - Be optimal from data-plane forwarding perspective. This means that 329 a gateway function is not required in order to normalize the 330 encapsulation to Ethernet in order to support the interoperability. 331 To elaborate on this: it is always possible to have an E-VPN PE 332 interoperate with an IP-VPN PE using a normalized Ethernet L2 hand- 333 off between the two. This however, requires that the MPLS 334 encapsulation be terminated on each PE, with the added overhead of 335 unnecessarily performing MPLS imposition and disposition on both PEs. 336 A side-effect of this gateway approach is that the host MAC addresses 337 will be visible to the E-VPN, and this may create scalability 338 bottlenecks, especially in virtualized data center environments 339 because of sheer number of host MAC addresses. 341 >> get rid off normalizaiton stuff and instead describe what we mean 342 >>> check definition of optimal above and compare it with rekhter-vm- 343 mobility-issues 345 3 An IRB Solution Based on E-VPN 347 An IRB solution based on E-VPN can meet data center network 348 requirements in terms of: 350 >>> qualify that all the following bullets are needed when NVEs are 351 implemented on TORs 353 >>> make it explicit that this section is for NVE on TORs. 355 - Providing optimal forwarding for intra-subnet (L2) traffic. 357 - Providing optimal forwarding for inter-subnet (L3) traffic, by 358 avoiding the need for a centralized L3 GW. This is because the E-VPN 359 MAC Advertisement route can carry an IP address in addition to the 360 MAC address. 362 - Support multicast using ingress replication, in cases where 363 multicast applications are not required or dominant. 365 - Support for optimal multicast delivery through P2MP tunnels, when 366 required, to optimize DCN resources. 368 - Support for multi-homing with active/active redundancy and per-flow 369 load-balancing using multi-chassis LAG. 371 - Support for network-based as well as host-based overlay models. 373 - Support for consistent policy-based forwarding for both L2 and L3 374 forwarded traffic. 376 3.1 E-VPN PE Model for Seamless Interoperability 378 This section describes the PE data-plane model required to achieve 379 seamless interoperability. 381 The E-VPN PE establishes a many-to-one mapping between E-VPN EVIs and 382 an IP-VPN VRF (referred to as just a VRF in the subsequent texts). 383 For a given EVI, it is possible to have multiple associated bridge- 384 domains using the VLAN-aware bundling service interface, as defined 385 in [EVPN-REQ]. Each bridge-domain maps to a unique IP subnet within a 386 VRF context. The following figure depicts the model where there are N 387 VRFs corresponding to N tenants, with each tenant having 2 EVIs and 388 up to M subnets (bridge domains) per EVI. 390 >>>> Either way, distributing the L3 edge to the NVE renders it 391 possible to avoid having an IP-VPN GW for the DCN. 393 Note that this PE model provides flexibility for a wide gamut of 394 deployment options. For example, one end of the spectrum would be 395 with a single EVI per tenant being mapped to a single VRF. Each EVI 396 hosts multiple bridge-domains (one bridge-domain per subnet). This 397 model allows for L2 traffic segregation between different subnets in 398 addition to L3 connectivity among those subnets, as long as global 399 Service VLANs are assigned per tenant (this uses VLAN-aware bundling 400 service in E-VPN). The other end of the spectrum is with multiple 401 EVIs per tenant all mapped to a single VRF. Each EVI hosts a single 402 bridge-domain in this latter case. This model allows for L2 traffic 403 segregation between subnets in addition to L3 connectivity among 404 those subnets without the need for globally assigned Service VLANs 405 (this uses VLAN-based service in E-VPN). 407 +---------------------------------------------+ 408 | | 409 | +-----------+ +-----------+ | 410 | | EVIn |---------| VRF n | | 411 | +------------+ | +------------+ | | 412 | | +-----+ | | | | | | 413 | | | BD1 | | | | | | | 414 | | +-----+ | | | VRF 1 | | | 415 | | .. +-------+ | | | 416 | | +-----+ | | | | | | 417 | | | BDm | | | | | | | 418 | | +-----+ | | | | | | 419 | | EVI 1 |-+ | | | | 420 | +------------+ | | | | 421 | | | | | 422 | +------------+ | | | | 423 | | EVIn*2 | | | | | 424 | +------------+ | | | | | 425 | | +-----+ | |-----| | | | 426 | | |BDm+1| | | | | | | 427 | | +-----+ | | | | | | 428 | | .. +-------+ | | | 429 | | +-----+ | | | | | | 430 | | |BDm*2| | | | | | | 431 | | +-----+ | | | | | | 432 | | EVI 2 |-+ | |--+ | 433 | +------------+ +------------+ | 434 | | 435 | E-VPN PE | 436 +---------------------------------------------+ 438 Figure 3: E-VPN PE Model for Seamless Interoperability with IP-VPN 440 One way to visualize this model is to consider a bridged virtual 441 interface (BVI) to be associated with every bridge-domain in a given 442 EVI. The BVI is an L3 routed interface (hence terminates L2). All the 443 BVIs associated with a given EVI are placed in the same VRF. 445 The IP forwarding table in a given VRF is shared in between E-VPN and 446 IP-VPN. When an E-VPN MAC advertisement route is received by the PE, 447 the MAC address associated with the route is used to populate the 448 bridge-domain MAC table, whereas the IP address associated with the 449 route is used to populate the corresponding VRF. In other words, the 450 VRF table can be populated by both E-VPN as well as IP-VPN BGP 451 routes. For intra-subnet forwarding, the PE consults the bridge- 452 domain MAC table whereas for inter-subnet forwarding the PE performs 453 the lookup in the associated VRF. 455 When an E-VPN packet is received by a PE, it decapsulates the MPLS 456 header and then performs a lookup on the destination MAC address. If 457 the MAC address corresponds to one of its BVI interfaces, the PE 458 deduces that the packet must be inter-subnet routed. Hence, the PE 459 performs an IP lookup in the associated VRF table. However, if the 460 destination MAC address does not correspond to a BVI, then the PE 461 concludes that this packet needs to be intra-subnet switched, and no 462 further IP lookup is needed. 464 3.2 IP-VPN BGP support on E-VPN PEs 466 The E-VPN PE learns host (e.g. VM) MAC addresses via normal bridge 467 learning, and host IP addresses either via snooping of control 468 traffic (e.g. ARP, DHCP..) or gleaning of data traffic. Once the PE 469 learns a new MAC/IP address tuple, it advertises two routes for that 470 tuple: 472 - An E-VPN MAC Advertisement route using the E-VPN AFI/SAFI and 473 associated NLRI, which is used to advertise reachability to other 474 remote E-VPN nodes. The MAC route advertises both the IP and MAC 475 addresses of the host. 477 - An IP-VPN route using IP-VPN AFI/SAFI and associated NLRIs, which 478 is used to advertise reachability to remote IP-VPN speakers. The IP- 479 VPN route advertises only the IP address of the end-station. 481 Given that on the E-VPN PEs there is a one-to-one mapping between an 482 E-VPN Instance (EVI) and a VRF, the same BGP RT and RD are used for 483 both E-VPN and IP-VPN routes. Received E-VPN routes carry both IP and 484 MAC addresses. The MAC addresses are injected into BD tables whereas 485 the IP addresses are injected into VRFs. When an E-VPN speaker 486 receives an IP-VPN route from a remote IP-VPN speaker, it installs 487 the associated IP address in the appropriate VRF. It should be noted 488 that when a MAC address is installed in the EVI, it is only installed 489 in a single BD associated with the subnet corresponding to the 490 Ethernet Tag encoded in the E-VPN MAC route. 492 If, for a given tenant, the IP-VPN PEs only need to share IP-VPN 493 routes for a subset of the subnets with their E-VPN PEs counterparts, 494 then one RT is used as a common RT between IP-VPN and E-VPN PEs for 495 the common subnets and a different one or more RTs are used by the E- 496 VPN PEs for the other tenant subnets that don't need to share routes 497 with the IP-VPN PEs. If further topology constraint is needed among 498 E-VPN and IP-VPN PEs, then instead of a common RT, one can use 499 additional RTs to satisfy the topology constraint. 501 3.3 Handling Multi-Destination Traffic: 503 A key issue is how to handle multi-destination traffic, since E-VPN 504 uses an MPLS label for split-horizon, and the equivalent does not 505 exist in IP-VPN. This can be solved in two different ways, depending 506 on whether the network uses LSM or Ingress Replication: 508 For LSM, two different sets of P2MP multicast trees can be used by 509 the E-VPN PEs. One tree set encompasses only the IP-VPN endpoints 510 whereas the second set includes only the E-VPN speakers. When an E- 511 VPN PE receives a multi-destination frame, it sends a copy on each of 512 the two trees associated with a given EVI/VRF. When the PE sends 513 traffic on the IP-VPN tree, it does not include the split-horizon 514 label since the IP-VPN endpoints do not understand this label. Note 515 that this does not create any adverse side-effects because an E-VPN 516 PE and an IP-VPN will never be combined in the same Redundancy Group 517 (i.e. will never be multi-homed to the same Ethernet Segment), and as 518 such the split-horizon filtering is never required on the IP-VPN PEs. 520 For ingress replication, the E-VPN PE sends the right label stack 521 depending on the capability of the receiving (i.e. egress) PE. When 522 replicating to IP-VPN endpoints, the ingress PE simply does not 523 include any split-horizon labels. 525 3.2.1 Further optimization on RR 527 It is possible to optimize the number of routes that are advertised 528 by a given E-VPN speaker for a specific host address, by leveraging 529 extra intelligence on the BGP route reflector. A future version of 530 this document will describe the detailed procedures to achieve this. 532 5 Acknowledgement 534 6 Security Considerations 536 7 IANA Considerations 538 8 References 540 8.1 Normative References 542 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 543 Requirement Levels", BCP 14, RFC 2119, March 1997. 545 8.2 Informative References 547 [EVPN] Sajassi et al., "BGP MPLS Based Ethernet VPN", draft-ietf- 548 l2vpn-evpn-00.txt, work in progress, February, 2012. 550 [DC-MOBILITY] Aggarwal et al., "Data Center Mobility based on 551 BGP/MPLS, IP Routing and NHRP", draft-raggarwa-data-center-mobility- 552 03.txt, work in progress, June, 2012. 554 Authors' Addresses 556 Ali Sajassi 557 Cisco 558 Email: sajassi@cisco.com 560 Samer Salam 561 Cisco 562 595 Burrard Street 563 Vancouver, BC V7X 1J1, Canada 564 Email: ssalam@cisco.com 566 Keyur Patel 567 Cisco 568 170 West Tasman Drive 569 San Jose, CA 95134, US 570 Email: keyupate@cisco.com 572 Nabil Bitar 573 Verizon Communications 574 Email : nabil.n.bitar@verizon.com 576 Aldrin Isaac 577 Bloomberg 578 aldrin.isaac@gmail.com 580 Wim Henderickx 581 Alcatel-Lucent 582 Email: wim.henderickx@alcatel-lucent.com 584 John E. Drake 585 Juniper Networks 586 Email: jnadeau@juniper.net 587 Yakov Rekhter 588 Juniper Networks 589 Email: yakov@juniper.net