summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7387.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7387.txt')
-rw-r--r--doc/rfc/rfc7387.txt731
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc7387.txt b/doc/rfc/rfc7387.txt
new file mode 100644
index 0000000..1ef8cb7
--- /dev/null
+++ b/doc/rfc/rfc7387.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) R. Key, Ed.
+Request for Comments: 7387
+Category: Informational L. Yong, Ed.
+ISSN: 2070-1721 Huawei
+ S. Delord
+ Telstra
+ F. Jounay
+ Orange CH
+ L. Jin
+ October 2014
+
+
+ A Framework for Ethernet Tree (E-Tree) Service
+ over a Multiprotocol Label Switching (MPLS) Network
+
+Abstract
+
+ This document describes an Ethernet-Tree (E-Tree) solution framework
+ for supporting the Metro Ethernet Forum (MEF) E-Tree service over a
+ Multiprotocol Label Switching (MPLS) network. The objective is to
+ provide a simple and effective approach to emulate E-Tree services in
+ addition to Ethernet LAN (E-LAN) services on an existing MPLS
+ network.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7387.
+
+
+
+
+
+
+
+
+
+
+
+
+Key, et al. Informational [Page 1]
+
+RFC 7387 E-Tree Framework October 2014
+
+
+Copyright Notice
+
+ Copyright (c) 2014 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Terminology ................................................3
+ 2. Overview ........................................................4
+ 2.1. Ethernet Bridge Network ....................................4
+ 2.2. MEF Multipoint Ethernet Services: E-LAN and E-Tree .........4
+ 2.3. IETF L2VPN .................................................5
+ 2.3.1. Virtual Private LAN Service (VPLS) ..................5
+ 2.3.2. Ethernet VPN (EVPN) .................................5
+ 2.3.3. Virtual Private Multicast Service (VPMS) ............6
+ 3. E-Tree Architecture Reference Model .............................6
+ 4. E-Tree Use Cases ................................................8
+ 5. L2VPN Gaps for Emulating MEF E-Tree Service .....................9
+ 5.1. No Differentiation on AC Role ..............................9
+ 5.2. No AC Role Indication or Advertisement .....................9
+ 5.3. Other Issues ...............................................9
+ 6. Security Considerations ........................................10
+ 7. References .....................................................11
+ 7.1. Normative References ......................................11
+ 7.2. Informative References ....................................11
+ Acknowledgments ...................................................12
+ Contributors ......................................................12
+ Authors' Addresses ................................................13
+
+
+
+
+
+
+
+
+
+
+
+
+Key, et al. Informational [Page 2]
+
+RFC 7387 E-Tree Framework October 2014
+
+
+1. Introduction
+
+ This document describes an Ethernet-Tree (E-Tree) solution framework
+ for supporting the Metro Ethernet Forum (MEF) E-Tree service over a
+ Multiprotocol Label Switching (MPLS) network. The objective is to
+ provide a simple and effective approach to emulate E-Tree services in
+ addition to Ethernet LAN (E-LAN) services on an existing MPLS
+ network.
+
+ This document extends the existing IETF-specified Layer 2 Virtual
+ Private Network (L2VPN) framework [RFC4664] to provide the emulation
+ of E-Tree services over an MPLS network. It specifies the E-Tree
+ architecture reference model and describes the corresponding
+ functional components. It also points out the gaps and required
+ extension areas in existing L2VPN solutions such as Virtual Private
+ LAN Service (VPLS) [RFC4761] [RFC4762] and Ethernet Virtual Private
+ Network (EVPN) [EVPN] for supporting E-Tree services.
+
+1.1. Terminology
+
+ This document adopts all the terminologies defined in RFC 4664
+ [RFC4664], RFC 4761 [RFC4761], and RFC 4762 [RFC4762]. It also uses
+ the following terms:
+
+ Leaf Attachment Circuit (AC): An AC with Leaf role. An ingress
+ Ethernet frame at a Leaf AC (Ethernet frame arriving over an AC at
+ the Provider Edge (PE) of an MPLS network) can only be delivered
+ to one or more Root ACs in an E-Tree service instance. An ingress
+ Ethernet frame at a Leaf AC must not be delivered to any Leaf ACs
+ in the E-Tree service instance.
+
+ Root AC: An AC with Root role. An ingress Ethernet frame at a Root
+ AC can be delivered to one or more of the other ACs in the
+ associated E-Tree service instance.
+
+ E-Tree: An Ethernet VPN service in which each AC is assigned the role
+ of a Root or Leaf. The forwarding rules in an E-Tree are as
+ follows:
+
+ o The Root AC can communicate with other Root ACs and Leaf ACs.
+
+ o Leaf ACs can only communicate with Root ACs.
+
+
+
+
+
+
+
+
+
+Key, et al. Informational [Page 3]
+
+RFC 7387 E-Tree Framework October 2014
+
+
+2. Overview
+
+2.1. Ethernet Bridge Network
+
+ In this document, "Ethernet bridge network" refers to the Ethernet
+ bridge/switch network defined in IEEE 802.1Q [IEEE802.1Q]. In a
+ bridge network, a data frame is an Ethernet frame; data forwarding is
+ based on destination Media Access Control (MAC) address; MAC
+ reachability is learned in the data plane based on the source MAC
+ address and the port (or tagged port) on which the frame arrives; and
+ the MAC aging mechanism is used to remove inactive MAC addresses from
+ the MAC forwarding table on an Ethernet switch.
+
+ Data frames arriving at a switch may be destined to known unicast,
+ unknown unicast, multicast, or broadcast MAC destinations. Unknown
+ unicast, multicast, and broadcast frames are forwarded in a similar
+ way, i.e., to every port except the ingress port on which the frame
+ arrives. Multicast forwarding can be further constrained when using
+ multicast control protocol snooping or using multicast MAC
+ registration protocols [IEEE802.1Q].
+
+ An Ethernet host receiving an Ethernet frame checks the destination
+ address in the frame to decide whether it is the intended
+ destination.
+
+2.2. MEF Multipoint Ethernet Services: E-LAN and E-Tree
+
+ MEF 6.1 [MEF6.1] defines two multipoint Ethernet Service types:
+
+ o E-LAN (Ethernet LAN), a multipoint-to-multipoint service
+
+ o E-Tree (Ethernet Tree), a rooted-multipoint service
+
+ The MEF defines User-Network Interface (UNI) in a multipoint service
+ as the Ethernet interface between Customer Equipment (CE) and a
+ Provider Edge (PE), i.e., the PE can send and receive Ethernet frames
+ to/from the CE. The MEF also defines UNI roles in a multipoint
+ service. One role is Root, and another is Leaf.
+
+ Note that MEF UNI in a service is equivalent to the Attachment
+ Circuit (AC) defined in L2VPN [RFC4664]. The Root AC and Leaf AC
+ defined in this document are the same as the Root UNI and Leaf UNI as
+ defined in MEF 10.3 [MEF10.3]. The terms "Root AC" and "Leaf AC" are
+ used in the following MEF service description.
+
+
+
+
+
+
+
+Key, et al. Informational [Page 4]
+
+RFC 7387 E-Tree Framework October 2014
+
+
+ For an E-LAN service, all ACs have the Root role, which means that
+ any AC can communicate with other ACs in the service. The E-LAN
+ service defined by the MEF may be implemented by IETF L2VPN solutions
+ such as VPLS and EVPN [EVPN].
+
+ An E-Tree service has one or more Root ACs and at least two Leaf ACs.
+ An E-Tree service supports communication among the roots and between
+ a root and a leaf but prohibits communication among the leaves.
+ Existing IETF L2VPN solutions can't support the E-Tree service. This
+ document specifies the E-Tree architecture reference model that
+ supports the E-Tree service defined by the MEF [MEF6.1]. Section 4
+ will discuss different E-Tree use cases.
+
+2.3. IETF L2VPN
+
+2.3.1. Virtual Private LAN Service (VPLS)
+
+ VPLS [RFC4761] [RFC4762] is an L2VPN solution that provides
+ multipoint-to-multipoint Ethernet connectivity across IP/MPLS
+ networks. VPLS emulates traditional Ethernet Virtual LAN (VLAN)
+ services in MPLS networks and may support MEF E-LAN services.
+
+ A data frame in VPLS is an Ethernet frame. Data forwarding in a VPLS
+ instance is based on the destination MAC address and the VLAN on
+ which the frame arrives. MAC reachability learning is performed in
+ the data plane based on the source address and the AC or pseudowire
+ (PW) on which the frame arrives. MAC aging is the mechanism used to
+ remove inactive MAC addresses from a VPLS switching instance (VSI) on
+ a PE. VPLS supports forwarding for known unicast frames, as well as
+ unknown unicast, broadcast, and multicast Ethernet frames.
+
+ Many service providers have deployed VPLS in their networks to
+ provide L2VPN services to customers.
+
+2.3.2. Ethernet VPN (EVPN)
+
+ Ethernet VPN [EVPN] is an enhanced L2VPN solution that emulates an
+ Ethernet LAN or virtual LAN(s) across MPLS networks.
+
+ EVPN supports active-active multihoming of CEs and uses the
+ Multiprotocol Border Gateway Protocol (MP-BGP) control plane to
+ advertise MAC address reachability from an ingress PE to egress PEs.
+ Thus, a PE learns MAC addresses that are reachable over local ACs in
+ the data plane and other MAC addresses reachable across the MPLS
+ network over remote ACs via the EVPN MP-BGP control plane. As a
+ result, EVPN aims to support large-scale L2VPN with better resiliency
+ compared to VPLS.
+
+
+
+
+Key, et al. Informational [Page 5]
+
+RFC 7387 E-Tree Framework October 2014
+
+
+ EVPN is a relatively new technique and is still under development in
+ the IETF L2VPN WG.
+
+2.3.3. Virtual Private Multicast Service (VPMS)
+
+ VPMS [VPMS] is an L2VPN solution that provides point-to-multipoint
+ connectivity across MPLS networks and supports various attachment
+ circuit (AC) types, including Frame Relay, ATM, Ethernet, PPP, etc.
+
+ In the case of Ethernet ACs, VPMS provides single coverage of
+ receiver membership, i.e., there is no differentiation among
+ multicast groups in one VPN. The destination address in the Ethernet
+ frame is not used in data forwarding.
+
+ VPMS supports unidirectional point-to-multipoint transport from a
+ sender to multiple receivers and may support reverse transport in a
+ point-to-point manner.
+
+3. E-Tree Architecture Reference Model
+
+ Figure 1 illustrates the E-Tree architecture reference model. Three
+ Provider Edges -- PE1, PE2, and PE3 -- are shown in the figure. Each
+ PE has a Virtual Service Instance (VSI) associated with an E-Tree
+ service instance. A CE attaches to the VSI on a PE via an AC. Each
+ AC must be configured with a Root or Leaf role. In Figure 1, AC1,
+ AC2, AC5, AC6, AC9, and AC10 are Root ACs; AC3, AC4, AC7, AC8, AC11,
+ and AC12 are Leaf ACs. This implies that a PE (local or remote)
+ processes the Ethernet frames from CE01, CE02, etc., as if they
+ originated from a Root AC, and it processes the Ethernet frames from
+ CE03, CE04, etc., as if they originated from a Leaf AC.
+
+ Under this architecture model, the forwarding rules among the ACs,
+ regardless of whether the sending AC and receiving AC are on the same
+ PE or on different PEs, are described as follows:
+
+ o An egress frame (the frame to be transmitted over an AC) at an AC
+ with Root role must be the result of an ingress frame at an AC
+ (the frame received at an AC) that has Root or Leaf role and is
+ attached to the same E-Tree service instance.
+
+ o An egress frame at the AC with Leaf role must be the result of an
+ ingress frame at an AC that has Root role and is attached to the
+ same E-Tree service instance.
+
+
+
+
+
+
+
+
+Key, et al. Informational [Page 6]
+
+RFC 7387 E-Tree Framework October 2014
+
+
+ <------------E-Tree----------->
+ PE1+---------+ +---------+PE2
+ +----+ | +---+ | | +---+ | +----+
+ |CE01+----AC1----+--+ | | | | +--+----AC5----+CE05|
+ +----+ (Root AC) | | V | | | | V | | (Root AC) +----+
+ +----+ | | | | | | | | +----+
+ |CE02+----AC2----+--+ | | | | +--+----AC6----+CE06|
+ +----+ (Root AC) | | S +--+---------+--+ S | | (Root AC) +----+
+ +----+ | | | | | | | | +----+
+ |CE03+----AC3----+--+ | | | | +--+----AC7----+CE07|
+ +----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+
+ +----+ | | | | | | | | +----+
+ |CE04+----AC4----+--+ | | | | +--+----AC8----+CE08|
+ +----+ (Leaf AC) | +-+-+ | | +-+-+ | (Leaf AC) +----+
+ +----+----+ +----+----+
+ | MPLS Core |
+ | +----+----+
+ | | +-+-+ | +----+
+ | | | +--+----AC9----+CE09|
+ | | | V | | (Root AC) +----+
+ | | | | | +----+
+ | | | +--+----AC10---+CE10|
+ +--------------+--+ S | | (Root AC) +----+
+ | | | | +----+
+ | | +--+----AC11---+CE11|
+ | | I | | (Leaf AC) +----+
+ | | | | +----+
+ | | +--+----AC12---+CE12|
+ | +---+ | (Leaf AC) +----+
+ PE3 +---------+
+ <-------------E-Tree---------->
+
+ Figure 1: E-Tree Architecture Reference Model
+
+ These rules apply to all frame types, i.e., known unicast, unknown
+ unicast, broadcast, and multicast. For known unicast frames,
+ forwarding in a VSI context is based on the destination MAC address.
+
+ A VSI on a PE corresponds to an E-Tree service instance and maintains
+ a MAC forwarding table that is isolated from other VSI tables on the
+ PE. It also keeps track of local AC roles. The VSI receives a frame
+ from an AC or across the MPLS core, and it forwards the frame to
+ another AC over which the destination is reachable according to the
+ VSI forwarding table and forwarding rules described above. When the
+ target AC is on a remote PE, the VSI forwards the frame to the remote
+ PE over the MPLS core. Forwarding over the MPLS core will be
+ dependent on the E-Tree solution. For instance, a solution may adopt
+ PWs to mesh VSIs as in VPLS and to forward frames over VSIs subject
+
+
+
+Key, et al. Informational [Page 7]
+
+RFC 7387 E-Tree Framework October 2014
+
+
+ to the E-Tree forwarding rules. Alternatively, a solution may adopt
+ the EVPN forwarding paradigm constrained by the E-Tree forwarding
+ rules. Thus, solutions that satisfy the E-Tree requirements could be
+ extensions to VPLS and EVPN.
+
+ In most use cases, an E-Tree service has only a few Root ACs (root CE
+ sites) but many Leaf ACs (leaf CE sites). Furthermore, a PE may have
+ only Root ACs or only Leaf ACs. Figure 1 provides a general E-Tree
+ architecture model.
+
+4. E-Tree Use Cases
+
+ Table 1 below presents some major use cases for E-Tree.
+
+ +---------------------------+--------------+------------+
+ | Use Case | Root AC | Leaf AC |
+ +---+---------------------------+--------------+------------+
+ | 1 | Hub & Spoke VPN | Hub Site | Spoke Site |
+ +---+---------------------------+--------------+------------+
+ | 2 | Wholesale Access | Customer's | Customer's |
+ | | | Interconnect | Subscriber |
+ +---+---------------------------+--------------+------------+
+ | 3 | Mobile Backhaul | RAN NC | RAN BS |
+ +---+---------------------------+--------------+------------+
+ | 4 | IEEE 1588 PTPv2 [IEEE1588]| PTP Server | PTP Client |
+ | | Clock Synchronization | | |
+ +---+---------------------------+--------------+------------+
+ | 5 | Internet Access | BNG Router | Subscriber |
+ | | Reference [TR-101] | | |
+ +---+---------------------------+--------------+------------+
+ | 6 | Broadcast Video | Video Source | Subscriber |
+ | | (unidirectional only) | | |
+ +---+---------------------------+--------------+------------+
+ | 7 | Broadcast/Multicast Video | Video Source | Subscriber |
+ | | plus Control Channel | | |
+ +---+---------------------------+--------------+------------+
+ | 8 | Device Management | Management | Managed |
+ | | | System | Device |
+ +---+---------------------------+--------------+------------+
+
+ Where:
+
+ RAN: Radio Access Network NC: Network Controller
+ BS: Base Station PTP: Precision Time Protocol
+ BNG: Broadband Network Gateway
+
+ Table 1: E-Tree Use Cases
+
+
+
+
+Key, et al. Informational [Page 8]
+
+RFC 7387 E-Tree Framework October 2014
+
+
+ Common to all use cases, direct Layer 2 leaf-to-leaf communication is
+ required to be prohibited. For mobile backhaul, this may not be
+ valid for Long Term Evolution (LTE) X2 interfaces; an LTE X2
+ interface [LTE] enables communication between two evolved Node Bs
+ (eNBs). E-Tree service is appropriate for such use cases.
+
+ Also common to the use cases mentioned above, there may be one or
+ multiple Root ACs in one E-Tree service. The need for multiple Root
+ ACs may be driven by a redundancy requirement or by having multiple
+ serving sites. Whether a particular E-Tree service needs to support
+ one or multiple Root ACs depends on the application.
+
+5. L2VPN Gaps for Emulating MEF E-Tree Service
+
+ The MEF E-Tree service defines special forwarding rules that prohibit
+ forwarding Ethernet frames among leaves. This poses some challenges
+ to IETF L2VPN solutions such as VPLS and EVPN in emulating E-Tree
+ service over an MPLS network. There are two major issues described
+ in the following subsections.
+
+5.1. No Differentiation on AC Role
+
+ IP/MPLS L2VPN architecture has no distinct roles on Attachment
+ Circuits (ACs) and supports any-to-any connectivity among all ACs.
+ It does not have any mechanism to support forwarding constraints
+ based on an AC role. However, the MEF E-Tree service defines two AC
+ roles -- Root and Leaf -- and defines the forwarding rules based on
+ the originating and receiving AC roles of a given frame.
+
+5.2. No AC Role Indication or Advertisement
+
+ In an L2VPN, when a PE, say PE2, receives a frame from another PE,
+ say PE1, over the MPLS core, PE2 does not know if the frame from PE1
+ is originated from a Root AC or Leaf AC. This causes the forwarding
+ issue on PE2 because the E-Tree forwarding rules require that the
+ forwarder must know the role of the frame origin, i.e., from Root AC
+ or Leaf AC. This is specifically important when PE2 has both Root AC
+ and Leaf AC attached to the VSI. E-Tree forwarding rules apply to
+ all types of frames (known unicast destination, unknown unicast
+ destination, multicast, and broadcast).
+
+5.3. Other Issues
+
+ Some desirable requirements for IETF E-Tree are specific to an
+ IP/MPLS L2VPN implementation such as Leaf-only PE. A Leaf-only PE is
+ a PE that only has Leaf AC(s) in an E-Tree service instance; thus,
+ other PEs on the same E-Tree service instance do not necessarily
+ forward the frames originated from a Leaf AC to the Leaf-only PE,
+
+
+
+Key, et al. Informational [Page 9]
+
+RFC 7387 E-Tree Framework October 2014
+
+
+ which may save some network resources. It is also desirable for an
+ E-Tree solution to work with existing PEs that support single-role
+ ACs, where the role is equivalent to the root in an E-Tree service.
+ These requirements are described in the E-Tree requirement document
+ [RFC7152].
+
+6. Security Considerations
+
+ An E-Tree service may be deployed for security reasons to prohibit
+ communication among sites (leaves). An E-Tree solution must enforce
+ E-Tree forwarding constraints. The solution must also guarantee that
+ Ethernet frames do not leak outside of the E-Tree service instance to
+ which they belong.
+
+ An E-Tree service prohibits communication among leaf sites but does
+ not have knowledge of higher-layer security constraints. Therefore,
+ in general, higher-layer applications cannot rely on E-Tree to
+ provide security protection unless all security constraints are fully
+ implemented by the E-Tree service.
+
+ Enhancing L2VPN for E-Tree services inherits the same security issues
+ described in the L2VPN framework document [RFC4664]. These relate to
+ both control-plane and data-plane security issues that may arise in
+ the following areas:
+
+ o issues fully contained in the provider network
+
+ o issues fully contained in the customer network
+
+ o issues in the customer-provider interface network
+
+ The framework document has substantial discussions on the security
+ issues and potential solutions to address them. An E-Tree solution
+ must consider these issues and address them properly. VPLS [RFC4761]
+ [RFC4762] and/or EVPN [EVPN] will likely be candidate solutions for
+ an E-Tree service over an MPLS network. The security capabilities
+ built into those solutions will be naturally adopted when supporting
+ E-Tree. For details, see the Security Considerations sections in
+ [RFC4761], [RFC4762], and [EVPN].
+
+
+
+
+
+
+
+
+
+
+
+
+Key, et al. Informational [Page 10]
+
+RFC 7387 E-Tree Framework October 2014
+
+
+7. References
+
+7.1. Normative References
+
+ [MEF6.1] Metro Ethernet Forum, "Ethernet Services Definitions -
+ Phase 2", MEF 6.1, April 2008.
+
+ [MEF10.3] Metro Ethernet Forum, "Ethernet Service Attributes -
+ Phase 3", MEF 10.3, October 2013.
+
+ [RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for
+ Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664,
+ September 2006,
+ <http://www.rfc-editor.org/info/rfc4664>.
+
+ [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private
+ LAN Service (VPLS) Using BGP for Auto-Discovery and
+ Signaling", RFC 4761, January 2007,
+ <http://www.rfc-editor.org/info/rfc4761>.
+
+ [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual
+ Private LAN Service (VPLS) Using Label Distribution
+ Protocol (LDP) Signaling", RFC 4762, January 2007,
+ <http://www.rfc-editor.org/info/rfc4762>.
+
+ [RFC7152] Key, R., Ed., DeLord, S., Jounay, F., Huang, L., Liu,
+ Z., and M. Paul, "Requirements for Metro Ethernet Forum
+ (MEF) Ethernet-Tree (E-Tree) Support in Layer 2 Virtual
+ Private Network (L2VPN)", RFC 7152, March 2014,
+ <http://www.rfc-editor.org/info/rfc7152>.
+
+7.2. Informative References
+
+ [IEEE802.1Q] IEEE, "IEEE Standard for Local and metropolitan area
+ networks -- Media Access Control (MAC) Bridges and
+ Virtual Bridged Local Area", IEEE Std 802.1Q, 2011.
+
+ [IEEE1588] IEEE, "IEEE Standard for a Precision Clock
+ Synchronization Protocol for Networked Measurement and
+ Control Systems", IEEE Std 1588, July 2008.
+
+ [LTE] 3GPP, "Evolved Universal Terrestrial Radio Access
+ (E-UTRA) and Evolved Universal Terrestrial Radio Access
+ Network (E-UTRAN)", 3GPP TS 36.300 v11.2.0, July 2012.
+
+ [TR-101] Broadband Forum, "Migration to Ethernet-Based Broadband
+ Aggregation", TR-101 Issue 2, July 2011.
+
+
+
+
+Key, et al. Informational [Page 11]
+
+RFC 7387 E-Tree Framework October 2014
+
+
+ [VPMS] Kamite, Y., Jounay, F., Niven-Jenkins, B., Brungard, D.,
+ and L. Jin, "Framework and Requirements for Virtual
+ Private Multicast Service (VPMS)", Work in Progress,
+ draft-ietf-l2vpn-vpms-frmwk-requirements-05,
+ October 2012.
+
+ [EVPN] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
+ and J. Uttaro, "BGP MPLS Based Ethernet VPN", Work in
+ Progress, draft-ietf-l2vpn-evpn-11, October 2014.
+
+Acknowledgments
+
+ The authors would like to thank Nabil Bitar and Adrian Farrel for
+ their detailed review and suggestions.
+
+Contributors
+
+ The following people contributed significantly to this document.
+
+ Yuji Kamite
+ NTT Communications Corporation
+ Granpark Tower
+ 3-4-1 Shibaura, Minato-ku
+ Tokyo 108-8118, Japan
+
+ EMail: y.kamite@ntt.com
+
+
+ Wim Henderickx
+ Alcatel-Lucent
+ Copernicuslaan 50
+ 2018 Antwerp, Belgium
+
+ EMail: wim.henderickx@alcatel-lucent.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Key, et al. Informational [Page 12]
+
+RFC 7387 E-Tree Framework October 2014
+
+
+Authors' Addresses
+
+ Raymond Key (editor)
+
+ EMail: raymond.key@ieee.org
+
+
+ Lucy Yong (editor)
+ Huawei USA
+
+ EMail: lucy.yong@huawei.com
+
+
+ Simon Delord
+ Telstra
+
+ EMail: simon.delord@gmail.com
+
+
+ Frederic Jounay
+ Orange CH
+ 4 rue caudray 1020 Renens
+ Switzerland
+
+ EMail: frederic.jounay@orange.ch
+
+
+ Lizhong Jin
+
+ EMail: lizho.jin@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Key, et al. Informational [Page 13]
+