idnits 2.17.1 draft-ietf-l2vpn-etree-reqt-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 (July 29, 2013) is 3917 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Raymond Key (editor), Huawei 3 Internet Draft Simon Delord, Telstra 4 Category: Informational Frederic Jounay, Orange CH 5 Expires: January 2014 Lu Huang, China Mobile 6 Zhihua Liu, China Telecom 7 Manuel Paul, Deutsche Telekom 9 July 29, 2013 11 Requirements for Metro Ethernet Forum (MEF) 12 Ethernet-Tree (E-Tree) Support in L2VPN 13 draft-ietf-l2vpn-etree-reqt-05 15 Abstract 17 This document provides functional requirements for Metro Ethernet 18 Forum (MEF) Ethernet Tree (E-Tree) support in multipoint L2VPN 19 solutions (referred to as simply L2VPN). It is intended that 20 potential solutions will use these requirements as guidelines. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on January 29, 2014. 45 Table of Contents 47 1. Introduction....................................................3 48 2. IETF Multipoint Ethernet L2VPN Services.........................3 49 2.1. VPLS..........................................................3 50 2.2. E-VPN.........................................................3 51 3. MEF Multipoint Ethernet Services................................3 52 3.1. Similarity between E-LAN and E-Tree...........................4 53 3.2. Difference between E-LAN and E-Tree...........................4 54 3.3. E-Tree Use Cases..............................................5 55 3.4. Generic E-Tree Service........................................6 56 4. Problem Statement...............................................6 57 4.1. Motivation....................................................6 58 4.2. Leaf-to-Leaf Communication Restriction........................6 59 5. Requirements....................................................7 60 5.1. Functional Requirements.......................................7 61 5.2. Applicability.................................................7 62 5.3. Backward Compatibility........................................8 63 5.4. External Network Network Interface............................8 64 6. Security Consideration..........................................8 65 7. IANA Considerations.............................................8 66 8. Contributors....................................................8 67 9. Acknowledgements................................................8 68 10. References.....................................................8 69 10.1. Normative References.........................................8 70 10.2. Informative References.......................................9 71 Appendix 72 A. Frequently Asked Questions.....................................10 73 A.1. Are E-Tree requirements addressed in the Virtual 74 Private Multicast Service (VPMS) requirements?...............10 75 Authors' Addresses................................................11 76 Contributors' Addresses...........................................12 77 Intellectual Property and Copyright Statements....................12 79 Conventions used in this document 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 1. Introduction 87 This document provides functional requirements for Metro Ethernet 88 Forum (MEF) Ethernet Tree (E-Tree) support in multipoint L2VPN 89 solutions (referred to as simply L2VPN). It is intended that 90 potential solutions will use these requirements as guidelines. 92 Considerable number of service providers have adopted Virtual Private 93 LAN Service (VPLS) to provide MEF Ethernet LAN (E-LAN) services to 94 customers. Service Providers currently need a simple and effective 95 solution to emulate E-Tree services in addition to E-LAN services on 96 their MPLS networks. 98 Service providers also expect E-Tree support in any newly developed 99 L2VPN technologies. 101 2. IETF Multipoint Ethernet L2VPN Services 103 2.1. VPLS 105 VPLS [RFC4761] [RFC4762] is a L2VPN service that provides multipoint- 106 to-multipoint connectivity for Ethernet across an IP or MPLS-enabled 107 IP Packet Switched Network (IP/MPLS PSN). VPLS emulates the Ethernet 108 Virtual Local Area Network (VLAN) functionality of traditional 109 Ethernet networks. Thus, in VPLS, the customer Ethernet frame is 110 transported over the IP/MPLS PSN from the ingress Provider Edge (PE) 111 to the egress PE where the destination is connected based on the 112 Ethernet frame destination MAC address in the context of the virtual 113 switching instance (VSI) to which it belongs. 115 2.2. Ethernet Virtual Private Network (E-VPN) 117 E-VPN is an enhanced Layer-2 service that emulates an Ethernet VLAN 118 across an IP/MPLS PSN, primarily targeted to support large scale 119 L2VPNs with resiliency requirements not satisfied by other L2VPN 120 solutions. 122 E-VPN is currently under development. Please refer to [Draft EVPN 123 Req]. 125 3. MEF Multipoint Ethernet Services 127 MEF has defined two multipoint Ethernet Service types: 128 - E-LAN (Ethernet LAN), multipoint-to-multipoint service 129 - E-Tree (Ethernet Tree), rooted-multipoint service 131 For full specification, please refer to [MEF6.1] [MEF10.2]. 133 3.1. Similarities between E-LAN and E-Tree 135 Following are the similarities between E-LAN and E-Tree services. 136 - Data frame is an Ethernet frame. 137 - Data forwarding is MAC-based forwarding. 138 - A generic E-LAN/E-Tree service is always bidirectional in the 139 sense that ingress frames can originate at any endpoint in the 140 service. 142 3.2. Differences between E-LAN and E-Tree 144 Within the context of a multipoint Ethernet service, each endpoint is 145 designated as either a Root or a Leaf. A Root can communicate with 146 all other endpoints in the same multipoint Ethernet service, however 147 a Leaf can only communicate with Roots but not Leaves. 149 The only differences between E-LAN and E-Tree are: 150 - E-LAN has Root endpoints only, which implies there is no 151 communication restriction between endpoints. 152 - E-Tree has both Root and Leaf endpoints, which implies there is a 153 need to enforce communication restriction between Leaf endpoints. 155 3.3. E-Tree Use Cases 157 Table 1 below presents some major E-Tree use cases. 159 +---------------------------+--------------+------------+ 160 | Use Case | Root | Leaf | 161 +---+---------------------------+--------------+------------+ 162 | 1 | Hub & Spoke VPN | Hub Site | Spoke Site | 163 +---+---------------------------+--------------+------------+ 164 | 2 | Wholesale Access | Customer's | Customer's | 165 | | | Interconnect | Subscriber | 166 +---+---------------------------+--------------+------------+ 167 | 3 | Mobile Backhaul | Radio Area | RAN Base | 168 | | | Network (RAN)| Station | 169 | | | Network | | 170 | | | Controller | | 171 +---+---------------------------+--------------+------------+ 172 | 4 | IEEE 1588 PTPv2 | Precision | PTP Client | 173 | | Clock Synchronisation | time Protocol| | 174 | | | (PTP) Server | | 175 +---+---------------------------+--------------+------------+ 176 | 5 | Internet Access | Broadband | Subscriber | 177 | | [TR-101] | Network | | 178 | | | Gateway | | 179 +---+---------------------------+--------------+------------+ 180 | 6 | Broadcast Video | Video Source | Subscriber | 181 | | (unidirectional only) | | | 182 +---+---------------------------+--------------+------------+ 183 | 7 | Broadcast/Multicast Video | Video Source | Subscriber | 184 | | plus Control Channel | | | 185 +---+---------------------------+--------------+------------+ 186 | 8 | Device Management | Management | Managed | 187 | | | System | Device | 188 +---+---------------------------+--------------+------------+ 190 Table 1: E-Tree Use Cases 192 Common to all use cases, direct layer 2 Leaf-to-Leaf communication is 193 not required or must be inhibited. 195 If direct layer 2 Leaf-to-Leaf communication is not allowed due to 196 security concern, then E-Tree should be used to prohibit 197 communication between Leaf endpoints. Otherwise E-LAN is also a 198 feasible option. 200 3.4. Generic E-Tree Service 202 A generic E-Tree service supports multiple Root endpoints. The need 203 for multiple Root endpoints is usually driven by redundancy 204 requirement. Whether a particular E-Tree service needs to support 205 single or multiple Roots depends on the target application. 207 A generic E-Tree service supports all the following traffic flows: 208 - Ethernet Unicast from Root to Leaf 209 - Ethernet Unicast from Leaf to Root 210 - Ethernet Unicast from Root to Root 211 - Ethernet Broadcast/Multicast from Root to other Roots & Leaves 212 - Ethernet Broadcast/Multicast from Leaf to Roots 213 A particular E-Tree service may need to support all the above or only 214 a subset depending on the target application. 216 4. Problem Statement 218 4.1. Motivation 220 L2VPN can be used to emulate MEF E-LAN service over an IP/MPLS PSN. 222 Service providers also require E-Tree support in L2VPN. 224 4.2. Leaf-to-Leaf Communication Restriction 226 In this section, VPLS is used to illustrate the problem. But the same 227 principle applies to other L2VPN technologies. 229 VPLS treats all attachment circuits (ACs) equally (essentially as 230 Roots, although they not classified into Root or Leaf) and provides 231 any-to-any connectivity among all ACs. VPLS does not include any 232 mechanism for communication restriction between specific ACs. 233 Therefore it is insufficient for emulating generic E-Tree service 234 over an IP/MPLS PSN. 236 As an example of the problems not addressed in VPLS solutions, 237 consider the scenario in Figure 1 where there are two PEs, each with 238 a Root AC and a Leaf AC and where VPLS is used to emulate an E-Tree 239 service interconnecting these ACs over an IP/MPLS PSN. 241 <------------E-Tree------------> 242 +---------+ +---------+ 243 | PE1 | | PE2 | 244 +---+ | +---+ | | +---+ | +---+ 245 |CE1+-----AC1----+--+ | | | | +--+----AC3-----+CE3| 246 +---+ (Root AC) | | V | | Ethernet | | V | | (Root AC) +---+ 247 | | S +--+-----PW-----+--+ S | | 248 +---+ | | I | | | | I | | +---+ 249 |CE2+-----AC2----+--+ | | | | +--+----AC4-----+CE4| 250 +---+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +---+ 251 +---------+ +---------+ 253 Figure 1: Problem Scenario for Leaf-to-Leaf Communication Restriction 255 When PE2 receives a frame from PE1 via the Ethernet PW, 256 - PE2 does not know which AC on PE1 is the ingress AC 257 - PE2 does not know whether the ingress AC is a Leaf AC or not 258 - PE2 does not have sufficient information to enforce the 259 Leaf-to-Leaf communication restriction 261 Examples where the problems arise: 262 - CE2 sends a Broadcast/Multicast Ethernet frame to PE1 via AC2 263 - CE2 sends a Unicast Ethernet frame to PE1 via AC2 with a 264 destination MAC address corresponding to CE4's MAC address 266 Note: Figure 1 is a hypothetical case solely used for explaining the 267 problem, and not meant to represent a typical E-Tree service. 269 There are some possible ways to get around this problem that do not 270 require extensions to existing VPLS solutions but they all come with 271 significant design complexity or deployment constraints, please refer 272 to [Draft ETree Frwk] Appendix A. 274 5. Requirements 276 5.1. Functional Requirements 278 Following are the E-Tree L2VPN functional requirements: 280 (1) A solution MUST prohibit communication between any two Leaf ACs 281 in a L2VPN instance. 283 (2) A solution MUST allow multiple Root ACs in a L2VPN instance. 285 (3) A solution MUST allow Root AC and Leaf AC of a L2VPN instance to 286 co-exist on any PE. 288 5.2. Applicability 290 A solution MUST identify the L2VPN technology ([RFC4761], [RFC4762], 291 E-VPN) the solution is applicable to. 293 5.3. Backward Compatibility 295 A solution SHOULD minimise the impact on VPLS and E-VPN L2VPN 296 solutions, especially for the MEF E-LAN services already in 297 operation. 299 A solution SHOULD be backward compatible with the VPLS and E-VPN 300 L2VPN solutions. It SHOULD allow a case where a common L2VPN instance 301 is composed of both PEs supporting the solution and PEs not 302 supporting it, and the Leaf-to-Leaf communication restriction is 303 enforced within the scope of the compliant PEs. 305 5.4. External Network Network Interface (ENNI) 307 A solution SHOULD support Root Operator Virtual Connection (OVC) End 308 Point, Leaf OVC End Point and Trunk OVC End Point specified in 309 [MEF26.1]. 311 6. Security Considerations 313 This document introduces a requirement of prohibiting communication 314 between any two Leaf ACs in a L2VPN instance. In some use cases, such 315 requirement is imposed because of security reasons. Other than that, 316 there are no additional security considerations beyond those already 317 described in [RFC4761] [RFC4762] [Draft EVPN Req]. 319 7. IANA Considerations 321 This document has no actions for IANA. 323 8. Contributors 325 Ruediger Kunze, Deutsche Telekom 326 Nick Del Regno, Verizon 327 Josh Rogers, Time Warner Cable 329 9. Acknowledgements 331 The authors would like to thank Lizhong Jin, Lucy Yong, Yuji Kamite 332 and Wim Henderickx for their valuable input and support. 334 10. References 336 10.1. Normative References 338 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate 339 Requirement Levels, BCP 14, RFC 2119, March 1997 341 [MEF6.1] Metro Ethernet Forum, Ethernet Services Definitions - 342 Phase 2, April 2008 344 [MEF10.2] Metro Ethernet Forum, Ethernet Services Attributes - 345 Phase 2, October 2009 347 [MEF22.1] Metro Ethernet Forum, Mobile Backhaul Implementation 348 Agreement - Phase 2, January 2012 350 [MEF26.1] Metro Ethernet Forum, External Network Network Interface 351 (ENNI) - Phase 2, January 2012 353 [RFC4761] Kompella & Rekhter, Virtual Private LAN Service (VPLS) 354 Using BGP for Auto-Discovery and Signaling, January 2007 356 [RFC4762] Lasserre & Kompella, Virtual Private LAN Service (VPLS) 357 Using Label Distribution Protocol (LDP) Signaling, 358 January 2007 360 10.2. Informative References 362 [Draft EVPN Req] Sajassi, et al., Requirements for Ethernet VPN 363 (EVPN), draft-ietf-l2vpn-evpn-req-04 364 (work in progress), July 2013 366 [TR-101] Broadband Forum, Migration to Ethernet-Based 367 Broadband Aggregation Issue 2, July 2011 369 [Draft ETree Frwk] Key, et al., A Framework for E-Tree Service over 370 MPLS Network, draft-ietf-l2vpn-etree-frwk-02 371 (work in progress), February 2013 373 [Draft VPMS Frmwk] Kamite, et al., Framework and Requirements for 374 Virtual Private Multicast Service (VPMS), 375 draft-ietf-l2vpn-vpms-frmwk-requirements-05 376 (work in progress), October 2012 378 Appendix A. Frequently Asked Questions 380 A.1. Are E-Tree requirements addressed in the Virtual Private Multicast 381 Service (VPMS) requirements? 383 VPMS requirements are defined in [Draft VPMS Frmwk]. 385 The focus of VPMS is to provide point-to-multipoint connectivity. 387 VPMS provides single coverage of receiver membership (i.e., there is 388 no distinct differentiation for multiple multicast groups). A VPMS 389 service supports single or multiple Root ACs. All traffic from a Root 390 AC will be forwarded to all Leaf ACs (i.e., P2MP, from Root to all 391 Leaves). Destination address in Ethernet frame is not used in data 392 forwarding. As an optional capability, a VPMS service may support 393 reverse traffic from a Leaf AC to a Root AC (i.e., P2P, from Leaf to 394 Root). 396 In contrast, the focus of MEF E-Tree is that a Leaf can only 397 communicate with Roots but not Leaves. 399 A generic MEF E-Tree service supports multiple Root endpoints. 400 Whether a particular E-Tree service needs to support single or 401 multiple Root endpoints depends on the target application. 403 As discussion in a previous section, a generic MEF E-Tree service 404 supports all the following traffic flows: 405 - Ethernet Unicast bidirectional Root to/from Root 406 - Ethernet Unicast bidirectional Root to/from Leaf 407 - Ethernet Broadcast/Multicast unidirectional Root to all Roots & 408 Leaves 409 - Ethernet Broadcast/Multicast unidirectional Leaf to all Roots. 410 A particular E-Tree service may need to support all the above or only 411 a subset depending on the target application. 413 IETF's VPMS definition and MEF's E-Tree definition are significantly 414 different. 416 VPMS may be acceptable in cases where E-Tree service is needed, such 417 as in the following cases: 418 - No Unicast traffic from Root destined for a specific Leaf (or 419 there is no concern if such Unicast traffic is forwarded to all 420 Leaves) 421 - No traffic between Roots 423 For generic E-Tree service, VPMS will not be able to meet the 424 requirements. 426 Authors' Addresses 428 Raymond Key (editor) 429 Huawei 430 Email: raymond.key@ieee.org 432 Simon Delord 433 Telstra 434 Email: simon.delord@gmail.com 436 Frederic Jounay 437 Orange CH 438 4 rue caudray 1020 Renens 439 Switzerland 440 Email: frederic.jounay@orange.ch 442 Lu Huang 443 China Mobile 444 Unit 2, 28 Xuanwumenxi Ave, Xuanwu District 445 Beijing 100053, China 446 Email: huanglu@chinamobile.com 448 Zhihua Liu 449 China Telecom 450 109 Zhongshan Ave., Guangzhou 451 510630, China 452 Email: zhliu@gsta.com 454 Manuel Paul 455 Deutsche Telekom 456 Winterfeldtstr. 21-27 457 10781 Berlin, Germany 458 Email: manuel.paul@telekom.de 460 Contributors' Addresses 462 Ruediger Kunze 463 Deutsche Telekom 464 Winterfeldtstr. 21-27 465 10781 Berlin, Germany 466 Email: ruediger.kunze@telekom.de 468 Nick Del Regno 469 Verizon 470 400 International Pkwy 471 Richardson, TX 75081, USA 472 Email: nick.delregno@verizon.com 474 Josh Rogers 475 Time Warner Cable 476 11921 N Mo Pac Expy 477 Suite 210B 478 Austin, TX 78759, USA 479 Email: josh.rogers@twcable.com 481 Copyright Notice 483 Copyright (c) 2013 IETF Trust and the persons identified as the 484 document authors. All rights reserved. 486 This document is subject to BCP 78 and the IETF Trust's Legal 487 Provisions Relating to IETF Documents 488 (http://trustee.ietf.org/license-info) in effect on the date of 489 publication of this document. Please review these documents 490 carefully, as they describe your rights and restrictions with respect 491 to this document. Code Components extracted from this document must 492 include Simplified BSD License text as described in Section 4.e of 493 the Trust Legal Provisions and are provided without warranty as 494 described in the Simplified BSD License.