Internet Engineering Task Force (IETF)                       R. Key, Ed.
Request for Comments: 7152                                     S. Delord
Category: Informational                                          Telstra
ISSN: 2070-1721                                                F. Jounay
                                                               Orange CH
                                                                L. Huang
                                                            China Mobile
                                                                  Z. Liu
                                                           China Telecom
                                                                 M. Paul
                                                        Deutsche Telekom
                                                              March 2014


   Requirements for Metro Ethernet Forum (MEF) Ethernet-Tree (E-Tree)
           Support in Layer 2 Virtual Private Network (L2VPN)

Abstract

   This document provides functional requirements for the support of
   Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in multipoint Layer
   2 Virtual Private Network solutions (referred to as simply "L2VPN").
   It is intended that potential solutions will use these requirements
   as guidelines.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7152.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction ....................................................3
      1.1. Conventions Used in This Document ..........................3
   2. IETF Multipoint Ethernet L2VPN Services .........................3
      2.1. VPLS .......................................................3
      2.2. Ethernet Virtual Private Network (E-VPN) ...................3
   3. MEF Multipoint Ethernet Services ................................4
      3.1. Similarities between E-LAN and E-Tree ......................4
      3.2. Differences between E-LAN and E-Tree .......................4
      3.3. E-Tree Use Cases ...........................................5
      3.4. Generic E-Tree Service .....................................6
   4. Problem Statement ...............................................6
      4.1. Motivation .................................................6
      4.2. Leaf-to-Leaf Communication Restriction .....................6
   5. Requirements ....................................................7
      5.1. Functional Requirements ....................................7
      5.2. Applicability ..............................................8
      5.3. Backward Compatibility .....................................8
      5.4. External Network Network Interface (ENNI) ..................8
   6. Security Considerations .........................................8
   7. Contributors ....................................................8
   8. Acknowledgements ................................................9
   9. References ......................................................9
      9.1. Normative References .......................................9
      9.2. Informative References ....................................10
   Appendix A. Frequently Asked Question .............................11
   A.1. Are E-Tree Requirements Addressed in the Virtual
        Private Multicast Service (VPMS) Requirements? ...............11

1.  Introduction

   This document provides functional requirements for the support of
   Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in multipoint Layer
   2 Virtual Private Network solutions (referred to as simply "L2VPN").
   It is intended that potential solutions will use these requirements
   as guidelines.

   A considerable number of service providers have adopted Virtual
   Private LAN Service (VPLS) to provide MEF Ethernet LAN (E-LAN)
   services to customers.  Service providers currently need a simple and
   effective solution to emulate E-Tree services in addition to E-LAN
   services on their MPLS networks.

   Service providers also expect E-Tree support in any newly developed
   L2VPN technologies.

1.1.  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].

2.  IETF Multipoint Ethernet L2VPN Services

2.1.  VPLS

   VPLS [RFC4761] [RFC4762] is an L2VPN service that provides
   multipoint-to-multipoint connectivity for Ethernet across an IP or
   MPLS-enabled IP Packet Switched Network (IP/MPLS PSN).  VPLS emulates
   the Ethernet VLAN functionality of traditional Ethernet networks.
   Thus, in VPLS, the customer Ethernet frame is transported over the
   IP/MPLS PSN from the ingress Provider Edge (PE) to the egress PE
   where the destination is connected based on the Ethernet frame
   destination Media Access Control (MAC) address in the context of the
   virtual switching instance (VSI) to which it belongs.

2.2.  Ethernet Virtual Private Network (E-VPN)

   E-VPN is an enhanced L2 service that emulates an Ethernet VLAN across
   an IP/MPLS 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 [EVPN].

3.  MEF Multipoint Ethernet Services

   MEF has defined two multipoint Ethernet service types:

      - E-LAN (Ethernet LAN), multipoint-to-multipoint service
      - E-Tree (Ethernet Tree), rooted-multipoint service

   For the full specifications, please refer to [MEF6.1] and [MEF10.2].

3.1.  Similarities between E-LAN and E-Tree

   The following are the similarities between E-LAN and E-Tree services.

      - Data frame is an Ethernet frame.
      - Data forwarding is MAC-based forwarding.
      - A generic E-LAN/E-Tree service is always bidirectional in the
        sense that ingress frames can originate at any endpoint in the
        service.

3.2.  Differences 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 Leaves.

   The only differences between E-LAN and E-Tree are:

      - 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.

3.3.  E-Tree Use Cases

   Table 1 presents some major E-Tree 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           | Radio Access | RAN Base   |
   |   |                           | Network (RAN)| Station    |
   |   |                           | Network      |            |
   |   |                           | Controller   |            |
   +---+---------------------------+--------------+------------+
   | 4 | IEEE 1588 PTPv2           | Precision    | PTP Client |
   |   | Clock Synchronisation     | Time Protocol|            |
   |   | [IEEE1588]                | (PTP) Server |            |
   +---+---------------------------+--------------+------------+
   | 5 | Internet Access           | Broadband    | Subscriber |
   |   | [TR-101]                  | Network      |            |
   |   |                           | Gateway      |            |
   +---+---------------------------+--------------+------------+
   | 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 L2 Leaf-to-Leaf communication is not
   required or must be inhibited.

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

3.4.  Generic E-Tree Service

   A generic E-Tree service supports multiple Root endpoints.  The need
   for multiple Root endpoints is usually driven by a redundancy
   requirement.  Whether a particular E-Tree service needs to support
   single or multiple Roots depends on the target application.

   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 other Roots and Leaves
      - 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.

4.  Problem Statement

4.1.  Motivation

   L2VPN can be used to emulate MEF E-LAN service over an IP/MPLS PSN.

   Service providers also require E-Tree support in L2VPN.

4.2.  Leaf-to-Leaf Communication Restriction

   In this section, VPLS is used to illustrate the problem; however, the
   same principle applies to other L2VPN technologies.

   VPLS treats all attachment circuits (ACs) equally (essentially as
   Roots, although they not classified into Root or Leaf) and provides
   any-to-any connectivity among all ACs.  VPLS does not include any
   mechanism for communication restriction between specific ACs.
   Therefore, it is insufficient for emulating generic E-Tree service
   over an IP/MPLS PSN.

   As an example of the problems not addressed in VPLS solutions,
   consider the scenario in Figure 1 where there are two PEs, each with
   a Root AC and a Leaf AC and where VPLS is used to emulate an E-Tree
   service interconnecting these ACs over an IP/MPLS PSN.

                     <------------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 1: Problem Scenario for Leaf-to-Leaf Communication Restriction

   When PE2 receives a frame from PE1 via the Ethernet pseudowire (PW),

      - PE2 does not know which AC on PE1 is the ingress AC
      - PE2 does not know whether or not the ingress AC is a Leaf AC
      - PE2 does not have sufficient information to enforce the Leaf-to-
        Leaf communication restriction

   Examples where the problems arise:

      - Customer Edge 2 (CE2) sends a Broadcast/Multicast Ethernet frame
        to PE1 via AC2
      - CE2 sends a Unicast Ethernet frame to PE1 via AC2 with a
        destination MAC address corresponding to CE4's MAC address

   Note: Figure 1 is a hypothetical case solely used for explaining the
   problem; it is not meant to represent a typical E-Tree service.

   There are some possible ways to get around this problem that do not
   require extensions to existing VPLS solutions, but they all come with
   significant design complexity or deployment constraints.

5.  Requirements

5.1.  Functional Requirements

   The following are the E-Tree L2VPN functional requirements:

   (1) A solution MUST prohibit communication between any two Leaf ACs
       in an L2VPN instance.

   (2) A solution MUST allow multiple Root ACs in an L2VPN instance.

   (3) A solution MUST allow a Root AC and Leaf AC of an L2VPN instance
       to coexist on any PE.

5.2.  Applicability

   A solution MUST identify the L2VPN technology ([RFC4761], [RFC4762],
   [EVPN]) to which the solution is applicable.

5.3.  Backward Compatibility

   A solution SHOULD minimise the impact on VPLS and E-VPN L2VPN
   solutions, especially for the MEF E-LAN services already in
   operation.

   A solution SHOULD be backward compatible with the VPLS and E-VPN
   L2VPN solutions.  It SHOULD allow a case where a common L2VPN
   instance is composed of both PEs supporting the solution and PEs not
   supporting it, and the Leaf-to-Leaf communication restriction is
   enforced within the scope of the compliant PEs.

5.4.  External Network Network Interface (ENNI)

   A solution SHOULD support Root Operator Virtual Connection (OVC) End
   Point, Leaf OVC End Point and Trunk OVC End Point specified in
   [MEF26.1].

6.  Security Considerations

   This document introduces a requirement of prohibiting communication
   between any two Leaf ACs in an L2VPN instance.  In some use cases,
   such a requirement is imposed because of security reasons.  Other
   than that, there are no additional security considerations beyond
   those already described in [RFC4761], [RFC4762], and [EVPN].

7.  Contributors

   Ruediger Kunze
   Deutsche Telekom
   Winterfeldtstr. 21-27
   10781 Berlin, Germany
   EMail: ruediger.kunze@telekom.de

   Nick Del Regno
   Verizon
   400 International Pkwy
   Richardson, TX 75081, USA
   EMail: nick.delregno@verizon.com

   Josh Rogers
   Time Warner Cable
   11921 N Mo Pac Expy
   Suite 210B
   Austin, TX 78759, USA
   EMail: josh.rogers@twcable.com

8.  Acknowledgements

   The authors would like to thank Lizhong Jin, Lucy Yong, Yuji Kamite,
   and Wim Henderickx for their valuable input and support.

9.  References

9.1.  Normative References

   [MEF6.1]     Metro Ethernet Forum, "Ethernet Services Definitions -
                Phase 2", Technical Specification MEF 6.1, April 2008,
                <http://metroethernetforum.org/Assets/
                Technical_Specifications/PDF/MEF6-1.pdf>.

   [MEF10.2]    Metro Ethernet Forum, "Ethernet Services Attributes
                Phase 2", Technical Specification MEF 10.2, October
                2009, <http://metroethernetforum.org/Assets/
                Technical_Specifications/PDF/MEF10.2.pdf>.

   [MEF26.1]    Metro Ethernet Forum, "External Network Network
                Interface (ENNI) Phase 2", Technical Specification, MEF
                26.1, January 2012,
                <http://metroethernetforum.org/Assets/
                Technical_Specifications/PDF/MEF_26.1.pdf>.

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4761]    Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private
                LAN Service (VPLS) Using BGP for Auto-Discovery and
                Signaling", RFC 4761, January 2007.

   [RFC4762]    Lasserre, M., Ed., and V. Kompella, Ed., "Virtual
                Private LAN Service (VPLS) Using Label Distribution
                Protocol (LDP) Signaling", RFC 4762, January 2007.

9.2.  Informative References

   [EVPN]       Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N.,
                Henderickx, W., and A. Isaac, "Requirements for Ethernet
                VPN (EVPN)", Work in Progress, February 2014.

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

   [TR-101]     Broadband Forum, "Migration to Ethernet-Based DSL
                Aggregation", Technical Report, DSL Forum TR-101, April
                2006, <http://www.broadband-forum.org/
                technical/download/TR-101.pdf>.

   [VPMS]       Kamite, Y., Jounay, F., Niven-Jenkins, B., Brungard, D.,
                and L. Jin, "Framework and Requirements for Virtual
                Private Multicast Service (VPMS)", Work in Progress,
                October 2012.

Appendix A.  Frequently Asked Question

A.1.  Are E-Tree Requirements Addressed in the Virtual Private Multicast
      Service (VPMS) Requirements?

   VPMS requirements are defined in [VPMS].

   The focus of VPMS is to provide point-to-multipoint connectivity.

   VPMS provides single coverage of receiver membership (i.e., there is
   no distinct differentiation for multiple multicast groups).  A VPMS
   service supports single or multiple Root ACs.  All traffic from a
   Root AC will be forwarded to all Leaf ACs (i.e., Point-to-Multipoint
   (P2MP), from Root to all Leaves).  The destination address in an
   Ethernet frame is not used in data forwarding.  As an optional
   capability, a VPMS service may support reverse traffic from a Leaf AC
   to a Root AC (i.e., point-to-point (P2P), from Leaf to Root).

   In contrast, the focus of MEF E-Tree is that a Leaf can only
   communicate with Roots, not Leaves.

   A generic MEF E-Tree service supports multiple Root endpoints.
   Whether a particular E-Tree service needs to support single or
   multiple Root endpoints depends on the target application.

   As discussion in a previous section, a generic MEF E-Tree service
   supports all the following traffic flows:

      - Ethernet Unicast bidirectional Root to/from Root
      - Ethernet Unicast bidirectional Root to/from Leaf
      - Ethernet Broadcast/Multicast unidirectional Root to all Roots
        and Leaves
      - Ethernet Broadcast/Multicast unidirectional Leaf to all Roots

   A particular E-Tree service may need to support all the above or only
   a subset depending on the target application.

   The IETF's VPMS definition and MEF's E-Tree definition are
   significantly different.

   VPMS may be acceptable in cases where E-Tree service is needed, such
   as in the following cases:

      - No Unicast traffic from Root destined for a specific Leaf (or
        there is no concern if such Unicast traffic is forwarded to all
        Leaves)
      - No traffic between Roots

   For generic E-Tree service, VPMS will not be able to meet the
   requirements.

Authors' Addresses

   Raymond Key (editor)

   EMail: raymond.key@ieee.org


   Simon Delord
   Telstra

   EMail: simon.delord@gmail.com


   Frederic Jounay
   Orange CH
   4 rue caudray 1020 Renens
   Switzerland

   EMail: frederic.jounay@orange.ch


   Lu Huang
   China Mobile
   Unit 2, 28 Xuanwumenxi Ave, Xuanwu District
   Beijing 100053, China

   EMail: huanglu@chinamobile.com


   Zhihua Liu
   China Telecom
   109 Zhongshan Ave., Guangzhou
   510630, China

   EMail: zhliu@gsta.com


   Manuel Paul
   Deutsche Telekom
   Winterfeldtstr. 21-27
   10781 Berlin, Germany

   EMail: manuel.paul@telekom.de