idnits 2.17.1 draft-ietf-l2vpn-evpn-req-07.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 (February 4, 2014) is 3732 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'G.8032' is mentioned on line 350, 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-13 Summary: 0 errors (**), 0 flaws (~~), 4 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: August 4, 2014 February 4, 2014 16 Requirements for Ethernet VPN (EVPN) 17 draft-ietf-l2vpn-evpn-req-07.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) 2014 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Specification of requirements . . . . . . . . . . . . . . . . . 5 74 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 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. Security Considerations . . . . . . . . . . . . . . . . . . . 13 89 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 91 14. Normative References . . . . . . . . . . . . . . . . . . . . . 14 92 14. Informative References . . . . . . . . . . . . . . . . . . . . 15 93 15. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 95 1. Introduction 97 VIrtual Private LAN Service (VPLS), as defined in 98 [RFC4664][RFC4761][RFC4762], is a proven and widely deployed 99 technology. However, the existing solution has a number of 100 limitations when it comes to redundancy, multicast optimization and 101 provisioning simplicity. Furthermore, new applications are driving 102 several new requirements for other L2VPN services such as Ethernet- 103 Tree (E-Tree), and Virtual Private Wire Service (VPWS). 105 In the area of multi-homing current VPLS can only support multi- 106 homing with active/standby resiliency model, for example as described 107 in [VPLS-BGP-MH]. Flexible multi-homing with all-active Attachment 108 Circuits (ACs) cannot be supported by current VPLS solution. 110 In the area of multicast optimization, [VPLS-MCAST] describes how 111 multicast LSPs can be used in conjunction with VPLS. However, this 112 solution is limited to Point-to-Multipoint (P2MP) LSPs, as there's no 113 defined solution for leveraging Multipoint-to-Multipoint (MP2MP) LSPs 114 with VPLS. 116 In the area of provisioning simplicity, current VPLS does offer a 117 mechanism for single-sided provisioning by relying on BGP-based 118 service auto-discovery [RFC4761][RFC6074]. This, however, still 119 requires the operator to configure a number of network-side 120 parameters on top of the access-side Ethernet configuration. 122 In the area of data center interconnect, applications are driving the 123 need for new service interface types which are a hybrid combination 124 of VLAN Bundling and VLAN-based service interfaces. These are 125 referred to as "VLAN-aware Bundling" service interfaces. 127 Virtualization applications are also fueling an increase in the 128 volume of MAC addresses that are to be handled by the network, which 129 gives rise to the requirement for having the network re-convergence 130 upon failure be independent of the number of MAC addresses learned by 131 the PE. 133 There are requirements for minimizing the amount of flooding of 134 multi-destination frames and localizing the flooding to the confines 135 of a given site. 137 There are also requirements for supporting flexible VPN topologies 138 and policies beyond those currently covered by (H-)VPLS. 140 The focus of this document is on defining the requirements for a new 141 solution, namely Ethernet VPN (EVPN), which addresses the above 142 issues. 144 Section 4 discusses the redundancy requirements. Section 5 describes 145 the multicast optimization requirements. Section 6 articulates the 146 ease of provisioning requirements. Section 7 focuses on the new 147 service interface requirements. Section 8 highlights the fast 148 convergence requirements. Section 9 describes the flood suppression 149 requirement, and finally section 10 discusses the requirements for 150 supporting flexible VPN topologies and policies. 152 2. Specification of requirements 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 This document is not a protocol specification and the key words in 159 this document are used for clarity and emphasis of requirements 160 language. 162 3. Terminology 164 AS: Autonomous System 166 CE: Customer Edge 168 E-Tree: Ethernet tree 170 MAC address: Media Access Control address - referred to as MAC 172 LSP: Label Switched Path 174 PE: Provider Edge 176 MP2MP: Multipoint to Multipoint 178 VPLS: Virtual Private LAN Service 180 Single-Active Redundancy Mode: When a device or a network is multi- 181 homed to a group of two or more PEs and when only a single PE in such 182 redundancy group can forward traffic to/from the multi-homed device 183 or network for a given VLAN, then such multi-homing is referred to as 184 "Single-Active". 186 All-Active Redundancy Mode: When a device is multi-homed to a group 187 of two or more PEs and when all PEs in such redundancy group can 188 forward traffic to/from the multi-homed device or network for a given 189 VLAN, then such multi-homing is referred to as "All-Active". 191 4. Redundancy Requirements 193 4.1. Flow-based Load Balancing 195 A common mechanism for multi-homing a CE node to a set of PE nodes 196 involves leveraging multi-chassis Ethernet link aggregation groups 197 based on [802.1AX]. [PWE3-ICCP] describes one such scheme. In 198 Ethernet link aggregation, the load-balancing algorithms by which a 199 CE distributes traffic over the Attachment Circuits connecting to the 200 PEs are quite flexible. The only requirement is for the algorithm to 201 ensure in-order frame delivery for a given traffic flow. In typical 202 implementations, these algorithms involve selecting an outbound link 203 within the bundle based on a hash function that typically identifies 204 a flow based on one or more of the following fields: 206 i. Layer 2: Source MAC Address, Destination MAC Address, VLAN 207 ii. Layer 3: Source IP Address, Destination IP Address 208 iii. Layer 4: UDP or TCP Source Port, Destination Port 210 A key point to note here is that [802.1AX] does not define a standard 211 load-balancing algorithm for Ethernet bundles, and as such different 212 implementations behave differently. As a matter of fact, a bundle 213 operates correctly even in the presence of asymmetric load-balancing 214 over the links. This being the case, the first requirement for all- 215 active multi-homing is the ability to accommodate flexible flow-based 216 load-balancing from the CE node based on L2, L3 and/or L4 header 217 fields. 219 (R1a) A solution MUST be capable of supporting flexible flow-based 220 load balancing from the CE as described above. 222 (R1b) A solution MUST also be able to support flow-based load- 223 balancing of traffic destined to the CE, even when the CE is 224 connected to more than one PE. Thus the solution MUST be able to 225 exercise multiple links connected to the CE, irrespective of the 226 number of PEs that the CE is connected to. 228 It should be noted that when a CE is multi-homed to several PEs, 229 there could be multiple ECMP paths from each remote PE to each multi- 230 homed PE. Furthermore, for all-active multi-homed CE, a remote PE can 231 choose any of the multi-homed PEs for sending traffic destined to the 232 multi-homed CE. Therefore, when a solution supports all-active multi- 233 homing, it MUST exercise as many of these paths as possible for 234 traffic destined to a multi-homed CE. 236 (R1c) A solution SHOULD support flow-based load balancing among PEs 237 that are members of a redundancy group spanning multiple Autonomous 238 Systems. 240 4.2. Flow-based Multi-pathing 242 Any solution that meets the all-active redundancy mode (e.g., flow- 243 based load balancing) described in section 4.1, also needs to 244 exercise multiple paths between a given pair of PEs. For instance, if 245 there are two or more LSPs between a remote PE and a pair of PEs in 246 an all-active redundancy group, then the solution needs to be capable 247 of load balancing traffic among those LSPs on a per L2-flow basis for 248 traffic destined to the PEs in the redundancy group. Furthermore, if 249 there are two or more ECMP paths between a remote PE and one of the 250 PE in the redundancy group, then the solution needs to leverage all 251 the equal cost LSPs. For the latter, the solution can also leverage 252 the load balancing capabilities based on entropy labels [RFC6790]. 254 (R2a) A solution MUST be able to exercise all LSPs between a remote 255 PE and all the PEs in the redundancy group with all-active multi- 256 homing. 258 (R2b) A solution MUST be able to exercise all ECMP paths between a 259 remote PE and any of the PEs in the redundancy group with all-active 260 multi-homing. 262 For example consider a scenario in which CE1 is multi-homed to PE1 263 and PE2, and CE2 is multi-homed to PE3 and PE4 running in all-active 264 redundancy mode. Furthermore, consider that there exist three ECMP 265 paths between any of the CE1's and CE2's multi-homed PEs. Traffic 266 from CE1 to CE2 can be forwarded on twelve different paths over 267 MPLS/IP core as follow: CE1 load balances traffic to both PE1 and 268 PE2. Each of the PE1 and PE2 have three ECMP paths to PE3 and PE4 for 269 the total of twelve paths. Finally, when traffic arrives at PE3 and 270 PE4, it gets forwarded to CE2 over the Ethernet channel (aka link 271 bundle). 273 It is worth pointing out that flow-based multi-pathing complements 274 flow-based load balancing described in the previous section. 276 4.3. Geo-redundant PE Nodes 278 The PE nodes offering multi-homed connectivity to a CE or access 279 network may be situated in the same physical location (co-located), 280 or may be spread geographically (e.g., in different COs or POPs). The 281 latter is needed when offering a geo-redundant solution that ensures 282 business continuity for critical applications in the case of power 283 outages, natural disasters, etc. An all-active multi-homing mechanism 284 needs to support both co-located as well as geo-redundant PE 285 placement. The latter scenario often means that requiring a dedicated 286 link between the PEs, for the operation of the multi-homing 287 mechanism, is not appealing from a cost standpoint. Furthermore, the 288 IGP cost from remote PEs to the pair of PEs in the dual-homed setup 289 cannot be assumed to be the same when those latter PEs are geo- 290 redundant. 292 (R3a) A solution MUST support all-active multi-homing without the 293 need for a dedicated control/data link among the PEs in the multi- 294 homed group. 296 (R3b) A solution MUST support different IGP costs from a remote PE to 297 each of the PEs in a multi-homed group. 299 (R3c) A solution MUST support multi-homing across different IGP 300 domains within the same Autonomous System. 302 (R3d) A solution SHOULD support multi-homing across multiple 303 Autonomous Systems. 305 4.4. Optimal Traffic Forwarding 307 In a typical network, and considering a designated pair of PEs, it is 308 common to find both single-homed as well as multi-homed CEs being 309 connected to those PEs. 311 (R4): An all-active multi-homing solution SHOULD support optimal 312 forwarding of unicast traffic for all the following scenarios. By 313 "optimal forwarding", we mean that traffic will not be forwarded 314 between PE devices that are members of a multi-home group unless the 315 destination CE is attached to one of the multi-homed PEs. 317 i. single-homed CE to multi-homed CE 318 ii. multi-homed CE to single-homed CE 319 iii. multi-homed CE to multi-homed CE 321 This is especially important in the case of geo-redundant PEs, where 322 having traffic forwarded from one PE to another within the same 323 multi-homed group introduces additional latency, on top of the 324 inefficient use of the PE node's and core nodes' switching capacity. 325 A multi-homed group (also known as a multi-chassis LAG) is a group of 326 PEs supporting a multi-homed CE. 328 4.5. Flexible Redundancy Grouping Support 330 (R5) In order to support flexible redundancy grouping, the multi- 331 homing mechanism SHOULD allow arbitrary grouping of PE nodes into 332 redundancy groups where each redundancy group represents all multi- 333 homed devices/networks that share the same group of PEs. 335 This is best explained with an example: consider three PE nodes - 336 PE1, PE2 and PE3. The multi-homing mechanism MUST allow a given PE, 337 say PE1, to be part of multiple redundancy groups concurrently. For 338 example, there can be a group (PE1, PE2), a group (PE1, PE3), and 339 another group (PE2, PE3) where CEs could be multi-homed to any one of 340 these three redundancy groups. 342 4.6. Multi-homed Network 344 There are applications, that require an Ethernet network, rather than 345 a single device, to be multi-homed to a group of PEs. The Ethernet 346 network would typically run a resiliency mechanism such as Multiple 347 Spanning Tree Protocol [802.1Q] or Ethernet Ring Protection Switching 348 [G.8032]. The PEs may or may not participate in the control protocol 349 of the Ethernet network. For a multi-homed network running [802.1Q] 350 or [G.8032], these protocols require that each VLAN to be active only 351 on one of the multi-homed links. 353 (R6a) A solution MUST support multi-homed network connectivity with 354 active/standby redundancy mode where all VLANs are active on one PE. 356 (R6b) A solution MUST also support multi-homed network with single- 357 active redundancy mode where disjoint VLAN sets are active on 358 disparate PEs. 360 (R6c) A solution SHOULD support single-active redundancy mode among 361 PEs that are member of a redundancy group spanning multiple ASes. 363 (R6d) A solution MAY support all-active redundancy mode for a multi- 364 homed network with MAC-based load balancing (i.e. different MAC 365 addresses on a VLAN are reachable via different PEs). 367 5. Multicast Optimization Requirements 369 There are environments where the use of MP2MP LSPs may be desirable 370 for optimizing multicast, broadcast and unknown unicast traffic in 371 order to reduce the amount of multicast states in the core routers. 372 [VPLS-MCAST] precludes the use of MP2MP LSPs since current VPLS 373 solutions require an egress PE to perform learning when it receives 374 unknown unicast packets over a LSP. This is challenging when MP2MP 375 LSPs are used, as MP2MP LSPs do not have inherent mechanisms to 376 identify the sender. The use of MP2MP LSPs for multicast optimization 377 becomes tractable if the need to identify the sender for performing 378 learning is lifted. 380 (R7a) A solution MUST be able to provide a mechanism that does not 381 require MAC learning against MPLS LSPs when packets are received over 382 a MP2MP LSP. 384 (R7b) A solution SHOULD be able to provide procedures to use MP2MP 385 LSPs for optimizing delivery of multicast, broadcast and unknown 386 unicast traffic. 388 6. Ease of Provisioning Requirements 390 As L2VPN technologies expand into enterprise deployments, ease of 391 provisioning becomes paramount. Even though current VPLS has an auto- 392 discovery mechanism, which enables automated discovery of member PEs 393 belonging to a given VPN instance over the MPLS/IP core network, 394 further simplifications are required, as outlined below: 396 (R8a) The solution MUST support auto-discovery of VPN member PEs over 397 MPLS/IP core network similar to VPLS auto-discovery mechanism 398 described in [RFC4761] and [RFC6074]. 400 (R8b) The solution SHOULD support auto-discovery of PEs belonging to 401 a given redundancy or multi-homed group. 403 (R8c) The solution SHOULD support auto-sensing of the site-id for a 404 multi-homed device or network, and support auto-generation of the 405 redundancy group-id based on the site-id. 407 (R8d) The solution SHOULD support automated Designated Forwarder (DF) 408 election among PEs participating in a redundancy (multi-homing) group 409 and to be able to divide service instances (e.g., VLANs) among member 410 PEs of the redundancy group. 412 (R8e) For deployments where VLAN identifiers are global across the 413 MPLS network (i.e. the network is limited to a maximum of 4K 414 services), the PE devices SHOULD derive the MPLS specific attributes 415 (e.g., VPN ID, BGP Route Target, etc.) from the VLAN identifier. This 416 way, it is sufficient for the network operator to configure the VLAN 417 identifier(s) for the access circuit, and all the MPLS and BGP 418 parameters required for setting up the service over the core network 419 would be automatically derived without any need for explicit 420 configuration. 422 (R8f) Implementations SHOULD revert to using default values for 423 parameters that no new values are configured for. 425 7. New Service Interface Requirements 427 [MEF] and [IEEE 802.1Q] have the following services specified: 429 - Port mode: in this mode, all traffic on the port is mapped to a 430 single bridge domain and a single corresponding L2VPN service 431 instance. Customer VLAN transparency is guaranteed end-to-end. 433 - VLAN mode: in this mode, each VLAN on the port is mapped to a 434 unique bridge domain and corresponding L2VPN service instance. This 435 mode allows for service multiplexing over the port and supports 436 optional VLAN translation. 438 - VLAN bundling: in this mode, a group of VLANs on the port are 439 collectively mapped to a unique bridge domain and corresponding L2VPN 440 service instance. Customer MAC addresses must be unique across all 441 VLANs mapped to the same service instance. 443 For each of the above services a single bridge domain is assigned per 444 service instance on the PE supporting the associated service. For 445 example, in case of the port mode, a single bridge domain is assigned 446 for all the ports belonging to that service instance regardless of 447 number of VLANs coming through these ports. 449 It is worth noting that the term 'bridge domain' as used above refers 450 to a MAC forwarding table as defined in the IEEE bridge model, and 451 does not denote or imply any specific implementation. 453 [RFC4762] defines two types of VPLS services based on "unqualified 454 and qualified learning" which in turn maps to port mode and VLAN mode 455 respectively. 457 (R9a) A solution MUST support the above three service types. 459 For hosted data center interconnect applications, network operators 460 require the ability to extend Ethernet VLANs over a WAN using a 461 single L2VPN instance while maintaining data-plane separation between 462 the various VLANs associated with that instance. This is referred to 463 as VLAN-aware bundling service. 465 (R9b) A solution MAY support VLAN-aware bundle service. 467 This gives rise to two new service interface types: VLAN-aware 468 bundling without translation, and VLAN-aware bundling with 469 translation. 471 The VLAN-aware Bundling without Translation service interface has the 472 following characteristics: 474 - The service interface provides bundling of customer VLANs into a 475 single L2VPN service instance. 477 - The service interface guarantees customer VLAN transparency end-to- 478 end. 480 - The service interface maintains data-plane separation between the 481 customer VLANs (i.e. create a dedicated bridge-domain per VLAN). 483 In the special case of all-to-one bundling, the service interface 484 must not assume any a priori knowledge of the customer VLANs. In 485 other words, the customer VLANs shall not be configured on the PE, 486 rather the interface is configured just like a port-based service. 488 The VLAN-aware Bundling with Translation service interface has the 489 following characteristics: 491 - The service interface provides bundling of customer VLANs into a 492 single L2VPN service instance. 494 - The service interface maintains data-plane separation between the 495 customer VLANs (i.e. create a dedicated bridge-domain per VLAN). 497 - The service interface supports customer VLAN translation to handle 498 the scenario where different VLAN Identifiers (VIDs) are used on 499 different interfaces to designate the same customer VLAN. 501 The main difference, in terms of service provider resource 502 allocation, between these new service types and the previously 503 defined three types is that the new services require several bridge 504 domains to be allocated (one per customer VLAN) per L2VPN service 505 instance as opposed to a single bridge domain per L2VPN service 506 instance. 508 8. Fast Convergence 510 (R10a) A solution MUST provide the ability to recover from PE-CE 511 attachment circuit failures as well as PE node failure for the case 512 of both multi-homed device and multi-homed network. 514 (R10b) The recovery mechanism(s) MUST provide convergence time that 515 is independent of the number of MAC addresses learned by the PE. This 516 is particularly important in the context of virtualization 517 applications which are fueling an increase in the number of MAC 518 addresses to be handled by the Layer 2 network. 520 (R10c) Furthermore, the recovery mechanism(s) SHOULD provide 521 convergence time that is independent of the number of service 522 instances associated with the attachment circuit or the PE. 524 9. Flood Suppression 526 (R11a) The solution SHOULD allow the network operator to choose 527 whether unknown unicast frames are to be dropped or to be flooded. 528 This attribute needs to be configurable on a per service instance 529 basis. 531 (R11b) In addition, for the case where the solution is used for data- 532 center interconnect, the solution SHOULD minimize the flooding of 533 broadcast frames outside the confines of a given site. Of particular 534 interest is periodic ARP traffic. 536 (R11c) Furthermore, the solution SHOULD eliminate any unnecessary 537 flooding of unicast traffic upon topology changes, especially in the 538 case of multi-homed site where the PEs have a priori knowledge of the 539 backup paths for a given MAC address. 541 10. Supporting Flexible VPN Topologies and Policies 543 (R12a) A solution MUST be capable of supporting flexible VPN 544 topologies that are not constrained by the underlying mechanisms of 545 the solution. 547 One example of this is E-TREE topology where one or more sites in the 548 VPN are roots and the others are leaves. The roots are allowed to 549 send traffic to other roots and to leaves, while leaves can 550 communicate only with the roots. The solution MUST provide the 551 ability to support E-TREE topology. 553 (R12b) The solution MAY provide the ability to apply policies at the 554 MAC address granularity to control which PEs in the VPN learn which 555 MAC address and how a specific MAC address is forwarded. It should be 556 possible to apply policies to allow only some of the member PEs in 557 the VPN to send or receive traffic for a particular MAC address. 559 (R12c) A solution MUST be capable of supporting both inter-AS option- 560 C and inter-AS option-B scenarios as described in [RFC4364]. 562 11. Security Considerations 564 Any protocol extensions developed for the EVPN solution shall include 565 the appropriate security analysis. Besides the security requirements 566 covered in [RFC4761] and [RFC4762] when MAC learning is performed in 567 data-plane and in [RFC4364] when MAC learning is performed in control 568 plane, the following additional requirements need to be covered. 570 (R13) A solution MUST be capable of detecting and properly handling a 571 situation where the same MAC address appears behind two different 572 Ethernet Segment (whether inadvertently or maliciously). 574 (R14) A solution MUST be capable of associating a MAC address to a 575 specific Ethernet Segment (sticky MAC) in order to help limit 576 malicious traffic into a network for that MAC address. This 577 capability can limit the appearance of spoofed MAC address on a 578 network. When this feature is enabled, the MAC mobility for such 579 sticky MAC addresses are disallowed and the traffic for such MAC 580 addresses from any other Ethernet Segment MUST be discarded. 582 12. Contributors 584 Samer Salam, Cisco, ssalam@cisco.com 585 John Drake, Juniper, jdrake@juniper.net 586 Clarence Filsfils, Cisco, cfilsfil@cisco.com 588 13. IANA Considerations 590 None. 592 14. Normative References 593 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", 594 August 1996. 596 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 597 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 598 4761, January 2007. 600 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 601 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 602 RFC 4762, January 2007. 604 [RFC4364] "BGP/MPLS IP Virtual Private Networks (VPNs)", February 605 2006. 607 [802.1AX] IEEE Std. 802.1AX-2008, "IEEE Standard for Local and 608 metropolitan area networks - Link Aggregation", IEEE 609 Computer Society, November 2008. 611 [802.1Q] IEEE Std. 802.1Q-2011, "IEEE Standard for Local and 612 metropolitan area networks - Virtual Bridged Local Area 613 Networks", 2011. 615 [RFC6074] E. Rosen and B. Davie, "Provisioning, Auto-Discovery, and 616 Signaling in Layer 2 Virtual Private Networks (L2VPNs)", 617 January 2011. 619 14. Informative References 620 [RFC4664] "Framework for Layer 2 Virtual Private Networks (L2VPNs)", 621 September 2006. 623 [VPLS-BGP-MH] Kothari et al., "BGP based Multi-homing in Virtual 624 Private LAN Service", draft-ietf-l2vpn-vpls-multihoming- 625 06, work in progress, February, 2013. 627 [PWE3-ICCP] Martini et al., "Inter-Chassis Communication Protocol for 628 L2VPN PE Redundancy", draft-ietf-pwe3-iccp-13.txt, work in 629 progress, January, 2014. 631 [VPLS-MCAST] R. Aggarwal, et al., "Multicast in VPLS", draft-ietf- 632 l2vpn-vpls-mcast-16.txt, work in progress, July 2013. 634 [MEF] MEF 6.1 Technical Specification, "Ethernet Service 635 Definitions", April 2008. 637 [RFC6790] K. Kompella et al., "The Use of Entropy Labels in MPLS 638 Forwarding", RFC 6790, November 2012. 640 15. Author's Address 642 Ali Sajassi 643 Cisco 644 Email: sajassi@cisco.com 646 Rahul Aggarwal 647 Arktan 648 Email: raggarwa_1@yahoo.com 650 Wim Henderickx 651 Alcatel-Lucent 652 Email: wim.henderickx@alcatel-lucent.com 654 Aldrin Isaac 655 Bloomberg 656 Email: aisaac71@bloomberg.net 657 James Uttaro 658 AT&T 659 Email: uttaro@att.com 661 Nabil Bitar 662 Verizon Communications 663 Email : nabil.n.bitar@verizon.com