E-Tree L2VPN: Requirements for Metro Ethernet Forum (MEF) Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private Network (L2VPN)
What an L2VPN solution has to do to offer a rooted multipoint Ethernet service with leaf-to-leaf traffic blocked.
Key, R., Ed., DeLord, S., Jounay, F., Huang, L., Liu, Z., and M. Paul, "Requirements for Metro Ethernet Forum (MEF) Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private Network (L2VPN)", RFC 7152, DOI 10.17487/RFC7152, March 2014, <https://www.rfc-editor.org/info/rfc7152>.
@misc{rfc7152,
series = {Request for Comments},
number = 7152,
howpublished = {RFC 7152},
publisher = {RFC Editor},
doi = {10.17487/RFC7152},
url = {https://www.rfc-editor.org/info/rfc7152},
author = {R. Key and S. DeLord and F. Jounay and L. Huang and Z. Liu and M. Paul},
title = {{Requirements for Metro Ethernet Forum (MEF) Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private Network (L2VPN)}},
pagetotal = 12,
year = 2014,
month = mar,
} RFC text
Contents
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
ISO Plain Language
On this page
§1Introduction
The document provides functional requirements for supporting the Metro Ethernet Forum Ethernet Tree service, E-Tree, in multipoint Layer 2 Virtual Private Network solutions, which it calls simply L2VPN. It is intended that potential solutions use these requirements as guidelines.
A considerable number of service providers have adopted Virtual Private LAN Service to provide MEF Ethernet LAN services to customers. Those providers currently need a simple and effective way to emulate E-Tree services in addition to E-LAN services on their MPLS networks, and they also expect E-Tree support in any newly developed L2VPN technology.
Carriers already sell a flat Ethernet service over their MPLS networks. This RFC says what they would need to add to sell a tree-shaped one, where the branches cannot talk to each other.
§2The IETF L2VPN Services
VPLS, described in RFC 4761 and RFC 4762, is an L2VPN service that provides multipoint-to-multipoint connectivity for Ethernet across an IP or MPLS-enabled packet switched network. It emulates the VLAN functionality of traditional Ethernet networks. The customer Ethernet frame is transported over the packet switched network from the ingress provider edge to the egress provider edge, where the destination is chosen from the frame's destination MAC address in the context of the virtual switching instance to which it belongs.
E-VPN is an enhanced layer 2 service that emulates an Ethernet VLAN across an IP/MPLS packet switched network, primarily targeted at large-scale L2VPNs with resiliency requirements that other solutions do not meet. The RFC notes that E-VPN was under development at the time of writing and refers readers to its own requirements document.
Two IETF technologies are in scope: VPLS, which many carriers already run, and E-VPN, which was being written at the time.
§3E-LAN and E-Tree
MEF has defined two multipoint Ethernet service types: E-LAN, a multipoint-to-multipoint service, and E-Tree, a rooted-multipoint service.
They are similar in that the data frame is an Ethernet frame, the data forwarding is MAC-based, and a generic service of either kind is bidirectional in the sense that ingress frames can originate at any endpoint. The difference is in how endpoints are classified. Within a multipoint Ethernet service each endpoint is designated either a Root or a Leaf. A Root can communicate with all other endpoints in the same service, while a Leaf can only communicate with Roots. E-LAN has Root endpoints only, which means there is no communication restriction between endpoints. E-Tree has both Root and Leaf endpoints, which means a restriction between Leaf endpoints has to be enforced.
The RFC lists the use cases that drive this. A hub and spoke VPN puts the hub site at the Root and the spoke sites at the Leaves. Wholesale access puts the customer's interconnect at the Root and the customer's subscribers at the Leaves. Mobile backhaul puts the radio access network controller at the Root and the base stations at the Leaves. Precision clock synchronisation puts the PTP server at the Root and the clients at the Leaves. Internet access puts the broadband network gateway at the Root and the subscriber at the Leaf. Broadcast video puts the video source at the Root and the subscribers at the Leaves, and the broadcast and multicast variant adds a control channel. Device management puts the management system at the Root and the managed devices at the Leaves. Common to all of them, direct layer 2 leaf-to-leaf communication is not required or must be inhibited, and where leaf-to-leaf traffic is disallowed for security reasons, E-Tree is the way to prohibit it.
A generic E-Tree service supports multiple Root endpoints, usually for redundancy, though whether a particular service needs one or several depends on the application. It supports five flows: unicast from Root to Leaf, unicast from Leaf to Root, unicast from Root to Root, broadcast or multicast from Root to the other Roots and Leaves, and broadcast or multicast from Leaf to the Roots. A particular service may need only a subset.
The appendix answers a common question about whether the Virtual Private Multicast Service requirements already cover this. They do not. VPMS focuses on point-to-multipoint connectivity, provides single coverage of receiver membership with no distinct differentiation between multiple multicast groups, and does not use the destination address in an Ethernet frame for data forwarding. It may support reverse traffic from a Leaf to a Root as an optional capability. In contrast, the focus of MEF E-Tree is that a Leaf can only communicate with Roots and not with Leaves, and a generic E-Tree service supports multiple Root endpoints. The two definitions are significantly different. VPMS may be acceptable where no unicast traffic from the Root is destined for a specific Leaf, and where there is no traffic between Roots. For a generic E-Tree service, VPMS will not meet the requirements.
Both services carry Ethernet frames and forward by MAC address. The difference is that an E-LAN has only roots, so nothing is blocked, while an E-Tree has leaves, and leaves are cut off from each other.
- E-Tree service Eight use cases from the RFC
- Hub and Spoke VPN Root: hub site. Leaf: spoke sites.
- Wholesale Access Root: customer interconnect. Leaf: customer subscribers.
- Mobile Backhaul Root: radio access network controller. Leaf: base stations.
- IEEE 1588 PTPv2 Root: PTP server. Leaf: PTP clients.
- Internet Access Root: broadband network gateway. Leaf: subscriber.
- Broadcast Video Root: video source. Leaf: subscribers.
- Device Management Root: management system. Leaf: managed devices.
§4Why VPLS Cannot Do It
The RFC uses VPLS to illustrate the problem, and notes that the same principle applies to other L2VPN technologies. VPLS treats all attachment circuits equally, essentially as Roots, although they are not classified as Root or Leaf, and provides any-to-any connectivity among them. VPLS has no mechanism for restricting communication between specific attachment circuits, so it is insufficient for emulating a generic E-Tree service.
The worked example has two provider edges, each with a Root attachment circuit and a Leaf attachment circuit, connected by an Ethernet pseudowire. When the second provider edge receives a frame from the first over that pseudowire, three things are true at once: it does not know which attachment circuit on the first edge the frame came in on, it does not know whether that circuit was a Leaf, and it does not have enough information to enforce the leaf-to-leaf restriction. The cases that break are a Leaf sending a broadcast or multicast frame, and a Leaf sending a unicast frame addressed to the MAC address of another Leaf on the far side.
The RFC notes that there are ways around this problem that do not require extensions to existing VPLS solutions, but they all carry significant design complexity or deployment constraints.
When a frame arrives over the wire between two provider edges, the receiving edge cannot tell which customer site sent it. Without that, it cannot drop the frames that a leaf should not be sending.
§5The Requirements
Three functional requirements state what a solution must do. It MUST prohibit communication between any two Leaf attachment circuits in an L2VPN instance. It MUST allow multiple Root attachment circuits in an L2VPN instance. And it MUST allow a Root attachment circuit and a Leaf attachment circuit of an L2VPN instance to coexist on any provider edge.
Three further requirements constrain how a solution is built. A solution MUST identify the L2VPN technology to which it applies, naming VPLS or E-VPN. A solution SHOULD minimise the impact on VPLS and E-VPN solutions, especially for the E-LAN services already in operation, and SHOULD be backward compatible with them. It SHOULD allow a case where one L2VPN instance is composed of both provider edges that support the solution and provider edges that do not, with the leaf-to-leaf restriction enforced within the scope of the compliant provider edges only. And a solution SHOULD support the Root Operator Virtual Connection end point, the Leaf Operator Virtual Connection end point and the Trunk Operator Virtual Connection end point specified in the MEF external network network interface specification.
A solution must block leaf-to-leaf traffic, must allow several roots for redundancy, must allow a root and a leaf on the same router, and must fit into the networks providers already run.
| Requirement | What a solution must do |
|---|---|
| Leaf-to-leaf restriction | Prohibit communication between any two Leaf attachment circuits in an L2VPN instance. |
| Multiple roots | Allow multiple Root attachment circuits in an L2VPN instance. |
| Coexistence | Allow a Root and a Leaf attachment circuit of an L2VPN instance to coexist on any provider edge. |
§6Security Considerations
The document introduces a requirement to prohibit communication between any two Leaf attachment circuits in an L2VPN instance. In some use cases that requirement is imposed for security reasons. Other than that, there are no additional security considerations beyond those already described for VPLS and E-VPN.
Blocking leaf-to-leaf traffic is often the security point of the whole exercise. Beyond that, the rules of the existing L2VPN services apply unchanged.