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