idnits 2.17.1 draft-ietf-l2vpn-etree-frwk-04.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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Overview' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7. IANA Considerations' ) ** There are 26 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([VPMS], [RFC4761], [IEEE1588], [RFC4762], [RFC4664], [TR-101], [ETREEREQ], [EVPN], [IEEE802.1Q]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 111: '...ame at a Leaf AC MUST NOT be delivered...' RFC 2119 keyword, line 233: '...le receivers and MAY support reverse t...' RFC 2119 keyword, line 242: '... Each AC MUST be configured as a ro...' RFC 2119 keyword, line 254: '... with Root role MUST be the result of...' RFC 2119 keyword, line 258: '...C with Leaf role MUST be the result of...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 21, 2014) is 3747 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 section? 'RFC4664' on line 472 looks like a reference -- Missing reference section? 'RFC4761' on line 475 looks like a reference -- Missing reference section? 'RFC4762' on line 479 looks like a reference -- Missing reference section? 'EVPN' on line 496 looks like a reference -- Missing reference section? 'IEEE802.1Q' on line 464 looks like a reference -- Missing reference section? 'VPMS' on line 492 looks like a reference -- Missing reference section? 'TR-101' on line 485 looks like a reference -- Missing reference section? 'ETREEREQ' on line 488 looks like a reference -- Missing reference section? 'IEEE1588' on line 467 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Raymond Key (editor) 2 Internet Draft Lucy Yong, Huawei (editor) 3 Category Informational Simon Delord, Telstra 4 Frederic Jounay, Orange CH 5 Lizhong Jin 7 Expires: July 2014 January 21, 2014 9 A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol 10 Label Switching (MPLS) Network 12 draft-ietf-l2vpn-etree-frwk-04 14 Abstract 16 This document describes an Ethernet-Tree (E-Tree) solution framework 17 for supporting the Metro Ethernet Forum (MEF) E-Tree service over a 18 Multiprotocol Label Switching (MPLS) network. The objective is to 19 provide a simple and effective approach to emulate E-Tree services 20 in addition to Ethernet LAN (E-LAN) services on an existing MPLS 21 network. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with 26 the provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other documents 35 at any time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on July 21, 2014. 46 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with 56 respect to this document. Code Components extracted from this 57 document must include Simplified BSD License text as described in 58 Section 4.e of the Trust Legal Provisions and are provided without 59 warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction...................................................3 64 1.1. Terminology...............................................3 65 2. Overview.......................................................4 66 2.1. Ethernet Bridge Network...................................4 67 2.2. MEF Multipoint Ethernet Services: E-LAN and E-Tree........4 68 2.3. IETF L2VPN................................................5 69 2.3.1. Virtual Private LAN Service (VPLS)...................5 70 2.3.2. Ethernet VPN (EVPN)..................................5 71 2.3.3. Virtual Private Multicast Service (VPMS).............6 72 3. E-Tree Architecture Reference Model............................6 73 4. E-Tree Use Cases...............................................8 74 5. L2VPN Gaps for Emulating MEF E-Tree Service....................9 75 5.1. No Differentiation on AC Role.............................9 76 5.2. No AC Role Indication or Advertisement....................9 77 6. Security Considerations.......................................10 78 7. IANA Considerations...........................................10 79 8. Contributing Authors..........................................10 80 9. References....................................................11 81 9.1. Normative References.....................................11 82 9.2. Informative References...................................11 84 1. Introduction 86 This document describes an Ethernet-Tree (E-Tree) solution framework 87 for supporting the Metro Ethernet Forum (MEF) E-Tree service over a 88 Multiprotocol Label Switching (MPLS) network. The objective is to 89 provide a simple and effective approach to emulate E-Tree services 90 in addition to Ethernet LAN (E-LAN) services on an existing MPLS 91 network. 93 This document extends the existing IETF specified Layer 2 Virtual 94 Private Network (L2VPN) framework [RFC4664] to provide the emulation 95 of E-Tree services over an MPLS network. It specifies the E-Tree 96 architecture reference model and describes the corresponding 97 functional components. It also points out the gaps and required 98 extension areas in existing L2VPN solutions such as Virtual Private 99 LAN Service (VPLS)[RFC4761][RFC4762] and Ethernet Virtual Private 100 Network (EVPN)[EVPN] for supporting E-Tree services. 102 1.1. Terminology 104 This document adopts all the terminologies defined in [RFC4664], 105 [RFC4761], and [RFC4762]. It also uses the following terminologies: 107 Leaf Attachment Circuit (AC): An AC with Leaf role. An ingress 108 Ethernet frame at a Leaf AC (Ethernet frame arriving over an AC at 109 the provider edge (PE) of an MPLS network) can only be delivered to 110 one or more Root ACs in an E-Tree service instance. An ingress 111 Ethernet frame at a Leaf AC MUST NOT be delivered to any Leaf ACs in 112 the E-Tree service instance. 114 Root AC: An AC with Root role. An ingress Ethernet frame at a Root 115 AC can be delivered to one or more of the other ACs in the 116 associated E-Tree service instance. 118 E-Tree: An Ethernet VPN service in which each AC is assigned the 119 role of a Root or Leaf. The forwarding rules in E-Tree are: Root AC 120 can communicate with other Root ACs and Leaf ACs; Leaf ACs can only 121 communicate with Root ACs. 123 2. Overview 125 2.1. Ethernet Bridge Network 127 In this document, Ethernet bridge network refers to the Ethernet 128 bridge/switch network defined in IEEE802.1Q [IEEE802.1Q]. In a 129 bridge network, a data frame is an Ethernet frame; data forwarding 130 is based on destination MAC address; MAC reachability is learned in 131 the data plane based on the source MAC address and the port (or 132 tagged port) on which the frame arrives; and the MAC aging mechanism 133 is used to remove inactive MAC addresses from the MAC forwarding 134 table on an Ethernet switch. 136 Data frames arriving at a switch may be destined to known unicast 137 MAC destinations, unknown, multicast, or broadcast MAC destinations. 138 Unknown, multicast, and broadcast frames are forwarded in a similar 139 way, i.e. to every port except the ingress port on which the frame 140 arrives. Multicast forwarding can be further constrained when using 141 multicast control protocol snooping or multicast MAC registration 142 protocols. [IEEE802.1Q] 144 An Ethernet host receiving an Ethernet frame checks the destination 145 address in the frame to decide whether it is the intended 146 destination. 148 2.2. MEF Multipoint Ethernet Services: E-LAN and E-Tree 150 MEF [MEF6.2] defines two multipoint Ethernet Service types: 152 o E-LAN (Ethernet LAN), a multipoint-to-multipoint service 154 o E-Tree (Ethernet Tree), a rooted-multipoint service 156 According to MEF's technical specification, a multipoint Ethernet 157 service is always bidirectional, which means that any AC in the 158 service can send and receive Ethernet frames to/from customer 159 equipment (CE). Note that the term AC is equivalent to MEF User- 160 Network Interface (UNI). Furthermore, MEF also defines AC roles. One 161 role is Root and another is Leaf. Besides destination MAC-based 162 forwarding, additional forwarding rules defined by MEF for a 163 multipoint Ethernet Service are below: 165 o A Root AC can receive/transmit a frame from/to any other ACs. 167 o A Leaf AC can receive/transmit a frame from/to any Root ACs. 169 o A Leaf AC cannot receive/transmit a frame from/to any Leaf ACs. 171 For an E-LAN service, all ACs have the Root role, which means that 172 any AC can communicate with other ACs in the service. The E-LAN 173 service defined by MEF may be supported by existing IETF L2VPN 174 solutions, VPLS and EVPN. 176 An E-Tree service has one or more Root ACs and many Leaf ACs. An E- 177 Tree service supports the communication among the roots and between 178 a root and a leaf but prohibits the communication among the leaves. 179 Existing IETF L2VPN solutions can't support the E-Tree service. This 180 document specifies the E-Tree architecture reference model that 181 supports the E-Tree service defined by MEF [MEF6.2]. Section 4 will 182 discuss different E-Tree use cases. 184 2.3. IETF L2VPN 186 2.3.1. Virtual Private LAN Service (VPLS) 188 VPLS [RFC4761] [RFC4762] is an L2VPN solution that provides 189 multipoint-to-multipoint Ethernet connectivity across IP/MPLS 190 networks. VPLS emulates traditional Ethernet Virtual LAN Services 191 (VLAN) in MPLS networks, and may support MEF E-LAN services. 193 A data frame in VPLS is an Ethernet frame. Data forwarding in a VPLS 194 instance is based on the destination MAC address and the VLAN on 195 which the fame arrives. MAC reachability learning is performed in 196 the data plane based on the source address and the AC or Pseudowire 197 (PW) on which the frame arrives. MAC aging is also the mechanism 198 used to remove inactive MAC addresses from a VPLS switching instance 199 (VSI) on a Provider Edge (PE). VPLS supports forwarding for known 200 unicast, unknown unicast, broadcast, and multicast Ethernet frames. 202 Many service providers have deployed VPLS in their networks to 203 provide L2VPN services to customers. 205 2.3.2. Ethernet VPN (EVPN) 207 Ethernet VPN [EVPN] is an enhanced L2VPN solution that emulates an 208 Ethernet LAN or virtual LAN(s) across MPLS networks. 210 EVPN supports active-active multi-homing of CEs and uses 211 Multiprotocol Border Gateway Protocol (MP-BGP) control plane to 212 advertise MAC address reachability from an ingress PE to egress PEs. 213 Thus, a PE learns MAC addresses reachable over local ACs in the data 214 plane and other MAC addresses reachable across the MPLS network over 215 remote ACs via the EVPN MP-BGP control plane. As a result, EVPN aims 216 to support large-scale L2VPN with better resiliency compared to VPLS. 218 EVPN is relatively new technique and is still under development in 219 the IETF L2VPN WG. 221 2.3.3. Virtual Private Multicast Service (VPMS) 223 VPMS [VPMS] is an L2VPN solution that provides point-to-multipoint 224 connectivity across MPLS networks and supports various attachment 225 circuit (AC) types, including Frame Relay, ATM, Ethernet, PPP, etc. 227 In the case of Ethernet ACs, VPMS provides single coverage of 228 receiver membership, i.e. there is no distinct differentiation for 229 multicast groups in one VPN. Destination address in the Ethernet 230 frame is not used in data forwarding. 232 VPMS supports unidirectional point-to-multipoint transport from a 233 sender to multiple receivers and MAY support reverse transport in a 234 point-to-point manner. 236 3. E-Tree Architecture Reference Model 238 Figure 1 illustrates the E-Tree architecture reference model. Three 239 provider edges (PEs), PE1, PE2 and PE3 are shown in the figure. Each 240 of these PEs has a Virtual Service Instance (VSI) associated with an 241 E-Tree service instance. A CE attaches to a VSI on a PE via an AC. 242 Each AC MUST be configured as a root or leaf AC. In figure 1, AC1 243 AC2, AC5, AC6, AC9, AC10 are Root ACs; AC3, AC4, AC7, AC8, AC11, 244 AC12 are Leaf ACs. This implies that an Ethernet frame from CE01, 245 CE02, etc will be treated as a frame originated from a Root AC; a 246 frame from CE03, CE04, etc will be treated as a frame originated 247 from a Leaf AC. 249 Under this architecture model, the forwarding rules among ACs, 250 regardless whether sending AC and receiving AC are on the same PE or 251 on different PEs, are described as follow: 253 o An egress frame (frame to be transmitted over an AC) at an AC 254 with Root role MUST be the result of an ingress frame at an AC 255 (frame received at an AC) that has Root or Leaf role attached to 256 the same E-tree service instance. 258 o An egress frame at the AC with Leaf role MUST be the result of an 259 ingress frame at an AC that has Root role attached to the same E- 260 tree service instance. 262 These rules apply to all frame types, i.e. Known Unicast, Unknown, 263 Broadcast, and Multicast. For Known Unicast frames, forwarding in a 264 VSI context is based on the destination MAC address. 266 A VSI on a PE corresponds to an E-Tree instance and maintains a MAC 267 forwarding table which is isolated from other VSI tables on the PE. 268 It also keeps the track of local AC roles. The VSI receives a frame 269 from an AC or across the MPLS core and forwards the frame on another 270 AC over which the destination is reachable according to the VSI 271 forwarding table and forwarding rules described above. When the 272 target AC is on a remote PE, the VSI forwards the frame to the 273 remote PE over the MPLS core. Forwarding over the MPLS core will be 274 dependent on the E-tree solution. For instance, a solution may 275 adopt PWs to mesh VSIs as in VPLS, and forward frames over VSIs 276 subject to the E-tree forwarding rules. Alternatively, a solution 277 may adopt the EVPN forwarding paradigm constrained by the E-tree 278 forwarding rules. Thus, solutions that satisfy the E-tree 279 requirements could be extensions to VPLS and EVPN. 281 <------------E-Tree-------------> 282 PE1+---------+ +---------+PE2 283 +----+ | +---+ | | +---+ | +----+ 284 |CE01+----AC1----+--+ | | | | +--+----AC5----+CE05| 285 +----+ (Root AC) | | V | | | | V | | (Root AC) +----+ 286 +----+ | | | | | | | | +----+ 287 |CE02+----AC2----+--+ | | | | +--+----AC6----+CE06| 288 +----+ (Root AC) | | S +--+------------+--+ S | | (Root AC) +----+ 289 +----+ | | | | | | | | +----+ 290 |CE03+----AC3----+--+ | | | | +--+----AC7----+CE07| 291 +----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+ 292 +----+ | | | | | | | | +----+ 293 |CE04+----AC4----+--+ | | | | +--+----AC8----+CE08| 294 +----+ (Leaf AC) | +-+-+ | | +-+-+ | (Leaf AC) +----+ 295 +----+----+ +----+----+ 296 | MPLS Core | 297 | +----+----+ 298 | | +-+-+ | +----+ 299 | | | +--+----AC9----+CE09| 300 | | | V | | (Root AC) +----+ 301 | | | | | +----+ 302 | | | +--+----AC10---+CE10| 303 +-----------------+--+ S | | (Root AC) +----+ 304 | | | | +----+ 305 | | +--+----AC11---+CE11| 306 | | I | | (Leaf AC) +----+ 307 | | | | +----+ 308 | | +--+----AC12---+CE12| 309 | +---+ | (Leaf AC) +----+ 310 PE3 +---------+ 311 <------------E-Tree-------------> 313 Figure 1 E-Tree Architecture Reference Model 315 In most use cases, an E-Tree service has only a few Root ACs (root 316 CE sites) but many Leaf ACs (leaf CE sites). Furthermore, a PE may 317 have only Root ACs or only Leaf ACs. Figure 1 provides a general E- 318 Tree architecture model. 320 4. E-Tree Use Cases 322 Table 1 below presents some major use cases for E-Tree. 324 +---------------------------+--------------+------------+ 325 | Use Case | Root AC | Leaf AC | 326 +---+---------------------------+--------------+------------+ 327 | 1 | Hub & Spoke VPN | Hub Site | Spoke Site | 328 +---+---------------------------+--------------+------------+ 329 | 2 | Wholesale Access | Customer's | Customer's | 330 | | | Interconnect | Subscriber | 331 +---+---------------------------+--------------+------------+ 332 | 3 | Mobile Backhaul | RAN NC | RAN BS | 333 +---+---------------------------+--------------+------------+ 334 | 4 | IEEE 1588 PTPv2 [IEEE1588]| PTP Server | PTP Client | 335 | | Clock Synchronization | | | 336 +---+---------------------------+--------------+------------+ 337 | 5 | Internet Access | BNG Router | Subscriber | 338 | | Reference: [TR-101] | | | 339 +---+---------------------------+--------------+------------+ 340 | 6 | Broadcast Video | Video Source | Subscriber | 341 | | (unidirectional only) | | | 342 +---+---------------------------+--------------+------------+ 343 | 7 | Broadcast/Multicast Video | Video Source | Subscriber | 344 | | plus Control Channel | | | 345 +---+---------------------------+--------------+------------+ 346 | 8 | Device Management | Management | Managed | 347 | | | System | Device | 348 +---+---------------------------+--------------+------------+ 350 Where: 352 RAN: Radio Access Network 353 NC: Network Controller 354 BS: Base Station 355 PTP: Precision Time Protocol 356 BNG: Broadband Network Gateway 358 Table 1: E-Tree Use Cases 360 Common to all use cases, direct Layer2 Leaf-to-Leaf communication is 361 required to be prohibited. For Mobile backhaul, this may not be 362 valid for LTE X2 interfaces in the future. If direct Layer 2 Leaf- 363 to-Leaf communication needs to be prohibited, E-Tree should be used. 365 Also common to the use cases mentioned above, there may be single or 366 multiple Root ACs in one E-Tree service. The need of multiple Root- 367 ACs may be driven by redundancy requirement or multiple serving 368 sites. Whether a particular E-Tree service needs to support single 369 or multiple Root ACs depends on the application. 371 An E-Tree service can meet these use case requirements. 373 Among the use cases mentioned above, broadcast video draws most 374 attention. In fact, broadcast video represents an example for 375 broadcast/multicast content delivery in general, such as news feed, 376 financial data feed, etc. 378 5. L2VPN Gaps for Emulating MEF E-Tree Service 380 E-Tree Service defines special forwarding rules that prohibit 381 forwarding Ethernet frames among leaves. This poses some challenges 382 to IETF L2VPN solutions, such as VPLS and EVPN, in emulating E-Tree 383 service over MPLS networks. There are two major issues described in 384 the following sections. 386 5.1. No Differentiation on AC Role 388 IP/MPLS L2VPN architecture only has single-role Attachment Circuit 389 (AC) and supports any-to-any connectivity among all ACs. It does not 390 include any mechanism for any forwarding constraint based on the AC 391 role. However, E-Tree service defines two AC roles, Root and Leaf, 392 and defines the forwarding rules among the ACs based on the AC roles. 394 5.2. No AC Role Indication or Advertisement 396 In IETF L2VPN, when a PE, say PE2, receives a frame from another PE, 397 say PE1, across the MPLS core, PE2 does not know if the frame is 398 originated from a root AC or leaf AC on PE1. This causes a 399 forwarding issue on PE2 because E-Tree forwarding rules require that 400 the forwarder MUST know the role of the frame origin, i.e. (from 401 root AC or leaf AC). This specifically important, when PE2 has both 402 a root AC and a leaf AC attached to the same VSI. The forwarding 403 rules apply to all types of frames (known unicast destination, 404 unknown unicast destination, multicast and broadcast). 406 In order to fulfill E-Tree service definition, L2VPN extension is 407 required to support Root and Leaf ACs and communicate AC role among 408 the PEs in an E-Tree instance. Furthermore, some desirable 409 requirements for IETF E-Tree are specific to an IP/MPLS L2VPN 410 implementation such as Leaf-only PE. A Leaf-only PE is the PE that 411 has all ACs associating to a VSI as the Leaf role, thus other PEs 412 on the same E-Tree instance do not necessarily forward the frames 413 coming from Leaf ACs to the Leaf-only PE, which may say some network 414 resources. It is also desirable for E-Tree solution to work with 415 existing PEs, i.e. PEs that only have single-role ACs and the role 416 is equivalent to the root role in an E-Tree Service. These 417 requirements are described in the E-Tree requirement document. 418 [ETREEREQ] 420 6. Security Considerations 422 There could be cases where an E-tree service is deployed for 423 security reasons to prohibit communication among sites (leaves) and 424 only allow communication between branch sites (leaves) and hub sites 425 (roots). Thus, an E-tree solution must enable the enforcement of an 426 E-tree service definition and the corresponding forwarding 427 constraints. The E-Tree solution must also guarantee that Ethernet 428 frames do not leak outside of the E-tree service instance to which 429 they belong. If additional security is desired, the PE-to-PE tunnels 430 can be IPsec tunnels. For more security, the end systems at the CE 431 sites may use appropriate means of encryption to secure their data 432 even before it enters the Service Provider network. 434 7. IANA Considerations 436 The document requires no IANA action. 438 8. Contributing Authors 440 The following people contribute the document as co-authors. 442 Yuji Kamite 443 NTT Communications Corporation 444 Granpark Tower 445 3-4-1 Shibaura, Minato-ku 446 Tokyo 108-8118, Japan 447 Email: y.kamite@ntt.com 449 Wim Henderickx 450 Alcatel-Lucent 451 Copernicuslaan 50 452 2018 Antwerp, Belgium 453 Email: wim.henderickx@alcatel-lucent.com 455 9. Acknowledgements 457 Authors like to thank Nabil Bitar for this detail review and 458 suggestions. 460 9. References 462 9.1. Normative References 464 [IEEE802.1Q] IEEE802.1, "Media Access Control (MAC) Bridges and 465 Virtual Bridged Local Area", IEEE802.1Q, 2011 467 [IEEE1588] IEEE 1588, "Precision Time Protocol", IEEE 1588, 2013 469 [MEF6.2] MEF, "Metro Ethernet Forum, Ethernet Services Definitions 470 - Phase 2", April 2008 472 [RFC4664] Andersson, L., et al, "Framework for Layer 2 Virtual 473 Private Network (L2VPNs)", RFC4664, Sept. 2006 475 [RFC4761] Kompella & Rekhter, "Virtual Private LAN Service (VPLS) 476 Using BGP for Auto-Discovery and Signaling", RFC4761, 477 January 2007 479 [RFC4762] Lasserre & Kompella, "Virtual Private LAN Service (VPLS) 480 Using Label Distribution Protocol (LDP) Signaling", 481 RFC4762, January 2007 483 9.2. Informative References 485 [TR-101] Broadband Forum, Migration to Ethernet-Based Broadband 486 Aggregation Issue 2, July 2011 488 [ETREEREQ] Key, et al., Requirements for Metro Ethernet Forum (MEF) 489 Ethernet-Tree (E-Tree) Support in L2VPN, draft-ietf-l2vpn- 490 etree-reqt-05 (work in progress), July 2013 492 [VPMS] Kamite, et al., Framework and Requirements for Virtual 493 Private Multicast Service (VPMS), draft-ietf-l2vpn-vpms- 494 frmwk-requirements-05 (work in progress), October 2012 496 [EVPN] Sajassi, et al., BGP MPLS Based Ethernet VPN, draft-ietf- 497 l2vpn-evpn-04 (work in progress), July 2013 499 Authors' Addresses 501 Raymond Key (editor) 502 Email: raymond.key@ieee.org 504 Lucy Yong (editor) 505 Huawei USA 506 Email: lucy.yong@huawei.com 508 Simon Delord 509 Telstra 510 Email: simon.delord@gmail.com 512 Frederic Jounay 513 Orange CH 514 4 rue caudray 1020 Renens 515 Switzerland 516 Email: frederic.jounay@orange.ch 518 Lizhong Jin 519 Email: lizho.jin@gmail.com