wdiff rfc7387.original rfc7387.txt

L2VPN WG                                           Raymond Key (editor)
Internet Draft                               Lucy Engineering Task Force (IETF)                       R. Key, Ed.
Request for Comments: 7387
Category: Informational                                     L. Yong, Ed.
ISSN: 2070-1721                                                   Huawei (editor)
Intended status: Informational                             Simon
                                                               S. Delord
Expires: February 2015
                                                                 Telstra
                                             Frederic Jounay,
                                                               F. Jounay
                                                               Orange CH
                                                            Lizhong
                                                                  L. Jin
                                                        August 25,
                                                            October 2014

             A Framework for Ethernet Tree (E-Tree) Service
          over a Multiprotocol Label Switching (MPLS) Network
                    draft-ietf-l2vpn-etree-frwk-10.txt

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 This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum
   (IETF).  It represents the consensus of six months the IETF community.  It has
   received public review and may be updated, replaced, or obsoleted has been approved for publication by other the
   Internet Engineering Steering Group (IESG).  Not all documents at
   approved by the IESG are a candidate for any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list status of Internet-Draft Shadow Directories can this document, any errata,
   and how to provide feedback on it may be accessed obtained at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on February 25, 2015.
   http://www.rfc-editor.org/info/rfc7387.

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 Introduction ....................................................3
      1.1. Terminology...............................................3 Terminology ................................................3
   2. Overview.......................................................4 Overview ........................................................4
      2.1. Ethernet Bridge Network...................................4 Network ....................................4
      2.2. MEF Multipoint Ethernet Services: E-LAN and E-Tree........4 E-Tree .........4
      2.3. IETF L2VPN................................................5 L2VPN .................................................5
           2.3.1. Virtual Private LAN Service (VPLS)...................5 (VPLS) ..................5
           2.3.2. Ethernet VPN (EVPN)..................................5 (EVPN) .................................5
           2.3.3. Virtual Private Multicast Service (VPMS).............6 (VPMS) ............6
   3. E-Tree Architecture Reference Model............................6 Model .............................6
   4. E-Tree Use Cases...............................................8 Cases ................................................8
   5. L2VPN Gaps for Emulating MEF E-Tree Service....................9 Service .....................9
      5.1. No Differentiation on AC Role.............................9 Role ..............................9
      5.2. No AC Role Indication or Advertisement....................9 Advertisement .....................9
      5.3. Other Issues..............................................9 Issues ...............................................9
   6. Security Considerations.......................................10 Considerations ........................................10
   7. IANA Considerations...........................................10
   8. References....................................................11
      8.1. References .....................................................11
      7.1. Normative References.....................................11
      8.2. References ......................................11
      7.2. Informative References...................................11
   9. Contributing Authors..........................................12
   10. Acknowledgments..............................................12 References ....................................11
   Acknowledgments ...................................................12
   Contributors ......................................................12
   Authors' Addresses ................................................13

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 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] (VPLS) [RFC4761] [RFC4762] and Ethernet Virtual Private
   Network (EVPN)[EVPN] (EVPN) [EVPN] for supporting E-Tree services.

1.1.  Terminology

   This document adopts all the terminologies defined in RFC4664 RFC 4664
   [RFC4664], RFC4761 RFC 4761 [RFC4761], and RFC4762 RFC 4762 [RFC4762].  It also uses
   the following terminologies: 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 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 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: are as
      follows:

      o  The Root AC can communicate with other Root ACs and Leaf ACs; ACs.

      o  Leaf ACs can only communicate with Root ACs.

2.  Overview

2.1.  Ethernet Bridge Network

   In this document, Ethernet "Ethernet bridge network network" refers to the Ethernet
   bridge/switch network defined in IEEE802.1Q IEEE 802.1Q [IEEE802.1Q].  In a
   bridge network, a data frame is an Ethernet frame; data forwarding is
   based on destination MAC 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 MAC
   destinations, unknown, unicast,
   unknown unicast, multicast, or broadcast MAC destinations.
   Unknown,  Unknown
   unicast, multicast, and broadcast frames are forwarded in a similar
   way, i.e. 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] 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

   MEF6.1

   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 a Customer Equipment (CE) and a
   Provider Edge (PE), i.e. 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 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 of the root Root UNI and leaf Leaf UNI as
   defined in MEF10.3 MEF 10.3 [MEF10.3].  The Root AC and Leaf AC terms "Root AC" and "Leaf AC" are
   used in the following MEF service description.

   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 the communication among the roots and between
   a root and a leaf but prohibits the 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 Services (VLAN)
   services in MPLS networks, 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 pseudowire
   (PW) on which the frame arrives.  MAC aging is also the mechanism used to
   remove inactive MAC addresses from a VPLS switching instance (VSI) on
   a Provider Edge (PE). PE.  VPLS supports forwarding for known unicast, 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 multi-homing 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.

   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. i.e., there is no differentiation among
   multicast groups in one VPN. Destination  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 (PEs),
   Provider Edges -- PE1, PE2, and PE3 -- are shown in the Figure. 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 Root or leaf Leaf role.  In Figure 1, AC1 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 etc., as if they are
   originated from a Root AC; AC, and it processes the Ethernet frames from
   CE03, CE04, etc etc., as if they are 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 follow: follows:

   o  An egress frame (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 (frame
      (the frame received at an AC) that has Root or Leaf role and is
      attached to the same
      E-tree 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 E-Tree service instance.

                     <------------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 1: E-Tree Architecture Reference Model

   These rules apply to all frame types, i.e. Known Unicast, Unknown,
   Broadcast, i.e., known unicast, unknown
   unicast, broadcast, and Multicast. multicast.  For Known Unicast 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 which that is isolated from other VSI tables on the
   PE.  It also keeps the track of local AC roles.  The VSI receives a frame
   from an AC or across the MPLS core; 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 E-Tree solution.  For instance, a solution may adopt
   PWs to mesh VSIs as in VPLS, VPLS and to forward frames over VSIs subject
   to the E-tree E-Tree forwarding rules.  Alternatively, a solution may adopt
   the EVPN forwarding paradigm constrained by the E-tree E-Tree forwarding
   rules.  Thus, solutions that satisfy the E-tree 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 [1588]    | [IEEE1588]| PTP Server   | PTP Client |
      |   | Clock Synchronization     |              |            |
      +---+---------------------------+--------------+------------+
      | 5 | Internet Access           | BNG Router   | Subscriber |
      |   | Reference: 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 1: E-Tree Use Cases
   Common to all use cases, direct Layer2 Leaf-to-Leaf Layer 2 leaf-to-leaf communication is
   required to be prohibited.  For Mobile mobile backhaul, this may not be
   valid for LTE Long Term Evolution (LTE) X2 interfaces; an LTE X2
   interface [LTE] enables communication between two evolved
   node B (eNB) enables the communication in between. Node Bs
   (eNBs).  E-Tree service is appropriate for such use cases.

   Also common to the use cases mentioned above, there may be single one or
   multiple Root ACs in one E-Tree service.  The need of for multiple Root- Root
   ACs may be driven by a redundancy requirement or by having multiple
   serving sites.  Whether a particular E-Tree service needs to support single
   one or multiple Root ACs depends on an the application.

5.  L2VPN Gaps for Emulating MEF E-Tree Service

   The MEF E-Tree Service 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 sections. subsections.

5.1.  No Differentiation on AC Role

   IP/MPLS L2VPN architecture has no distinct role roles on Attachment Circuit
   (AC)
   Circuits (ACs) and supports any-to-any connectivity among all ACs.
   It does not have any mechanism to support forwarding constraint constraints
   based on an AC role.  However, the MEF E-Tree service defines two AC roles,
   roles -- Root and Leaf, Leaf -- and defines the forwarding rules based on
   the frame originating and receiving AC roles. 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 Root AC or leaf 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. i.e., from root Root AC
   or leaf Leaf AC.  This is specifically important, important when PE2 has both root Root AC
   and leaf Leaf AC attached to the VSI.  E-Tree forwarding rules apply to
   all types of frames (known unicast destination, unknown unicast
   destination, multicast 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
   the
   a PE that only has Leaf AC(s) in an E-Tree service instance, thus 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,
   which may save some network resources.  It is also desirable for E-
   Tree an
   E-Tree solution to work with existing PEs that support single-role AC
   and
   ACs, where the role is equivalent to the root in an E-Tree Service. service.
   These requirements are described in the E-Tree requirement document.
   [RFC7152] document
   [RFC7152].

6.  Security Considerations

   An E-tree E-Tree service may be deployed for security reasons to prohibit
   communication among sites (leaves).  An E-tree 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 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 higher-layer security constraint. constraints.  Therefore,
   in general, higher layer higher-layer applications can not cannot rely on E-Tree to
   provide
   the security protection unless all security constraints are fully
   implemented by the E-Tree service.

   Enhancing L2VPN for E-Tree service services inherits the same security issues
   described in the L2VPN framework document [RFC4664].  These relate to
   both control
   plane control-plane and data plane 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 service over an MPLS network.  The security capabilities
   built in these into those solutions will be naturally adopted in when supporting
   E-Tree.  For the
   detail, details, see the security consideration section Security Considerations sections in
   [RFC4761], [RFC4762], and [EVPN].

7. IANA Considerations

   The document requires no IANA action.

8.  References

8.1.

7.1.  Normative References

   [MEF6.1]  MEF, "Metro     Metro Ethernet Forum, Ethernet "Ethernet Services Definitions -
                Phase 2", MEF6.1, MEF 6.1, April 2008 2008.

   [MEF10.3] MEF,    Metro Ethernet Forum, "Ethernet Service Attributes -
                Phase 3", MEF10.3, MEF 10.3, October 2013 2013.

   [RFC4664]    Andersson, L., et al, Ed., and E. Rosen, Ed., "Framework for
                Layer 2 Virtual Private Network Networks (L2VPNs)", RFC4664, Sept. 2006 RFC 4664,
                September 2006, <http://www.rfc-editor.org/
                info/rfc4664>.

   [RFC4761] Kompella &    Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private
                LAN Service (VPLS) Using BGP for Auto-Discovery and
                Signaling", RFC4761, RFC 4761, January 2007 2007,
                <http://www.rfc-editor.org/info/rfc4761>.

   [RFC4762] Lasserre &    Lasserre, M., Ed., and V. Kompella, Ed., "Virtual
                Private LAN Service (VPLS) Using Label Distribution
                Protocol (LDP) Signaling",
             RFC4762, RFC 4762, January 2007 2007,
                <http://www.rfc-editor.org/info/rfc4762>.

   [RFC7152]    Key, et al., 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 L2VPN", RFC7152, April
             2011997.

8.2. Layer 2 Virtual
                Private Network (L2VPN)", RFC 7152, March 2014,
                <http://www.rfc-editor.org/info/rfc7152>.

7.2.  Informative References

   [IEEE802.1Q] IEEE802.1, "Media IEEE, "IEEE Standard for Local and metropolitan area
                networks -- Media Access Control (MAC) Bridges and
                Virtual Bridged Local Area", IEEE802.1Q, 2011

   [1588] IEEE 1588, "Precision Time Protocol", Std 802.1Q, 2011.

   [IEEE1588]   IEEE, "IEEE Standard for a Precision Clock
                Synchronization Protocol for Networked Measurement and
                Control Systems", IEEE Std 1588, 2013 July 2008.

   [LTE]     3GPP TS,        3GPP, "Evolved Universal Terrestrial Radio Access (E-
             UTRA)
                (E-UTRA) and Evolved Universal Terrestrial Radio Access
                Network (E-UTRAN)", V11.2.0, June, 2012 3GPP TS 36.300 v11.2.0, July 2012.

   [TR-101]     Broadband Forum, "Migration to Ethernet-Based Broadband
             Aggregation
                Aggregation", TR-101 Issue 2", 2, July 2011 2011.

   [VPMS]       Kamite, et al., Y., Jounay, F., Niven-Jenkins, B., Brungard, D.,
                and L. Jin, "Framework and Requirements for Virtual
                Private Multicast Service (VPMS)", draft-ietf-l2vpn-vpms-
             frmwk-requirements-05, work Work in progress Progress,
                draft-ietf-l2vpn-vpms-frmwk-requirements-05,
                October 2012.

   [EVPN]       Sajassi, et al., A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
                and J. Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-
             l2vpn-evpn-07, work Work in progress

9. Contributing Authors
                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 contribute the document as co-authors. contributed significantly to this document.

   Yuji Kamite
   NTT Communications Corporation
   Granpark Tower
   3-4-1 Shibaura, Minato-ku
   Tokyo 108-8118, Japan
   Email:

   EMail: y.kamite@ntt.com

   Wim Henderickx
   Alcatel-Lucent
   Copernicuslaan 50
   2018 Antwerp, Belgium
   Email:

   EMail: wim.henderickx@alcatel-lucent.com

10. Acknowledgments

   Authors like to thank Nabil Bitar for this detail review and
   suggestions.

Authors' Addresses

   Raymond Key (editor)

   Email:

   EMail: raymond.key@ieee.org

   Lucy Yong (editor)
   Huawei USA

   Email:

   EMail: lucy.yong@huawei.com

   Simon Delord
   Telstra

   Email:

   EMail: simon.delord@gmail.com

   Frederic Jounay
   Orange CH
   4 rue caudray 1020 Renens
   Switzerland

   Email:

   EMail: frederic.jounay@orange.ch

   Lizhong Jin

   Email:

   EMail: lizho.jin@gmail.com