Internet DRAFT - draft-ietf-l2vpn-etree-reqt

draft-ietf-l2vpn-etree-reqt






Network Working Group                       Raymond Key (editor), Huawei
Internet Draft                                     Simon Delord, Telstra
Category: Informational                       Frederic Jounay, Orange CH
Expires: January 2014                             Lu Huang, China Mobile
                                               Zhihua Liu, China Telecom
                                           Manuel Paul, Deutsche Telekom


                                                           July 29, 2013


              Requirements for Metro Ethernet Forum (MEF)
                Ethernet-Tree (E-Tree) Support in L2VPN
                    draft-ietf-l2vpn-etree-reqt-05


Abstract

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


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 29, 2014. 







Key, et al.               Expires January 2014                 [Page 1]

Internet Draft         Requirement E-Tree in L2VPN             July 2013


Table of Contents
   
   1. Introduction....................................................3
   2. IETF Multipoint Ethernet L2VPN Services.........................3
   2.1. VPLS..........................................................3
   2.2. E-VPN.........................................................3
   3. MEF Multipoint Ethernet Services................................3
   3.1. Similarity between E-LAN and E-Tree...........................4
   3.2. Difference 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.................................................7
   5.3. Backward Compatibility........................................8
   5.4. External Network Network Interface............................8
   6. Security Consideration..........................................8
   7. IANA Considerations.............................................8
   8. Contributors....................................................8
   9. Acknowledgements................................................8
   10. References.....................................................8
   10.1. Normative References.........................................8
   10.2. Informative References.......................................9
   Appendix
   A. Frequently Asked Questions.....................................10
   A.1. Are E-Tree requirements addressed in the Virtual 
        Private Multicast Service (VPMS) requirements?...............10
   Authors' Addresses................................................11
   Contributors' Addresses...........................................12
   Intellectual Property and Copyright Statements....................12


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 2014                 [Page 2]

Internet Draft         Requirement E-Tree in L2VPN             July 2013


1. Introduction 

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

   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.

2. IETF Multipoint Ethernet L2VPN Services

2.1. VPLS 

   VPLS [RFC4761] [RFC4762] is a 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 
   Virtual Local Area Network (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 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 Layer-2 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 [Draft EVPN 
   Req].

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 full specification, please refer to [MEF6.1] [MEF10.2].






Key, et al.               Expires January 2014                 [Page 3]

Internet Draft         Requirement E-Tree in L2VPN             July 2013


3.1. Similarities between E-LAN and E-Tree

   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.
































Key, et al.               Expires January 2014                 [Page 4]

Internet Draft         Requirement E-Tree in L2VPN             July 2013


3.3. E-Tree Use Cases

   Table 1 below 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 Area   | RAN Base   |
   |   |                           | Network (RAN)| Station    |
   |   |                           | Network      |            |
   |   |                           | Controller   |            |
   +---+---------------------------+--------------+------------+
   | 4 | IEEE 1588 PTPv2           | Precision    | PTP Client |
   |   | Clock Synchronisation     | time Protocol|            |
   |   |                           | (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 layer 2 Leaf-to-Leaf communication is 
   not required or must be inhibited.

   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.









Key, et al.               Expires January 2014                 [Page 5]

Internet Draft         Requirement E-Tree in L2VPN             July 2013


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













Key, et al.               Expires January 2014                 [Page 6]

Internet Draft         Requirement E-Tree in L2VPN             July 2013


                     <------------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 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 where the problems arise:
     - 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, and 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, please refer 
   to [Draft ETree Frwk] Appendix A.
 
5. Requirements

5.1. Functional Requirements

   Following are the E-Tree L2VPN functional requirements:

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

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

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

5.2. Applicability

   A solution MUST identify the L2VPN technology ([RFC4761], [RFC4762], 
   E-VPN) the solution is applicable to.


Key, et al.               Expires January 2014                 [Page 7]

Internet Draft         Requirement E-Tree in L2VPN             July 2013


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 a L2VPN instance. In some use cases, such 
   requirement is imposed because of security reasons. Other than that, 
   there are no additional security considerations beyond those already 
   described in [RFC4761] [RFC4762] [Draft EVPN Req].

7. IANA Considerations 
    
   This document has no actions for IANA.
    
8. Contributors

   Ruediger Kunze, Deutsche Telekom
   Nick Del Regno, Verizon
   Josh Rogers, Time Warner Cable

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

10. References    

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

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


Key, et al.               Expires January 2014                 [Page 8]

Internet Draft         Requirement E-Tree in L2VPN             July 2013


   [MEF10.2]    Metro Ethernet Forum, Ethernet Services Attributes - 
                Phase 2, October 2009

   [MEF22.1]    Metro Ethernet Forum, Mobile Backhaul Implementation 
                Agreement - Phase 2, January 2012

   [MEF26.1]    Metro Ethernet Forum, External Network Network Interface
                (ENNI) - Phase 2, January 2012
   
   [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

10.2. Informative References

   [Draft EVPN Req]   Sajassi, et al., Requirements for Ethernet VPN 
                      (EVPN), draft-ietf-l2vpn-evpn-req-04 
                      (work in progress), July 2013

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

   [Draft ETree Frwk] Key, et al., A Framework for E-Tree Service over 
                      MPLS Network, draft-ietf-l2vpn-etree-frwk-02 
                      (work in progress), February 2013

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




















Key, et al.               Expires January 2014                 [Page 9]

Internet Draft         Requirement E-Tree in L2VPN             July 2013


Appendix A. Frequently Asked Questions

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

   VPMS requirements are defined in [Draft VPMS Frmwk].

   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., P2MP, from Root to all 
   Leaves). Destination address in 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., P2P, from Leaf to 
   Root).

   In contrast, the focus of MEF E-Tree is that a Leaf can only 
   communicate with Roots but 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 & 
       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.

   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.






Key, et al.               Expires January 2014                 [Page 10]

Internet Draft         Requirement E-Tree in L2VPN             July 2013


Authors' Addresses 
    
   Raymond Key (editor)
   Huawei
   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




















Key, et al.               Expires January 2014                 [Page 11]

Internet Draft         Requirement E-Tree in L2VPN             July 2013


Contributors' Addresses  

   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

Copyright Notice 
    
   Copyright (c) 2013 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 2014                 [Page 12]