Skip to main content

A Framework for E-Tree Service over MPLS Network
draft-ietf-l2vpn-etree-frwk-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7387.
Expired & archived
Authors Simon DeLord , Frederic JOUNAY , Lucy Yong , Lizhong Jin , Yuji Kamite , Wim Henderickx
Last updated 2013-01-31 (Latest revision 2012-07-30)
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 7387 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-l2vpn-etree-frwk-01
Network Working Group                       Raymond Key (editor), Huawei
Internet Draft                              Simon Delord, Alcatel-Lucent
Category: Informational                       Frederic Jounay, Orange CH
Expires: January 2013                                  Lucy Yong, Huawei
                                                        Lizhong Jin, ZTE
                                         Yuji Kamite, NTT Communications
                                          Wim Henderickx, Alcatel-Lucent

                                                           July 30, 2012

            A Framework for E-Tree Service over MPLS Network
                     draft-ietf-l2vpn-etree-frwk-01

Status of this Memo 
 
   This Internet-Draft is submitted to IETF in full conformance with the 
   provisions of BCP 78 and BCP 79. 
 
   Internet-Drafts are working documents 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 of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time.  It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 
 
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt. 
 
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
 
   This Internet-Draft will expire on January 30, 2013. 

Abstract
    
   This document proposes a solution framework for supporting Metro 
   Ethernet Forum (MEF) Ethernet Tree (E-Tree) services 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.

Key, et al.               Expires January 2013                [Page 1]
Internet Draft         Framework E-Tree over MPLS              July 2012

Table of Contents
   
   1. Introduction....................................................3
   1.1. Objective and Scope...........................................3
   1.2. Traditional Ethernet Network..................................3
   1.3. MEF Multipoint Ethernet Services..............................3
   1.3.1. Similarity between E-LAN and E-Tree.........................4
   1.3.2. Difference between E-LAN and E-Tree.........................4
   1.4. IETF Multipoint L2VPN Services................................5
   1.4.1. Virtual Private LAN Service (VPLS)..........................5
   1.4.2. Virtual Private Multicast Service (VPMS)....................5
   1.4.3. Ethernet VPN (E-VPN)........................................6
   1.5. Terminology...................................................6
   2. Reference Model.................................................6
   3. Use Cases.......................................................8
   4. Challenges......................................................9
   4.1. Generic E-Tree Service Definition.............................9
   4.1.1. Mandatory Leaf-to-Leaf Communication Restriction............9
   4.2. Use Case Desirable Requirements..............................10
   4.2.1. Ethernet Broadcast/Multicast Optimisation..................10
   4.2.2. IP Multicast Optimisation..................................11
   4.2.3. MAC-based Forwarding Unnecessary...........................11
   4.2.4. MAC-based Forwarding Security Concern......................12
   5. A Solution Framework for MAC-based Forwarding E-Tree...........12
   5.1. VPLS Solution................................................12
   5.1.1. MAC-based Forwarding Any-to-Any Ethernet VPN...............12
   5.1.2. Leaf-to-Leaf Communication Restriction.....................13
   5.1.3. Optional Enhancement - Point-to-Multipoint PW..............13
   5.1.4. Optional Enhancement - IP Multicast in VPLS........ .......14
   5.2. E-VPN Solution...............................................14
   6. Non-MAC-based Forwarding E-Tree................................14
   6.1. Single Root, Broadcast Only - VPMS...........................14
   6.2. Multiple Roots, Broadcast and Unicast........................14
   6.3. E-VPN Solution...............................................15
   7. Security Consideration.........................................15
   8. IANA Considerations............................................15
   9. Acknowledgements...............................................15
   10. References....................................................15
   10.1. Normative References........................................15
   10.2. Informative References......................................16
   Appendix A. Some Possible Ways for Leaf-to-Leaf Communication
               Restriction...........................................18
   Authors' Addresses................................................28
   Intellectual Property and Copyright Statements....................29

Conventions used in this document 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in [RFC2119]. 

Key, et al.               Expires January 2013                [Page 2]
Internet Draft         Framework E-Tree over MPLS              July 2012

1. Introduction 

1.1. Objective and Scope

   This document proposes a solution framework for supporting Metro 
   Ethernet Forum (MEF) Ethernet Tree (E-Tree) services over a 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 solution framework makes use of existing IETF specified 
   mechanisms unless there are technical reasons why the existing 
   mechanisms are insufficient or unnecessary.

   This document does not intend to provide a full specification of the 
   solution, but rather to identify the functional components of the 
   overall solution, and for each component, whether it is REQUIRED or 
   OPTIONAL, whether existing mechanism is sufficient, or whether 
   relevant mechanism is already under development.

   In this document, "current standard" refers to [RFC4385], [RFC4447], 
   [RFC4448], [RFC4761] and [RFC4762].

1.2. Traditional Ethernet Network

   In this document, traditional Ethernet network refers to the Ethernet 
   bridge/switch network, not the Ethernet repeater/hub network.

   Data frame is Ethernet frame.

   Data forwarding is MAC-based forwarding, which includes MAC address 
   learning and aging.

   It is important to note that in traditional Ethernet network unicast 
   unknown, multicast and broadcast frames are forwarded in exactly the 
   same way to every port except the ingress port.

   An Ethernet host receiving a frame checks the destination address in 
   the frame to decide whether it is the intended destination. 

1.3. MEF Multipoint Ethernet Services

   MEF defines two multipoint Ethernet Service types:
     - E-LAN (Ethernet LAN), multipoint-to-multipoint service
     - E-Tree (Ethernet Tree), rooted-multipoint service

   According to MEF's technical specification, a generic E-LAN/E-Tree 
   service is always bidirectional in the sense that ingress frames can 
   originate at any endpoint in the service. However, some application 
   scenarios of E-Tree may have unidirectional traffic only. Section 3 
   will discuss about different use cases.

Key, et al.               Expires January 2013                [Page 3]
Internet Draft         Framework E-Tree over MPLS              July 2012

   For full specification, please refer to MEF's "Ethernet Services 
   Definitions - Phase 2" [MEF6.1] and "Ethernet Services Attributes 
   Phase 2" [MEF10.2].

1.3.1. Similarity between E-LAN and E-Tree

   Data frame is Ethernet frame.

   Data forwarding can be MAC-based forwarding or something else, to be 
   specified by service provider in the particular service definition.

   Extract from [MEF6.1] Table 7 and Table 9:
   +---------------+---------------------------------------------------+
   | EVC Service   | E-LAN/E-Tree Service Type Requirement             |
   | Attribute     |                                                   |
   +---------------+---------------------------------------------------+
   | Unicast       | Deliver Unconditionally or Deliver Conditionally. |
   | Service Frame | If Delivered Conditionally, MUST specify the      |
   | Delivery      | delivery criteria.                                |
   +---------------+---------------------------------------------------+
   | Multicast     | Deliver Unconditionally or Deliver Conditionally. |
   | Service Frame | If Delivered Conditionally, MUST specify the      |
   | Delivery      | delivery criteria.                                |
   +---------------+---------------------------------------------------+
   | Broadcast     | Deliver Unconditionally or Deliver Conditionally. |
   | Service Frame | If Delivered Conditionally, MUST specify the      |
   | Delivery      | delivery criteria.                                |
   +---------------+---------------------------------------------------+

   It is important to note that it is not a must for a MEF multipoint 
   Ethernet service (E-LAN or E-Tree) to use MAC-based forwarding. This 
   document presents a solution framework for MAC-based forwarding 
   E-Tree in section 5, and also discusses non-MAC-based forwarding 
   E-Tree in section 6.

1.3.2. Difference between E-LAN and E-Tree

   Within the context of a multipoint Ethernet service, each endpoint is 
   designated as either a Root or a Leaf. A Root can communicate with 
   all other endpoints in the same multipoint Ethernet service, however 
   a Leaf can only communicate with Roots but not Leafs.

   The only difference between E-LAN and E-Tree is:
     - E-LAN has Root endpoints only, which implies there is no 
       communication restriction between endpoints 
     - E-Tree has both Root and Leaf endpoints, which implies there is a 
       need to enforce communication restriction between Leaf endpoints

   Extract from [MEF10.2] Section 6.3:
   The UNI Type MUST have the value either "Root" or "Leaf." If the type 
   of EVC is Point-to-Point or Multipoint-to-Multipoint, then the UNI 
   Type MUST equal "Root."

Key, et al.               Expires January 2013                [Page 4]
Internet Draft         Framework E-Tree over MPLS              July 2012

   Extract from [MEF10.2] Section 6.1.2.2:
   An ingress Service Frame mapped to the EVC at a Leaf UNI MUST NOT 
   result in an egress Service Frame at another Leaf UNI but MAY result 
   in an egress Service Frame at some or all of the Root UNIs.

   It is important to note that one E-Tree service may have single or 
   multiple Root UNIs.

   Extract from [MEF6.1] Section 6.3:
   In its simplest form, an E-Tree Service type can provide a single 
   Root for multiple Leaf UNIs. Each Leaf UNI can exchange data with 
   only the Root UNI. ... In more sophisticated forms, an E-Tree Service 
   type may support two or more Root UNIs. In this scenario, each Leaf 
   UNI can exchange data only with the Root UNIs. As well, the Roots can 
   communicate with each other. In such a service, redundant access to 
   the Root can also be provided, effectively allowing for enhanced 
   service reliability and flexibility.

1.4. IETF Multipoint L2VPN Services

1.4.1. Virtual Private LAN Service (VPLS)

   VPLS is a L2VPN service that provides multipoint-to-multipoint 
   connectivity for Ethernet across an IP or MPLS-enabled IP Packet 
   Switched Network. VPLS emulates the Ethernet VLAN functionality of 
   traditional Ethernet network.

   VPLS is a current IETF standard, please refer to [RFC4761] [RFC4762].

   Data frame is Ethernet frame. 

   Data forwarding is MAC-based forwarding, which includes MAC address 
   learning and aging.

   It is important to note that the current standard VPLS treats 
   Ethernet multicast frame in exactly the same way as Ethernet 
   broadcast frame and does not restrict transmission of Ethernet 
   multicast frame to a smaller set of receivers. An Ethernet host 
   receiving a frame checks the destination address in the frame to 
   determine whether it is the intended destination.

   VPLS can be used to emulate E-LAN service over MPLS network provided 
   that the E-LAN service uses MAC-based forwarding as service frame 
   delivery attribute. Considerable number of service providers have 
   adopted this approach to provide E-LAN services to customers.

1.4.2. Virtual Private Multicast Service (VPMS)

   VPMS is a L2VPN service that provides point-to-multipoint 
   connectivity across a variety of link layers, including Frame Relay, 
   ATM, Ethernet, PPP, etc., across an IP or MPLS-enabled IP Packet 
   Switched Network.

Key, et al.               Expires January 2013                [Page 5]
Internet Draft         Framework E-Tree over MPLS              July 2012

   In the Ethernet use case, VPMS provides single coverage of receiver 
   membership, i.e. there is no distinct differentiation for multiple 
   multicast groups. Destination address in Ethernet frame is not used 
   in data forwarding.

   VPMS MUST support unidirectional point-to-multipoint traffic from a 
   sender to multiple receivers and MAY support reverse traffic in a 
   point-to-point manner.

   VPMS is currently under development. Please refer to [Draft VPMS 
   Frmwk].

1.4.3. Ethernet VPN (E-VPN)

   E-VPN is an enhanced Layer-2 service that emulates an Ethernet (V)LAN
   across a PSN, primarily targeted to support large-scale L2VPNs with
   resiliency requirements not satisfied by other L2VPN solutions.

   E-VPN is currently under development. Please refer to [Draft EVPN 
   Req] [Draft BGP EVPN].

1.5. Terminology

   E-Tree

   An Ethernet VPN in which each Root AC can communicate with every 
   other AC, whereas Leaf ACs can only communicate with Root ACs. Each 
   AC on an E-Tree construct is designated as either a Root AC or a Leaf 
   AC. There can be multiple Root ACs and Leaf ACs per E-Tree construct.

   Root AC

   An ingress frame at a Root AC can be delivered to one or more of 
   any of the other ACs in the E-Tree. Please note that this AC is 
   bidirectional.

   Leaf AC

   Ingress frame at a Leaf AC can only be delivered to one or more Root
   ACs in the E-Tree. Ingress frame at a Leaf AC MUST NOT be delivered
   to any Leaf ACs in the E-Tree. Please note that this AC is 
   bidirectional.

2. Reference Model

   Figure 1 below describes a generic reference model where PE1, PE2 and 
   PE3 need to establish an E-Tree construct between different Ethernet 
   endpoints. Each PE has 2 Root ACs and 2 Leaf ACs connected to a VSI. 
   These VSIs are then linked together via Ethernet PWs.

   In most use cases, an E-Tree construct has only a few Root ACs but 
   many Leaf ACs. There may be only Root ACs or only Leaf ACs on a PE.

Key, et al.               Expires January 2013                [Page 6]
Internet Draft         Framework E-Tree over MPLS              July 2012

                     <------------E-Tree------------>
                    +---------+            +---------+
                    |   PE1   |            |   PE2   |
   +----+           |  +---+  |            |  +---+  |           +----+
   |CE01+----AC1----+--+   |  |            |  |   +--+----AC5----+CE05|
   +----+ (Root AC) |  | V |  |            |  | V |  | (Root AC) +----+
   +----+           |  |   |  |            |  |   |  |           +----+
   |CE02+----AC2----+--+   |  |  Ethernet  |  |   +--+----AC6----+CE06|
   +----+ (Root AC) |  | S +--+-----PW-----+--+ S |  | (Root AC) +----+
   +----+           |  |   |  |            |  |   |  |           +----+
   |CE03+----AC3----+--+   |  |            |  |   +--+----AC7----+CE07|
   +----+ (Leaf AC) |  | I |  |            |  | I |  | (Leaf AC) +----+
   +----+           |  |   |  |            |  |   |  |           +----+
   |CE04+----AC4----+--+   |  |            |  |   +--+----AC8----+CE08|
   +----+ (Leaf AC) |  +-+-+  |            |  +-+-+  | (Leaf AC) +----+ 
                    |    |    |            |    |    |
                    +----+----+            +----+----+
                         |                      |
                         |Ethernet              |Ethernet
                         |PW                    |PW
                         |                      |
                         |                 +----+----+
                         |                 |    |    |
                         |                 |  +-+-+  |           +----+
                         |                 |  |   +--+----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 Reference Model

   With an E-Tree construct:
     - A Root AC can receive from and transmit to any other ACs.
     - A Leaf AC can receive from and transmit to any Root ACs.
     - A Leaf AC cannot receive from and transmit to any other Leaf ACs.

   This applies to all traffic, including Unicast Known, Unicast 
   Unknown, Broadcast and Multicast.  

   When an Ethernet Frame is received on PE1 via AC1, the frame can be 
   transmitted to any other local ACs on PE1 and via Ethernet PWs to any 
   remote ACs on PE2 and PE3.

Key, et al.               Expires January 2013                [Page 7]
Internet Draft         Framework E-Tree over MPLS              July 2012

   However when an Ethernet frame is received on PE1 via AC3, the frame 
   can be transmitted to any other local Root ACs on PE1 and via 
   Ethernet PWs to any remote Root ACs on PE2 and PE3, but the frame 
   cannot be transmitted to any local Leaf ACs on PE1 nor any remote 
   Leaf ACs on PE2 and PE3.

3. Use Cases

   Table 1 below presents some major use cases.

       +---------------------------+--------------+------------+
       | Use Case                  | Root         | Leaf       |
   +---+---------------------------+--------------+------------+
   | 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           | PTP Server   | PTP Client |
   |   | Clock Synchronisation     |              |            |
   +---+---------------------------+--------------+------------+
   | 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     |
   +---+---------------------------+--------------+------------+

                     Table 1: E-Tree Use cases

   Common to all use cases, direct Layer 2 Leaf-to-Leaf communication is 
   not required. For Mobile backhaul, this may not be valid for LTE X2 
   interfaces in the future.

   If direct Layer 2 Leaf-to-Leaf communication is not allowed due to 
   security concern, then E-Tree should be used to prohibit 
   communication between Leaf endpoints, otherwise E-LAN is also a 
   feasible option.

   Also common to the use cases mentioned above, there may be single or 
   multiple Root endpoints in one E-Tree service. The need for multiple 
   Root endpoints is usually driven by redundancy requirement. Whether 
   a particular E-Tree service needs to support single or multiple Root 
   endpoints depends on the target application.

Key, et al.               Expires January 2013                [Page 8]
Internet Draft         Framework E-Tree over MPLS              July 2012

   A generic E-Tree service supports all the following traffic flows: 
     - Ethernet Unicast from Root to Leaf
     - Ethernet Unicast from Leaf to Root
     - Ethernet Unicast from Root to Root
     - Ethernet Broadcast/Multicast from Root to Roots & Leafs
     - Ethernet Broadcast/Multicast from Leaf to Roots
   A particular E-Tree service may need to support all the above or only 
   a subset depending on the target application.

   Among the use cases mentioned above, broadcast video draws most 
   attention. Actually, broadcast video is a representing example for 
   content delivery in general, such as news feed, financial data 
   feed, etc.

4. Challenges

4.1. Generic E-Tree Service Definition

   This section highlights why the current standard VPLS is insufficient 
   for emulating E-Tree service over MPLS network.

4.1.1. Mandatory Leaf-to-Leaf Communication Restriction

   Current standard VPLS treats all ACs equal (i.e. not classified into 
   Root or Leaf) and provides any-to-any connectivity among all ACs. The 
   current standard VPLS does not include any mechanism of communication 
   restriction between specific ACs, therefore is insufficient for 
   emulating generic E-Tree service over MPLS network.

   A problem occurs when there are two or more PEs with both Root AC and 
   Leaf AC. 

   Let's look at the scenario illustrated in Figure 2 below. VPLS is 
   used to emulate an E-Tree service over a MPLS network.

   Note: Figure 2 is a hypothetical case solely for explaining the 
   problem, and not meant to represent a typical E-Tree service.

                     <------------E-Tree------------>
                    +---------+            +---------+
                    |   PE1   |            |   PE2   |
   +---+            |  +---+  |            |  +---+  |            +---+
   |CE1+-----AC1----+--+   |  |            |  |   +--+----AC3-----+CE3|
   +---+  (Root AC) |  | V |  |  Ethernet  |  | V |  | (Root AC)  +---+
                    |  | S +--+-----PW-----+--+ S |  |
   +---+            |  | I |  |            |  | I |  |            +---+
   |CE2+-----AC2----+--+   |  |            |  |   +--+----AC4-----+CE4|
   +---+  (Leaf AC) |  +---+  |            |  +---+  | (Leaf AC)  +---+
                    +---------+            +---------+

   Figure 2: Problem Scenario for Leaf-to-Leaf Communication Restriction

Key, et al.               Expires January 2013                [Page 9]
Internet Draft         Framework E-Tree over MPLS              July 2012

   When PE2 receives a frame from PE1 via the Ethernet PW, 
     - PE2 does not know which AC on PE1 is the ingress AC
     - PE2 does not know whether the ingress AC is a Leaf AC or not
     - PE2 does not have sufficient information to enforce the 
       Leaf-to-Leaf communication restriction

   Examples:
     - CE2 sends a Broadcast/Multicast frame to PE1 via AC2
     - CE2 sends a Unicast frame to PE1 via AC2, destination address in 
       Ethernet header equal to CE4's MAC address 

   In order to fulfil the generic E-Tree service definition, extension 
   to the current VPLS standard will be required. Extension to related 
   PWE3 standard may also be required, depending on solution approach. 
   Such extensions should have minimal impact on the emulated E-LAN 
   services already in operation.

   There are some possible ways to get around this problem that do not 
   require extension to the current VPLS standard but they all come with 
   significant design complexity or deployment constraints. Appendix A 
   highlights the major ones and the related concerns.

4.2. Use Case Desirable Requirements

   There are quite a variety of use cases for E-Tree. For some use 
   cases, the generic MEF E-Tree service definition is good enough. For 
   some other use cases, there are desirable requirements beyond that.

   The challenges discussed in this section are not related to the 
   generic MEF E-Tree service definition but the desirable requirements
   of specific use cases. They may be critical to the success in some
   E-Tree services while totally irrelevant in some others.

4.2.1. Ethernet Broadcast/Multicast Optimisation

   According to MAC-based forwarding, an Ethernet broadcast/multicast/
   unicast unknown frame is forwarded to all ACs other than the ingress
   AC, which implies point-to-multipoint traffic from the ingress PE to
   all other PEs in the VPLS instance.

   The current standard VPLS uses only point-to-point PW between PEs.
   When the Ethernet destination address is broadcast, multicast or
   unicast unknown, the ingress PE replicates the frame on every PW
   towards remote PE belonging to the same VPLS instance. Depending on
   the mapping between the logical topology of the E-Tree service and
   the physical topology of the network, multiple PWs may transverse
   same physical link, result in multiple copies of the same payload
   Ethernet frame on the physical link. Such approach is inefficient in
   terms of bandwidth usage.

Key, et al.               Expires January 2013                [Page 10]
Internet Draft         Framework E-Tree over MPLS              July 2012

   For some use cases, for example broadcast/multicast video, due to 
   nature of the application, there is significant volume of point-to- 
   multipoint traffic. Bandwidth optimisation for such traffic within 
   the network becomes a concern from the service provider perspective.

   [RFC5501] provides an in-depth discussion on broadcast/multicast
   related requirements for VPLS, see issue B (Replication of PWs on
   shared physical path) in section 3.2.

4.2.2. IP Multicast Optimisation

   The current standard VPLS is a L2VPN service agnostic to customer's
   Layer 3 traffic, hence does not maintain any information about IP
   multicast group membership. Although a Layer 3 IP multicast packet is
   encapsulated in a Layer 2 Ethernet multicast frame, the current
   standard VPLS treats Ethernet multicast frame in exactly the same way
   as Ethernet broadcast frame. Therefore, such payload IP multicast
   packet will be forwarded to every other AC of the same VPLS instance.

   A payload IP multicast packet will be forwarded to all ACs, including
   those with no member of the specific IP multicast group attached.
   Unnecessary traffic consumes bandwidth on access link and may become
   a concern from the customer perspective. In some cases, it may also
   be a security concern as the multicast frame may be forwarded to an
   endpoint other than the intended destinations.

   A payload IP multicast packet will be forwarded to a remote PE with 
   no member of the specific IP multicast group attached. Unnecessary
   traffic consumes bandwidth in the network and may become a concern
   from the service provider perspective.  

   For some use cases, for example multicast video, due to nature of the
   application, there is significant volume of IP multicast traffic and
   different IP multicast groups are required in one E-Tree service. The
   above may become a real concern from both the customer and service 
   provider perspectives.

   [RFC5501] provides an in-depth discussion on broadcast/multicast
   related requirements for VPLS, see both issue A (Replication to non-
   member site) and issue B (Replication of PWs on shared physical path)
   in section 3.2.

4.2.3. MAC-based Forwarding Unnecessary 

   For some use cases, for example broadcast video, due to nature of the 
   application, there is only broadcast unidirectional traffic from Root 
   to all other endpoints. It is unnecessary to use destination address 
   for data forwarding. Deliver unconditionally for ingress frame at 
   Root endpoint may be a simpler approach than MAC-based forwarding.

Key, et al.               Expires January 2013                [Page 11]
Internet Draft         Framework E-Tree over MPLS              July 2012

4.2.4. MAC-based Forwarding Security Concern

   MAC-based forwarding will make an unicast frame from a Root destined 
   for a specific Leaf being forwarded to other endpoints in addition to 
   the intended destination when the frame is classified as unicast 
   unknown, may be due to MAC address aged out or MAC address table 
   overflow.

   MAC address spoofing may cause an unicast frame from a Root destined 
   for a specific Leaf being forwarded to an endpoint different from the 
   intended destination.

   If such unicast frame carries sensitive information strictly for the 
   intended destination only, then the MAC-based forwarding may cause a 
   security concern from the customer perspective.

   For some use cases where mutually un-trusted subscribers are 
   connected to leaf endpoints in the same E-Tree service, such as
   Internet access and wholesale access, this is a valid concern.

   There are some possible mitigations:
     - For every Leaf endpoint of the particular E-Tree service, deploy 
       a service provider controlled router between the Leaf endpoint 
       and the customer network
     - Customer to deploy encryption for sensitive information, for
       example IPsec, SSL, SSH, HTTPS

   Whether the MAC-based forwarding really becomes a security concern
   depends on the particular application and the deployment scenario.
   This is unlikely to be a critical concern in most cases.

5. A Solution Framework for MAC-based Forwarding E-Tree

   As mentioned in section 1.3.1. E-Tree can use MAC-based forwarding or 
   something else for data forwarding. This section presents a solution 
   framework for MAC-based forwarding E-Tree. Section 6 will discuss 
   other variants.

5.1. VPLS Solution

   This is a VPLS based solution. Functional components of the solution 
   are identified and discussed in the subsections.  

5.1.1. MAC-based Forwarding Any-to-Any Ethernet VPN

   This is a REQUIRED component.

   This component is the current standard VPLS and PWE3 as specified in 
   [RFC4385] [RFC4447] [RFC4448] [RFC4761] [RFC4762], which provides 
   any-to-any connectivity among all ACs in one VPLS instance.

   This is the base component. All other REQUIRED/OPTIONAL components 
   are to be added on top of this component.

Key, et al.               Expires January 2013                [Page 12]
Internet Draft         Framework E-Tree over MPLS              July 2012

5.1.2. Leaf-to-Leaf Communication Restriction

   This is in response to the challenge in section 4.1.1. Mandatory 
   Leaf-to-Leaf Communication Restriction. 

   This is a REQUIRED component.

   This component is a minimal extension to the current VPLS and PWE3 
   standards, with the objective to provide a simple and effective way 
   to support generic E-Tree services in addition to E-LAN services 
   using VPLS on a MPLS network.

   [Draft VPLS ETree Req] is a work in progress requirement draft.

   Different solutions have been proposed:
     - Control Word L-bit solution, [Draft CW L-bit] [Draft VPLS ETree]
     - Dual VLAN solution, [Draft VPLS PE ETree] [Draft VPLS ETree BGP]
     - Multiple PW solution, [Draft VPLS ETree Multi PW]

5.1.3. Optional Enhancement - Point-to-Multipoint PW

   This is in response to the challenge in section 4.2.1. Ethernet
   Broadcast/Multicast Optimisation. 

   This is an OPTIONAL component, applicable only when there is 
   significant volume of Ethernet broadcast/multicast traffic.

   Point-to-Multipoint pseudowire (P2MP PW) is a PW attached to a source 
   used to distribute Layer 1 or Layer 2 format traffic to a set of 
   receivers. P2MP PW is unidirectional but optionally bidirectional.

   By using P2MP PW, the ingress PE is not responsible for replicating 
   the payload frame on each P2P PW towards egress PE, instead the 
   network elements along the physical path participate in replication. 
   The replication is done by the underlying point-to-multipoint label 
   switched path (P2MP LSP).

   Extension to current VPLS standard will be required to specify how 
   P2MP PW and P2P PW should be used and how MAC learning works on P2MP 
   PW. Please refer to [Draft LDP-VPLS Bcast].

   P2MP PW is currently under development. Please refer to [Draft P2MP 
   PW Req] [Draft P2MP PW Sig].

   It is important to note that this component will align with the
   recommendation in [RFC4665],
   "With the exception of IPLS, an L2VPN service SHOULD be agnostic to
   customer's Layer 3 traffic (e.g., IP, IPX, Appletalk) encapsulated
   within Layer 2 frames."

Key, et al.               Expires January 2013                [Page 13]
Internet Draft         Framework E-Tree over MPLS              July 2012

5.1.4. Optional Enhancement - IP Multicast in VPLS

   This is in response to the challenge in section 4.2.2. IP Multicast
   Optimisation.

   This is an OPTIONAL component, applicable only when there is 
   significant volume of IP multicast traffic and different IP multicast
   groups are required in one E-Tree service.

   Multicast in VPLS is currently under development, with the objective
   to provide efficient ways to support IP multicast services over VPLS.
   It covers IP multicast group membership control and also bandwidth
   optimisation. Please refer to [Draft Mcast VPLS].

   It is important to note that this component will make use of Layer 3
   IP multicast information in payload frames to improve transport
   efficiency, hence will not align with the recommendation in [RFC4665]
   that an L2VPN service SHOULD be agnostic to customer's Layer 3
   traffic.

5.2. E-VPN Solution

   A E-VPN based solution has been proposed. Please refer to [Draft EVPN
   ETree].

6. Non-MAC-based Forwarding E-Tree

   This section presents some variants of E-Tree services which do not 
   use MAC-based forwarding as the service frame delivery attribute.

6.1. Single Root, Broadcast Only - VPMS

   This is in response to the challenge in section 4.2.3. MAC-based 
   Forwarding Unnecessary.

   VPMS provides single coverage of receiver membership. Destination 
   address in Ethernet frame is not used in data forwarding.

   For E-Tree service of single Root and only unidirectional broadcast 
   traffic from the Root, for example certain broadcast video or similar 
   content delivery applications, VPMS will be a much more simple and 
   effective solution than VPLS.

   VPMS is currently under development. Please refer to [Draft VPMS 
   Frmwk].

6.2. Multiple Roots, Broadcast and Unicast

   This is in response to the challenge in section 4.2.4. MAC-based 
   Forwarding Security Concern. 

   This will be added in later version of this document.

Key, et al.               Expires January 2013                [Page 14]
Internet Draft         Framework E-Tree over MPLS              July 2012

6.3. E-VPN Solution

   A E-VPN based solution has been proposed. Please refer to [Draft EVPN
   ETree].

7. Security Considerations 
    
   This will be added in later version of this document.

8. IANA Considerations 
    
   This will be added in later version of this document.
    
9. Acknowledgements 
    
   This will be added in later version of this document.

10. References    

10.1. Normative References
    
   [MEF6.1]     Metro Ethernet Forum, Ethernet Services Definitions - 
                Phase 2, April 2008
   
   [MEF10.2]    Metro Ethernet Forum, Ethernet Services Attributes 
                Phase 2, October 2009

   [RFC2119]    Bradner, S., Key words for use in RFCs to Indicate 
                Requirement Levels, BCP 14, RFC 2119, March 1997
   
   [RFC4385]    Bryant,S., Swallow, G., and Al, Pseudowire Emulation 
                Edge-to-Edge (PWE3) Control Word for Use over an MPLS
                PSN, February 2006.

   [RFC4447]    Martini, L., and al, Pseudowire Setup and Maintenance
                Using the Label Distribution Protocol (LDP), April 2006 
    
   [RFC4448]    Martini, L., and al, Encapsulation Methods for 
                Transport of Ethernet over MPLS Networks, April 2006

   [RFC4665]    Augustyn & Serbest, Service Requirements for Layer 2
                Provider-Provisioned Virtual Private Networks,
                September 2006

   [RFC4761]    Kompella & Rekhter, Virtual Private LAN Service (VPLS) 
                Using BGP for Auto-Discovery and Signaling, January 2007 
    
   [RFC4762]    Lasserre & Kompella, Virtual Private LAN Service (VPLS)
                Using Label Distribution Protocol (LDP) Signaling, 
                January 2007

   [RFC5501]    Kamite, et al., Requirements for Multicast Support in 
                Virtual Private LAN Services, March 2009

Key, et al.               Expires January 2013                [Page 15]
Internet Draft         Framework E-Tree over MPLS              July 2012

10.2. Informative References

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

   [Draft VPLS ETree Req]
                Key, et al., Requirements for MEF E-Tree Support in 
                VPLS, draft-ietf-l2vpn-etree-reqt-01 (work in progress),
                April 2012

   [Draft CW L-bit] 
                Delord, et al., Control Word Reserved bit for use in 
                E-Tree, draft-delord-pwe3-cw-bit-etree-07 (work in 
                progress), April 2012 

   [Draft VPLS ETree]
                Key, et al., Extension to VPLS for E-Tree,
                draft-key-l2vpn-vpls-etree-07 (work in progress), 
                April 2012 

   [Draft VPLS PE ETree]
                Jiang, et al., VPLS PE Model for E-Tree Support,
                draft-jiang-l2vpn-vpls-pe-etree-06 (work in progress),
                June 2012

   [Draft VPLS ETree BGP]
                Jiang, et al., E-Tree Support in VPLS with BGP 
                Signaling, draft-jiang-l2vpn-etree-bgp-00 
                (work in progress), February 2012

   [Draft VPLS ETree Multi PW]
                Ram, et al., Extension to VPLS for E-Tree Using Multiple
                PWs, draft-ram-l2vpn-etree-multiple-pw-01 (work in 
                progress), March 2012

   [Draft P2MP PW Req]
                Jounay, et al., Requirements for Point-to-Multipoint 
                Pseudowire, draft-ietf-pwe3-p2mp-pw-requirements-05
                (work in progress), September 2011   

   [Draft P2MP PW Sig]
                Sivabalan, et al., Signaling Root-Initiated Point-to-
                Multipoint Pseudowires using LDP,
                draft-ietf-pwe3-p2mp-pw-04 (work in progress),
                March 2012

   [Draft LDP-VPLS Bcast]
                Delord, et al., Extension to LDP-VPLS for Ethernet 
                Broadcast and Multicast, 
                draft-ietf-l2vpn-ldp-vpls-broadcast-exten-04 (work in 
                progress), July 2012

Key, et al.               Expires January 2013                [Page 16]
Internet Draft         Framework E-Tree over MPLS              July 2012

   [Draft Mcast VPLS]
                Raggarwa, Kamite & Fang, Multicast in VPLS,
                draft-ietf-l2vpn-vpls-mcast-11 (work in progress),
                July 2012 

   [Draft VPMS Frmwk]
                Kamite, et al., Framework and Requirements for Virtual
                Virtual Private Multicast Service (VPMS),
                draft-ietf-l2vpn-vpms-frmwk-requirements-04 (work in 
                progress), July 2011

   [Draft EVPN Req]
                Sajassi, Aggarwal, et al., Requirements for Ethernet VPN
                (E-VPN), draft-ietf-l2vpn-evpn-req-00 (work in
                progress), March 2012

   [Draft BGP EVPN]
                Sajassi, Aggarwal, et al., BGP MPLS Based Ethernet VPN,
                draft-ietf-l2vpn-evpn-01 (work in progress), July 2012

   [Draft EVPN ETree]
                Sajassi, et al., E-TREE Support in E-VPN,
                draft-ietf-l2vpn-evpn-etree-00 (work in progress), 
                June 2012 

Key, et al.               Expires January 2013                [Page 17]
Internet Draft         Framework E-Tree over MPLS              July 2012

Appendix A. Some Possible Ways for Leaf-to-Leaf Communication
            Restriction 

   This appendix briefly describes the following approaches:
   - Single Root Only (A.1)
   - Only one PE has Roots (A.2)
   - Only one PE with both Root & Leaf
     - Backhaul Root (A.3)
     - Backhaul Leaf (A.4)
     - H-VPLS Root (A.5)
     - H-VPLS Leaf (A.6)
   - Separate PEs for Root and Leaf (A.7)
   - Separate VSI for Root and Leaf
     - Internal Connection (A.8)
     - External Connection (A.9)
   - Separate PWs for "From Root" traffic and "From Leaf" traffic (A.10)
   - "From Root" or "From Leaf" derived from source MAC address (A.11)
   - Static MAC address configuration for Root AC (A.12)

   Reference Model for Leaf-to-Leaf Communication Restriction

                     <------------E-Tree------------>
                    +---------+            +---------+
                    |   PE1   |            |   PE2   |
   +----+           |  +---+  |            |  +---+  |           +----+
   |CE01+----AC1----+--+   |  |            |  |   +--+----AC5----+CE05|
   +----+ (Root AC) |  | V |  |            |  | V |  | (Root AC) +----+
   +----+           |  |   |  |            |  |   |  |           +----+
   |CE02+----AC2----+--+   |  |  Ethernet  |  |   +--+----AC6----+CE06|
   +----+ (Root AC) |  | S +--+-----PW-----+--+ S |  | (Root AC) +----+
   +----+           |  |   |  |            |  |   |  |           +----+
   |CE03+----AC3----+--+   |  |            |  |   +--+----AC7----+CE07|
   +----+ (Leaf AC) |  | I |  |            |  | I |  | (Leaf AC) +----+
   +----+           |  |   |  |            |  |   |  |           +----+
   |CE04+----AC4----+--+   |  |            |  |   +--+----AC8----+CE08|
   +----+ (Leaf AC) |  +---+  |            |  +---+  | (Leaf AC) +----+
                    |         |            |         |
                    +---------+            +---------+

   For the diagrams in this appendix, "L" indicates the particular AC or
   PW belonging to the PE local split horizon group specifically for
   Leaf-to-Leaf Communication Restriction. No communication is allowed
   between any two members of a split horizon group.

Key, et al.               Expires January 2013                [Page 18]
Internet Draft         Framework E-Tree over MPLS              July 2012

A.1. Single Root Only

                     <------------E-Tree------------>
                    +---------+            +---------+
                    |   PE1   |            |   PE2   |
   +----+           |  +---+  |            |  +---+  |
   |CE01+----AC1----+--+   |  |            |  |   |  |
   +----+ (Root AC) |  | V |  |            |  | V |  |
                    |  |   |  |            |  |   |  |
                    |  |   |  |  Ethernet  |  |   |  |
                    |  | S +L-+-----PW-----+--+ S |  |
   +----+           |  |   |  |            |  |   |  |           +----+
   |CE03+----AC3----+-L+   |  |            |  |   +L-+----AC7----+CE07|
   +----+ (Leaf AC) |  | I |  |            |  | I |  | (Leaf AC) +----+
   +----+           |  |   |  |            |  |   |  |           +----+
   |CE04+----AC4----+-L+   |  |            |  |   +L-+----AC8----+CE08|
   +----+ (Leaf AC) |  +---+  |            |  +---+  | (Leaf AC) +----+
                    |         |            |         |
                    +---------+            +---------+

   Concerns:
   - Not fulfil multi-Root requirement of generic MEF E-Tree service
     definition

A.2. Only one PE has Roots

                     <------------E-Tree------------>
                    +---------+            +---------+
                    |   PE1   |            |   PE2   |
   +----+           |  +---+  |            |  +---+  |
   |CE01+----AC1----+--+   |  |            |  |   |  |
   +----+ (Root AC) |  | V |  |            |  | V |  |
   +----+           |  |   |  |            |  |   |  |
   |CE02+----AC2----+--+   |  |  Ethernet  |  |   |  |
   +----+ (Root AC) |  | S +L-+-----PW-----+--+ S |  |
   +----+           |  |   |  |            |  |   |  |           +----+
   |CE03+----AC3----+-L+   |  |            |  |   +L-+----AC7----+CE07|
   +----+ (Leaf AC) |  | I |  |            |  | I |  | (Leaf AC) +----+
   +----+           |  |   |  |            |  |   |  |           +----+
   |CE04+----AC4----+-L+   |  |            |  |   +L-+----AC8----+CE08|
   +----+ (Leaf AC) |  +---+  |            |  +---+  | (Leaf AC) +----+
                    |         |            |         |
                    +---------+            +---------+

   Concerns:
   - Deployment constraint

Key, et al.               Expires January 2013                [Page 19]
Internet Draft         Framework E-Tree over MPLS              July 2012

A.3. Only one PE with both Root & Leaf - Backhaul Root

                        +---AC5(Root AC)---------------------------+
                        |                                          |
                        | +-AC6(Root AC)----------------------+    |
                        | |                                   |    |
                        | |                                   |    |
                        | |                                   |    |
                    +---+-+---+            +---------+        |    |
                    |   | |   |            |         |        |    |
   +----+           |  ++-++  |            |  +---+  |        |  +-+--+
   |CE01+----AC1----+--+   |  |            |  |   |  |        |  |CE05|
   +----+ (Root AC) |  | V |  |            |  | V |  |        |  +----+
   +----+           |  |   |  |            |  |   |  |        |  +----+
   |CE02+----AC2----+--+   |  |  Ethernet  |  |   |  |        +--+CE06|
   +----+ (Root AC) |  | S +L-+-----PW-----+--+ S |  |           +----+
   +----+           |  |   |  |            |  |   |  |           +----+
   |CE03+----AC3----+-L+   |  |            |  |   +L-+----AC7----+CE07|
   +----+ (Leaf AC) |  | I |  |            |  | I |  | (Leaf AC) +----+
   +----+           |  |   |  |            |  |   |  |           +----+
   |CE04+----AC4----+-L+   |  |            |  |   +L-+----AC8----+CE08|
   +----+ (Leaf AC) |  +---+  |            |  +---+  | (Leaf AC) +----+
                    |   PE1   |            |   PE2   |
                    +---------+            +---------+
                     <------------E-Tree------------>

   Concerns:
   - Deployment constraint
   - Long fibre path

Key, et al.               Expires January 2013                [Page 20]
Internet Draft         Framework E-Tree over MPLS              July 2012

A.4. Only one PE with both Root & Leaf - Backhaul Leaf

                     <------------E-Tree------------>
                    +---------+            +---------+
                    |   PE1   |            |   PE2   |
   +----+           |  +---+  |            |  +---+  |           +----+
   |CE01+----AC1----+--+   |  |            |  |   +--+----AC5----+CE05|
   +----+ (Root AC) |  | V |  |            |  | V |  | (Root AC) +----+
   +----+           |  |   |  |            |  |   |  |           +----+
   |CE02+----AC2----+--+   |  |  Ethernet  |  |   +--+----AC6----+CE06|
   +----+ (Root AC) |  | S +--+-----PW-----+--+ S |  | (Root AC) +----+
   +----+           |  |   |  |            |  |   |  |           +----+
   |CE03+----AC3----+-L+   |  |            |  |   |  |        +--+CE07|
   +----+ (Leaf AC) |  | I |  |            |  | I |  |        |  +----+
   +----+           |  |   |  |            |  |   |  |        |  +----+
   |CE04+----AC4----+-L+   |  |            |  |   |  |        |  |CE08|
   +----+ (Leaf AC) |  ++-++  |            |  +---+  |        |  +-+--+
                    |   L L   |            |         |        |    |
                    +---+-+---+            +---------+        |    |
                        | |                                   |    |
                        | |                                   |    |
                        | |                                   |    |
                        | +-AC7(Leaf AC)----------------------+    |
                        |                                          |
                        +---AC8(Leaf AC)---------------------------+

   Concerns:
   - Deployment constraint
   - Long fibre path

Key, et al.               Expires January 2013                [Page 21]
Internet Draft         Framework E-Tree over MPLS              July 2012

A.5. Only one PE with both Root & Leaf - H-VPLS Root

                     <------------E-Tree------------>
                    +---------+            +---------+
                    |   PE1   |            |   PE2   |
   +----+           |  +---+  |  Ethernet  |         |           +----+
   |CE01+----AC1----+--+   +--+-----PW-----+---------+----AC5----+CE05|
   +----+ (Root AC) |  | V |  |            |         | (Root AC) +----+
   +----+           |  |   |  |  Ethernet  |         |           +----+
   |CE02+----AC2----+--+   +--+-----PW-----+---------+----AC6----+CE06|
   +----+ (Root AC) |  | S |  |            |  +---+  | (Root AC) +----+
   +----+           |  |   |  |            |  |   |  |           +----+
   |CE03+----AC3----+-L+   |  |  Ethernet  |  | V +L-+----AC7----+CE07|
   +----+ (Leaf AC) |  | I +L-+-----PW-----+--+ S |  | (Leaf AC) +----+
   +----+           |  |   |  |            |  | I |  |           +----+
   |CE04+----AC4----+-L+   |  |            |  |   +L-+----AC8----+CE08|
   +----+ (Leaf AC) |  +---+  |            |  +---+  | (Leaf AC) +----+
                    |         |            |         |
                    +---------+            +---------+

   Concerns:
   - Design complexity
   - More PW
   - Hair pinning (e.g. CE05 to CE06/07/08) impact bandwidth and delay

A.6. Only one PE with both Root & Leaf - H-VPLS Leaf

                     <------------E-Tree------------>
                    +---------+            +---------+
                    |   PE1   |            |   PE2   |
   +----+           |  +---+  |            |  +---+  |           +----+
   |CE01+----AC1----+--+   |  |            |  |   +--+----AC5----+CE05|
   +----+ (Root AC) |  | V |  |  Ethernet  |  | V |  | (Root AC) +----+
   +----+           |  |   +--+-----PW-----+--+ S |  |           +----+
   |CE02+----AC2----+--+   |  |            |  | I +--+----AC6----+CE06|
   +----+ (Root AC) |  | S |  |            |  |   |  | (Root AC) +----+
   +----+           |  |   |  |  Ethernet  |  +---+  |           +----+
   |CE03+----AC3----+-L+   +L-+-----PW-----+---------+----AC7----+CE07|
   +----+ (Leaf AC) |  | I |  |            |         | (Leaf AC) +----+
   +----+           |  |   |  |  Ethernet  |         |           +----+
   |CE04+----AC4----+-L+   +L-+-----PW-----+---------+----AC8----+CE08|
   +----+ (Leaf AC) |  +---+  |            |         | (Leaf AC) +----+
                    |         |            |         |
                    +---------+            +---------+

   Concerns:
   - Design complexity
   - More PW
   - Hair pinning (e.g. CE08 to CE05/06) impact bandwidth and delay

Key, et al.               Expires January 2013                [Page 22]
Internet Draft         Framework E-Tree over MPLS              July 2012

A.7. Separate PEs for Root and Leaf
     (PE2 split to PE2R & PE2L)

                     <------------E-Tree------------>
                    +---------+            +---------+
                    |   PE1   |            |   PE2R  |
   +----+           |  +---+  |            |  +---+  |           +----+
   |CE01+----AC1----+--+   |  |  Ethernet  |  | V +--+----AC5----+CE05|
   +----+ (Root AC) |  | V +--+-----PW-----+--+ S |  | (Root AC) +----+
   +----+           |  |   |  |            |  | I |  |           +----+
   |CE02+----AC2----+--+   |  |            |  |   +--+----AC6----+CE06|
   +----+ (Root AC) |  | S |  |            |  +-+-+  | (Root AC) +----+
   +----+           |  |   |  |            |    L    |
   |CE03+----AC3----+-L+   |  |            +----+----+
   +----+ (Leaf AC) |  | I |  |                 |
   +----+           |  |   |  |                 |Ethernet
   |CE04+----AC4----+-L+   |  |                 |PW
   +----+ (Leaf AC) |  +-+-+  |                 |
                    |    L    |            +----+----+
                    +----+----+            |    |    |
                         |                 |  +-+-+  |           +----+
                         |       Ethernet  |  | V +L-+----AC7----+CE07|
                         +----------PW-----+--+ S |  | (Leaf AC) +----+
                                           |  | I |  |           +----+
                                           |  |   +L-+----AC8----+CE08|
                                           |  +---+  | (Leaf AC) +----+
                                           |   PE2L  |
                                           +---------+
                     <------------E-Tree------------>

   Concerns:
   - Require two PEs in one POP
   - More PW

Key, et al.               Expires January 2013                [Page 23]
Internet Draft         Framework E-Tree over MPLS              July 2012

A.8. Separate VSI for Root and Leaf - Internal Connection
     (VSI on PE split to VSIR & VSIL)

                     <------------E-Tree------------>
                    +---------+            +---------+
                    |   PE1   |            |   PE2   |
   +----+           |  +---+  |            |  +---+  |           +----+
   |CE01+----AC1----+--+ V |  |            |  | V +--+----AC5----+CE05|
   +----+ (Root AC) |  | S +--+------------+--+ S |  | (Root AC) +----+
   +----+           |  | I |  |            |  | I |  |           +----+
   |CE02+----AC2----+--+ R +L-+--+      +--+-L+ R +--+----AC6----+CE06|
   +----+ (Root AC) |  +-+-+  |  |      |  |  +-+-+  | (Root AC) +----+
                    |    L    |  |      |  |    L    |
                    |    |    |  \      /  |    |    |
                    |    |    |   \    /   |    |    |
                    |    |    |    \  /    |    |    |
                 Internal|    |     \/     |    |Internal
               Connection|    |     /\     |    |Connection
                    |    |    |    /  \    |    |    |
                    |    |    |   /    \   |    |    |
                    |    |    |  /      \  |    |    |
   +----+           |  +-+-+  |  |      |  |  +-+-+  |           +----+
   |CE03+----AC3----+-L+ V |  |  |      |  |  | V +L-+----AC7----+CE07|
   +----+ (Leaf AC) |  | S +--+--+      +--+--+ S |  | (Leaf AC) +----+
   +----+           |  | I |  |            |  | I |  |           +----+
   |CE04+----AC4----+-L+ L |  |   Three    |  | L +L-+----AC8----+CE08|
   +----+ (Leaf AC) |  +-+-+  |  Ethernet  |  +---+  | (Leaf AC) +----+
                    |         |    PWs     |         |
                    +---------+            +---------+

   Concerns:
   - Design complexity
   - More VSI
   - More PW
   - Some vendor implementation may require additional hardware module
     to support internal connection between two VSIs
   - Some vendor implementation may have bandwidth limitation on
     internal connection between two VSIs
   - Some vendor implementation of service-aware management system may
     assume only one VSI per VPLS on one PE

Key, et al.               Expires January 2013                [Page 24]
Internet Draft         Framework E-Tree over MPLS              July 2012

A.9. Separate VSI for Root and Leaf - External Connection
     (VSI on PE split to VSIR & VSIL)

                     <------------E-Tree------------>
                    +---------+            +---------+
                    |   PE1   |            |   PE2   |
   +----+           |  +---+  |            |  +---+  |           +----+
   |CE01+----AC1----+--+ V |  |            |  | V +--+----AC5----+CE05|
   +----+ (Root AC) |  | S +--+------------+--+ S |  | (Root AC) +----+
   +----+           |  | I |  |            |  | I |  |           +----+
   |CE02+----AC2----+--+ R +L-+--+      +--+-L+ R +--+----AC6----+CE06|
   +----+ (Root AC) |  |   |  |  |      |  |  |   |  | (Root AC) +----+
                    |  |   |  |  |      |  |  |   |  |
     +------AC-X1---+-L+   |  |  \      /  |  |   +L-+----AC-X2-----+
     |    (Leaf AC) |  +---+  |   \    /   |  +---+  | (Leaf AC)    |
     |              |         |    \  /    |         |              |
     |External      |         |     \/     |         |      External|
     |Connection    |         |     /\     |         |    Connection|
     |              |  +---+  |    /  \    |  +---+  |              |
     +------AC-Y1---+--+   |  |   /    \   |  |   +--+----AC-Y2-----+
          (Root AC) |  |   |  |  /      \  |  |   |  | (Root AC)
   +----+           |  |   |  |  |      |  |  |   |  |           +----+
   |CE03+----AC3----+-L+ V |  |  |      |  |  | V +L-+----AC7----+CE07|
   +----+ (Leaf AC) |  | S +--+--+      +--+--+ S |  | (Leaf AC) +----+
   +----+           |  | I |  |            |  | I |  |           +----+
   |CE04+----AC4----+-L+ L |  |   Three    |  | L +L-+----AC8----+CE08|
   +----+ (Leaf AC) |  +-+-+  |  Ethernet  |  +---+  | (Leaf AC) +----+
                    |         |    PWs     |         |
                    +---------+            +---------+

   Concerns:
   - Design complexity
   - More VSI
   - More PW
   - More AC (for external connection between two VSIs)
   - Require additional two high speed physical ports on PE to support
     such external connections
   - Some vendor implementation of service-aware management system may
     assume only one VSI per VPLS on one PE

Key, et al.               Expires January 2013                [Page 25]
Internet Draft         Framework E-Tree over MPLS              July 2012

A.10. Separate PWs for "From Root" traffic and "From Leaf" traffic

                     <------------E-Tree------------>
                    +---------+            +---------+
                    |   PE1   |            |   PE2   |
   +----+           |  +---+  |            |  +---+  |           +----+
   |CE01+----AC1----+--+   |  |  Ethernet  |  |   +--+----AC5----+CE05|
   +----+ (Root AC) |  | V +--+---PW for---+--+ V |  | (Root AC) +----+
   +----+           |  |   |  |"From Root" |  |   |  |           +----+
   |CE02+----AC2----+--+   |  |  Traffic   |  |   +--+----AC6----+CE06|
   +----+ (Root AC) |  | S |  |            |  | S |  | (Root AC) +----+
   +----+           |  |   |  |            |  |   |  |           +----+
   |CE03+----AC3----+--+   |  |            |  |   +--+----AC7----+CE07|
   +----+ (Leaf AC) |  | I |  |  Ethernet  |  | I |  | (Leaf AC) +----+
   +----+           |  |   +--+---PW for---+--+   |  |           +----+
   |CE04+----AC4----+--+   |  |"From Leaf" |  |   +--+----AC8----+CE08|
   +----+ (Leaf AC) |  +---+  |  Traffic   |  +---+  | (Leaf AC) +----+
                    |         |            |         |
                    +---------+            +---------+

   Concerns:
   - More PW
   - Most, if not all, vendor implementation support only one PW
     between two VSIs on different PEs
   - Most, if not all, vendor implementation of service-aware management
     system assume only one PW between two VSIs on different PEs
   - Asymmetric path for bidirectional traffic between Root and Leaf on
     different PEs (e.g. CE01-->CE07 use the "From Root" PW, CE07-->CE01
     use the "From Leaf" PW)
   - Require extension to current standard VPLS
     - support two PWs between two VSIs on different PEs (both active
       but no loop)
     - share MAC learning between the "From Root" PW and "From Leaf" PW
       (bidirectional traffic may be on asymmetric path)
     - in addition to standard MAC-based forwarding, select which PW to
       use based on whether ingress AC is Root or Leaf
     - filter Leaf-to-Leaf traffic (split horizon group at PW/AC level
       is not good enough because of asymmetric path)

Key, et al.               Expires January 2013                [Page 26]
Internet Draft         Framework E-Tree over MPLS              July 2012

A.11. "From Root" or "From Leaf" derived from source MAC address

   Based on the current standard VPLS, a PE has no information about ACs
   on another PE.

   This approach will need additional information exchange between
   ingress PE and egress PE, via OSS or peer to peer.

   Concerns:
   - Require system development or additional signaling between PEs
   - Not an ideal solution from security perspective because of the
     dynamic nature of MAC address to AC mapping

A.12. Static MAC address configuration for Root AC

   This approach requires additional configuration on PEs
   - Disable MAC address learning for Root ACs
   - Static configuration of MAC addresses per Root AC
   - Add filtering for each Root AC
     - Drop ingress frame if source MAC address not equal to any of the
       static MAC addresses configured for the particular Root AC
   - Add filtering for each Leaf AC
     - Drop ingress frame if source MAC address equal to any of the
       static MAC addresses configured for any Root ACs of the VPLS
       instance
     - Drop egress frame if source MAC address not equal to any of the
       static MAC addresses configured for any Root ACs of the VPLS
       instance

   Concerns:
   - No MAC address learning capability for Root ACs
   - Need resources for maintaining the static MAC address configuration
     per Root AC

Key, et al.               Expires January 2013                [Page 27]
Internet Draft         Framework E-Tree over MPLS              July 2012

Authors' Addresses 
    
   Raymond Key (editor)
   Huawei
   Email: raymond.key@ieee.org

   Simon Delord
   Alcatel-Lucent
   Email: simon.delord@gmail.com

   Frederic Jounay     
   Orange CH     
   4 rue caudray 1020 Renens     
   Switzerland    
   Email: frederic.jounay@orange.ch

   Lucy Yong
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075, USA
   Email: lucy.yong@huawei.com

   Lizhong Jin
   ZTE Corporation
   889, Bibo Road
   Shanghai, 201203, China
   Email: lizhong.jin@zte.com.cn

   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.               Expires January 2013                [Page 28]
Internet Draft         Framework E-Tree over MPLS              July 2012

Copyright Notice 
    
   Copyright (c) 2012 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.

Key, et al.               Expires January 2013                [Page 29]