idnits 2.17.1 draft-ietf-l2vpn-evpn-req-05.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 15, 2013) is 3845 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'G.8032' is mentioned on line 339, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-l2vpn-vpls-multihoming-06 == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-iccp-11 == Outdated reference: A later version (-16) exists of draft-ietf-l2vpn-vpls-mcast-15 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Working Group A. Sajassi 3 INTERNET-DRAFT Cisco 4 Category: Informational 5 R. Aggarwal 6 J. Uttaro Arktan 7 AT&T 8 N. Bitar 9 W. Henderickx Verizon 10 Alcatel-Lucent 11 Aldrin Isaac 12 Bloomberg 14 Expires: April 15, 2014 October 15, 2013 16 Requirements for Ethernet VPN (EVPN) 17 draft-ietf-l2vpn-evpn-req-05.txt 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright and License Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Abstract 57 The widespread adoption of Ethernet L2VPN services and the advent of 58 new applications for the technology (e.g., data center interconnect) 59 have culminated in a new set of requirements that are not readily 60 addressable by the current Virtual Private LAN Service (VPLS) 61 solution. In particular, multi-homing with all-active forwarding is 62 not supported and there's no existing solution to leverage 63 Multipoint-to-Multipoint (MP2MP) LSPs for optimizing the delivery of 64 multi-destination frames. Furthermore, the provisioning of VPLS, even 65 in the context of BGP-based auto-discovery, requires network 66 operators to specify various network parameters on top of the access 67 configuration. This document specifies the requirements for an 68 Ethernet VPN (EVPN) solution which addresses the above issues. 70 Table of Contents 72 1. Specification of requirements . . . . . . . . . . . . . . . . . 4 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 4. Redundancy Requirements . . . . . . . . . . . . . . . . . . . . 6 76 4.1. Flow-based Load Balancing . . . . . . . . . . . . . . . . 6 77 4.2. Flow-based Multi-pathing . . . . . . . . . . . . . . . . . 7 78 4.3. Geo-redundant PE Nodes . . . . . . . . . . . . . . . . . . 7 79 4.4. Optimal Traffic Forwarding . . . . . . . . . . . . . . . . 8 80 4.5. Flexible Redundancy Grouping Support . . . . . . . . . . . 8 81 4.6. Multi-homed Network . . . . . . . . . . . . . . . . . . . 9 82 5. Multicast Optimization Requirements . . . . . . . . . . . . . . 9 83 6. Ease of Provisioning Requirements . . . . . . . . . . . . . . . 10 84 7. New Service Interface Requirements . . . . . . . . . . . . . . 10 85 8. Fast Convergence . . . . . . . . . . . . . . . . . . . . . . . 12 86 9. Flood Suppression . . . . . . . . . . . . . . . . . . . . . . . 13 87 10. Supporting Flexible VPN Topologies and Policies . . . . . . . 13 88 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 90 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 91 14. Normative References . . . . . . . . . . . . . . . . . . . . . 14 92 14. Informative References . . . . . . . . . . . . . . . . . . . . 14 93 15. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 95 1. Specification of requirements 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 2. Terminology 103 AS: Autonomous System 105 CE: Customer Edge 107 E-Tree: Ethernet tree 109 MAC address: Media Access Control address - referred to as MAC 111 LSP: Label Switched Path 113 PE: Provider Edge 115 MP2MP: Multipoint to Multipoint 117 VPLS: Virtual Private LAN Service 119 Single-Active Mode: When a device or a network is multi-homed to two 120 or more PEs and when only a single PE in such redundancy group can 121 forward traffic to/from the multi-homed device or network for a given 122 VLAN, then such multi-homing or redundancy is referred to as "Single- 123 Active". 125 All-Active: When a device is multi-homed to two or more PEs and when 126 all PEs in such redundancy group can forward traffic to/from the 127 multi-homed device for a given VLAN, then such multi-homing or 128 redundancy is referred to as "All-Active". 130 3. Introduction 132 VPLS, as defined in [RFC4664][RFC4761][RFC4762], is a proven and 133 widely deployed technology. However, the existing solution has a 134 number of limitations when it comes to redundancy, multicast 135 optimization and provisioning simplicity. Furthermore, new 136 applications are driving several new requirements for other L2VPN 137 services such as E-TREE, and VPWS. 139 In the area of multi-homing current VPLS can only support multi- 140 homing with active/standby resiliency model, for example as described 141 in [VPLS-BGP-MH]. Flexible multi-homing with all-active Attachment 142 Circuits (ACs) cannot be supported by current VPLS solution. 144 In the area of multicast optimization, [VPLS-MCAST] describes how 145 multicast LSPs can be used in conjunction with VPLS. However, this 146 solution is limited to Point-to-Multipoint (P2MP) LSPs, as there's no 147 defined solution for leveraging Multipoint-to-Multipoint (MP2MP) LSPs 148 with VPLS. 150 In the area of provisioning simplicity, current VPLS does offer a 151 mechanism for single-sided provisioning by relying on BGP-based 152 service auto-discovery [RFC4761][RFC6074]. This, however, still 153 requires the operator to configure a number of network-side 154 parameters on top of the access-side Ethernet configuration. 156 Furthermore, data center interconnect applications are driving the 157 need for new service interface types which are a hybrid combination 158 of VLAN Bundling and VLAN-based service interfaces. These are 159 referred to as "VLAN-aware Bundling" service interfaces. 161 Also virtualization applications are fueling an increase in the 162 volume of MAC addresses that are to be handled by the network, which 163 gives rise to the requirement for having the network re-convergence 164 upon failure be independent of the number of MAC addresses learned by 165 the PE. 167 In addition, there are requirements for minimizing the amount of 168 flooding of multi-destination frames and localizing the flooding to 169 the confines of a given site. 171 Moreover, there are requirements for supporting flexible VPN 172 topologies and policies beyond those currently covered by (H-)VPLS. 174 The focus of this document is on defining the requirements for a new 175 solution, namely Ethernet VPN (EVPN), which addresses the above 176 issues. 178 Section 4 discusses the redundancy requirements. Section 5 describes 179 the multicast optimization requirements. Section 6 articulates the 180 ease of provisioning requirements. Section 7 focuses on the new 181 service interface requirements. Section 8 highlights the fast 182 convergence requirements. Section 9 describes the flood suppression 183 requirement, and finally section 10 discusses the requirements for 184 supporting flexible VPN topologies and policies. 186 4. Redundancy Requirements 188 4.1. Flow-based Load Balancing 190 A common mechanism for multi-homing a CE node to a set of PE nodes 191 involves leveraging multi-chassis Ethernet link aggregation groups 192 based on [802.1AX]. [PWE3-ICCP] describes one such scheme. In 193 Ethernet link aggregation, the load-balancing algorithms by which a 194 CE distributes traffic over the Attachment Circuits connecting to the 195 PEs are quite flexible. The only requirement is for the algorithm to 196 ensure in-order frame delivery for a given traffic flow. In typical 197 implementations, these algorithms involve selecting an outbound link 198 within the bundle based on a hash function that identifies a flow 199 based on one or more of the following fields: 201 i. Layer 2: Source MAC Address, Destination MAC Address, VLAN 202 ii. Layer 3: Source IP Address, Destination IP Address 203 iii. Layer 4: UDP or TCP Source Port, Destination Port 205 A key point to note here is that [802.1AX] does not define a standard 206 load-balancing algorithm for Ethernet bundles, and as such different 207 implementations behave differently. As a matter of fact, a bundle 208 operates correctly even in the presence of asymmetric load-balancing 209 over the links. This being the case, the first requirement for all- 210 active multi-homing is the ability to accommodate flexible flow-based 211 load-balancing from the CE node based on L2, L3 and/or L4 header 212 fields. 214 (R1a) A solution MUST be capable of supporting flexible flow-based 215 load balancing from the CE as described above. 217 (R1b) A solution MUST also be able to support flow-based load- 218 balancing of traffic destined to the CE, even when the CE is 219 connected to more than one PE. Thus the solution MUST be able to 220 exercise multiple links connected to the CE, irrespective of the 221 number of PEs that the CE is connected to. 223 It should be noted that when a CE is multi-homed to several PEs, 224 there could be multiple ECMP paths from each remote PE to each multi- 225 homed PE. Furthermore, for all-active multi-homed CE, a remote PE can 226 choose any of the multi-homed PEs for sending traffic destined to the 227 multi-homed CE. Therefore, when a solution supports all-active multi- 228 homing, it MUST exercise as many of these paths as possible for 229 traffic destined to a multi-homed CE. 231 (R1c) A solution MAY support flow-based load balancing among PEs that 232 are members of a redundancy group spanning multiple Autonomous 233 Systems. 235 4.2. Flow-based Multi-pathing 237 Any solution that meets the all-active flow based load balancing 238 requirement described in section 4.1 MUST also be able to exercise 239 multiple paths between a given pair of PEs. For instance, if there 240 are multiple RSVP-TE LSPs between a pair of PEs then the solution 241 MUST be capable of load balancing traffic among those LSPs on a per 242 flow basis. Similarly, if LDP is being used as the signaling protocol 243 for transport LSPs, then the solution MUST be able to leverage LDP 244 signaled equal cost LSPs. The solution MUST also be able to leverage 245 work in the MPLS WG that is in progress to improve the load balancing 246 capabilities of the network based on entropy labels [RFC6790]. 248 (R2) A solution MUST be able to exercise as many ECMP paths as 249 possible between any pair of PEs in conjunction with the all-active 250 load-balancing described above. 252 For example consider a scenario in which CE1 is multi-homed to PE1 253 and PE2, and CE2 is multi-homed to PE3 and PE4 running in all-active 254 mode. Furthermore, consider that there exist three ECMPs between any 255 of the CE1's and CE2's multi-homed PEs. Traffic from CE1 to CE2 can 256 be forwarded on twelve different paths over MPLS/IP core as follow: 257 CE1 load balances traffic to both PE1 and PE2. Each of the PE1 and 258 PE2 have three ECMPs to PE3 and PE4 for the total of twelve paths. 259 Finally, when traffic arrives at PE3 and PE4, it gets forwarded to 260 CE2 over the Ethernet channel (aka link bundle). 262 It is worth pointing out that flow-based multi-pathing complements 263 flow-based load balancing described in the previous section. 265 4.3. Geo-redundant PE Nodes 267 The PE nodes offering multi-homed connectivity to a CE or access 268 network may be situated in the same physical location (co-located), 269 or may be spread geographically (e.g., in different COs or POPs). The 270 latter is desirable when offering a geo-redundant solution that 271 ensures business continuity for critical applications in the case of 272 power outages, natural disasters, etc. An all-active multi-homing 273 mechanism SHOULD support both co-located as well as geo-redundant PE 274 placement. The latter scenario often means that requiring a dedicated 275 link between the PEs, for the operation of the multi-homing 276 mechanism, is not appealing from a cost standpoint. Furthermore, the 277 IGP cost from remote PEs to the pair of PEs in the dual-homed setup 278 cannot be assumed to be the same when those latter PEs are geo- 279 redundant. 281 (R3a) A solution MUST support all-active multi-homing without the 282 need for a dedicated control/data link among the PEs in the multi- 283 homed group. 285 (R3b) A solution MUST NOT assume that the IGP cost from a remote PE 286 to each of the PEs in the multi-homed group is the same. 288 (R3c) A solution MUST support multi-homing across different IGP 289 domains within the same Autonomous System. 291 (R3d) A solution SHOULD support multi-homing across multiple 292 Autonomous Systems. 294 4.4. Optimal Traffic Forwarding 296 In a typical network, and considering a designated pair of PEs, it is 297 common to find both single-homed as well as multi-homed CEs being 298 connected to those PEs. 300 R4: An all-active multi-homing solution SHOULD support optimal 301 forwarding of unicast traffic for all the following scenarios. By 302 "optimal forwarding", we mean that traffic will not be forwarded 303 between PE devices that are members of a multi-home group unless the 304 destination CE is attached to one of the multi-homed PEs. 306 i. single-homed CE to multi-homed CE 307 ii. multi-homed CE to single-homed CE 308 iii. multi-homed CE to multi-homed CE 310 This is especially important in the case of geo-redundant PEs, where 311 having traffic forwarded from one PE to another within the same 312 multi-homed group introduces additional latency, on top of the 313 inefficient use of the PE node's and core nodes' switching capacity. 314 A multi-homed group (also known as a multi-chassis LAG) is a group of 315 PEs supporting a multi-homed CE. 317 4.5. Flexible Redundancy Grouping Support 319 (R5) In order to simplify service provisioning and activation, the 320 multi-homing mechanism SHOULD allow arbitrary grouping of PE nodes 321 into redundancy groups where each redundancy group represents all 322 multi-homed groups that share the same group of PEs. 324 This is best explained with an example: consider three PE nodes - 325 PE1, PE2 and PE3. The multi-homing mechanism MUST allow a given PE, 326 say PE1, to be part of multiple redundancy groups concurrently. For 327 example, there can be a group (PE1, PE2), a group (PE1, PE3), and 328 another group (PE2, PE3) where CEs could be multi-homed to any one of 329 these three redundancy groups. 331 4.6. Multi-homed Network 333 There are applications, which require an Ethernet network, rather 334 than a single device, to be multi-homed to a group of PEs. The 335 Ethernet network would typically run a resiliency mechanism such as 336 Multiple Spanning Tree Protocol [802.1Q] or Ethernet Ring Protection 337 Switching [G.8032]. The PEs may or may not participate in the control 338 protocol of the Ethernet network. For a multi-homed network running 339 [802.1Q] or [G.8032], these protocols require that each VLAN to be 340 active only on one of the multi-homed links. 342 (R6a) A solution MUST support multi-homed network connectivity with 343 active/standby redundancy. 345 (R6b) A solution MUST also support multi-homed network with all- 346 active VLAN-based load balancing (i.e. disjoint VLAN sets active on 347 disparate PEs). 349 (R6c) A solution MAY support VLAN-based load balancing among PEs that 350 are member of a redundancy group spanning multiple ASes. 352 (R6d) A solution MAY support multi-homed network with all-active MAC- 353 based load balancing (i.e. different MAC addresses on a VLAN are 354 reachable via different PEs). 356 5. Multicast Optimization Requirements 358 There are environments where the usage of MP2MP LSPs may be desirable 359 for optimizing multicast, broadcast and unknown unicast traffic in 360 order to reduce the amount of multicast states in the core routers. 361 [VPLS-MCAST] precludes the usage of MP2MP LSPs since current VPLS 362 solutions require an egress PE to perform learning when it receives 363 unknown unicast packets over a LSP. This is challenging when MP2MP 364 LSPs are used, as MP2MP LSPs do not have inherent mechanisms to 365 identify the sender. The usage of MP2MP LSPs for multicast 366 optimization becomes tractable if the need to identify the sender for 367 performing learning is lifted. 369 (R7a) A solution MUST be able to provide a mechanism that does not 370 require MAC learning against MPLS LSPs when packets are received over 371 a MP2MP LSP. 373 (R7b) A solution SHOULD be able to provide procedures to use MP2MP 374 LSPs for optimizing delivery of multicast, broadcast and unknown 375 unicast traffic. 377 6. Ease of Provisioning Requirements 379 As L2VPN technologies expand into enterprise deployments, ease of 380 provisioning becomes paramount. Even though current VPLS has an auto- 381 discovery mechanism, which enables automated discovery of member PEs 382 belonging to a given VPN instance over the MPLS/IP core network, 383 further simplifications are required, as outlined below: 385 (R8a) The solution MUST support auto-discovery of VPN member PEs over 386 MPLS/IP core network similar to VPLS auto-discovery mechanism 387 described in [RFC4761] and [RFC6074]. 389 (R8b) The solution SHOULD support auto-discovery of PEs belonging to 390 a given redundancy or multi-homed group. 392 (R8c) The solution SHOULD support auto-sensing of the site-id for a 393 multi-homed device or network, and support auto-generation of the 394 redundancy group-id based on the site-id. 396 (R8d) The solution SHOULD support automated Designated Forwarder (DF) 397 election among PEs participating in a redundancy (multi-homing) group 398 and to be able to divide service instances (e.g., VLANs) among member 399 PEs of the redundancy group. 401 (R8e) For deployments where VLAN identifiers are global across the 402 MPLS network (i.e. the network is limited to a maximum of 4K 403 services), the PE devices SHOULD derive the MPLS specific attributes 404 (e.g., VPN ID, BGP Route Target, etc.) from the VLAN identifier. This 405 way, it is sufficient for the network operator to configure the VLAN 406 identifier(s) for the access circuit, and all the MPLS and BGP 407 parameters required for setting up the service over the core network 408 would be automatically derived without any need for explicit 409 configuration. 411 Implementations SHOULD revert to using default values for parameters 412 as and where applicable. 414 7. New Service Interface Requirements 416 [MEF] and [IEEE 802.1Q] have the following services specified: 418 - Port mode: in this mode, all traffic on the port is mapped to a 419 single bridge domain and a single corresponding L2VPN service 420 instance. Customer VLAN transparency is guaranteed end-to-end. 422 - VLAN mode: in this mode, each VLAN on the port is mapped to a 423 unique bridge domain and corresponding L2VPN service instance. This 424 mode allows for service multiplexing over the port and supports 425 optional VLAN translation. 427 - VLAN bundling: in this mode, a group of VLANs on the port are 428 collectively mapped to a unique bridge domain and corresponding L2VPN 429 service instance. Customer MAC addresses must be unique across all 430 VLANs mapped to the same service instance. 432 For each of the above services a single bridge domain is assigned per 433 service instance on the PE supporting the associated service. For 434 example, in case of the port mode, a single bridge domain is assigned 435 for all the ports belonging to that service instance regardless of 436 number of VLANs coming through these ports. 438 It is worth noting that the term 'bridge domain' as used above refers 439 to a MAC forwarding table as defined in the IEEE bridge model, and 440 does not denote or imply any specific implementation. 442 [RFC4762] defines two types of VPLS services based on "unqualified 443 and qualified learning" which in turn maps to port mode and VLAN mode 444 respectively. 446 A solution is required to support the above three service types plus 447 two additional service types which are primarily intended for hosted 448 data center applications and are described below. 450 For hosted data center interconnect applications, network operators 451 require the ability to extend Ethernet VLANs over a WAN using a 452 single L2VPN instance while maintaining data-plane separation between 453 the various VLANs associated with that instance. This is referred to 454 as VLAN-aware bundling service. 456 (R9) A solution MAY support VLAN-aware bundle service. 458 This gives rise to two new service interface types: VLAN-aware 459 bundling without translation, and VLAN-aware bundling with 460 translation. 462 The VLAN-aware Bundling without Translation service interface has the 463 following characteristics: 465 - The service interface MUST provide bundling of customer VLANs into 466 a single L2VPN service instance. 468 - The service interface MUST guarantee customer VLAN transparency 469 end-to-end. 471 - The service interface MUST maintain data-plane separation between 472 the customer VLANs (i.e. create a dedicated bridge-domain per VLAN). 474 In the special case of all-to-one bundling, the service interface 475 MUST NOT assume any a priori knowledge of the customer VLANs. In 476 other words, the customer VLANs shall not be configured on the PE, 477 rather the interface is configured just like a port-based service. 479 The VLAN-aware Bundling with Translation service interface has the 480 following characteristics: 482 - The service interface MUST provide bundling of customer VLANs into 483 a single L2VPN service instance. 485 - The service interface MUST maintain data-plane separation between 486 the customer VLANs (i.e. create a dedicated bridge-domain per VLAN). 488 The service interface MUST support customer VLAN translation to 489 handle the scenario where different VLAN Identifiers (VIDs) are used 490 on different interfaces to designate the same customer VLAN. 492 The main difference, in terms of service provider resource 493 allocation, between these new service types and the previously 494 defined three types is that the new services require several bridge 495 domains to be allocated (one per customer VLAN) per L2VPN service 496 instance as opposed to a single bridge domain per L2VPN service 497 instance. 499 8. Fast Convergence 501 (R10a) A solution MUST provide the ability to recover from PE-CE 502 attachment circuit failures as well as PE node failure for the case 503 of both multi-homed device and multi-homed network. 505 (R10b) The recovery mechanism(s) MUST provide convergence time that 506 is independent of the number of MAC addresses learned by the PE. This 507 is particularly important in the context of virtualization 508 applications which are fueling an increase in the number of MAC 509 addresses to be handled by the Layer 2 network. 511 (R10c) Furthermore, the recovery mechanism(s) SHOULD provide 512 convergence time that is independent of the number of service 513 instances associated with the attachment circuit or the PE. 515 9. Flood Suppression 517 (R11) The solution SHOULD allow the network operator to choose 518 whether unknown unicast frames are to be dropped or to be flooded. 519 This attribute needs to be configurable on a per service instance 520 basis. 522 In addition, for the case where the solution is used for data-center 523 interconnect, it is required to minimize the flooding of broadcast 524 frames outside the confines of a given site. Of particular interest 525 is periodic ARP traffic. 527 Furthermore, it is required to eliminate any unnecessary flooding of 528 unicast traffic upon topology changes, especially in the case of 529 multi-homed site where the PEs have a priori knowledge of the backup 530 paths for a given MAC address. 532 10. Supporting Flexible VPN Topologies and Policies 534 (R12) A solution MUST be capable of supporting flexible VPN 535 topologies that are not constrained by the underlying mechanisms of 536 the solution. 538 One example of this is E-TREE topology where one or more sites in the 539 VPN are roots and the others are leaves. The roots are allowed to 540 send traffic to other roots and to leaves, while leaves can 541 communicate only with the roots. The solution MUST provide the 542 ability to support E-TREE topology. 544 (R12b) The solution MAY provide the ability to apply policies at the 545 MAC address granularity to control which PEs in the VPN learn which 546 MAC address and how a specific MAC address is forwarded. It should be 547 possible to apply policies to allow only some of the member PEs in 548 the VPN to send or receive traffic for a particular MAC address. 550 (R12c) A solution MUST be capable of supporting both inter-AS option- 551 C and inter-AS option-B scenarios as described in [RFC4364]. 553 11. Contributors 555 Samer Salam, Cisco, ssalam@cisco.com 556 John Drake, Juniper, jdrake@juniper.net 557 Clarence Filsfils, Cisco, cfilsfil@cisco.com 559 12. Security Considerations 561 Any protocol extensions developed for the EVPN solution shall include 562 the appropriate security analysis. The requirement is to introduce no 563 new vulnerabilities beyond those of [RFC4761] and [RFC4762] when MAC 564 learning is performed in data-plane and beyond that of [RFC4364] when 565 MAC learning is performed in control plane. 567 13. IANA Considerations 569 None. 571 14. Normative References 572 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", 573 August 1996. 575 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 576 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 577 4761, January 2007. 579 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 580 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 581 RFC 4762, January 2007. 583 [RFC4364] "BGP/MPLS IP Virtual Private Networks (VPNs)", February 584 2006. 586 [802.1AX] IEEE Std. 802.1AX-2008, "IEEE Standard for Local and 587 metropolitan area networks - Link Aggregation", IEEE 588 Computer Society, November 2008. 590 [802.1Q] IEEE Std. 802.1Q-2011, "IEEE Standard for Local and 591 metropolitan area networks - Virtual Bridged Local Area 592 Networks", 2011. 594 [RFC6074] E. Rosen and B. Davie, "Provisioning, Auto-Discovery, and 595 Signaling in Layer 2 Virtual Private Networks (L2VPNs)", 596 January 2011. 598 14. Informative References 599 [RFC4664] "Framework for Layer 2 Virtual Private Networks (L2VPNs)", 600 September 2006. 602 [VPLS-BGP-MH] Kothari et al., "BGP based Multi-homing in Virtual 603 Private LAN Service", draft-ietf-l2vpn-vpls-multihoming- 604 06, work in progress, February, 2013. 606 [PWE3-ICCP] Martini et al., "Inter-Chassis Communication Protocol for 607 L2VPN PE Redundancy", draft-ietf-pwe3-iccp-11.txt, work in 608 progress, February, 2013. 610 [VPLS-MCAST] R. Aggarwal, et al., "Multicast in VPLS", draft-ietf- 611 l2vpn-vpls-mcast-15.txt, work in progress, July 2013. 613 [MEF] MEF 6.1 Technical Specification, "Ethernet Service 614 Definitions", April 2008. 616 [RFC6790] K. Kompella et al., "The Use of Entropy Labels in MPLS 617 Forwarding", RFC 6790, November 2012. 619 15. Author's Address 621 Ali Sajassi 622 Cisco 623 Email: sajassi@cisco.com 625 Rahul Aggarwal 626 Arktan 627 Email: raggarwa_1@yahoo.com 629 Wim Henderickx 630 Alcatel-Lucent 631 Email: wim.henderickx@alcatel-lucent.com 633 Aldrin Isaac 634 Bloomberg 635 Email: aisaac71@bloomberg.net 637 James Uttaro 638 AT&T 639 Email: uttaro@att.com 641 Nabil Bitar 642 Verizon Communications 643 Email : nabil.n.bitar@verizon.com