wdiff rfc7152.original rfc7152.txt

Network Working Group Raymond Key (editor), Huawei
Internet Draft Simon Delord, Telstra Engineering Task Force (IETF) R. Key, Ed.
Request for Comments: 7152 S. Delord
Category: Informational Frederic Jounay, Telstra
ISSN: 2070-1721 F. Jounay
Orange CH
Expires: January 2014 Lu Huang,
L. Huang
China Mobile
Zhihua Liu,
Z. Liu
China Telecom
Manuel Paul,
M. Paul
Deutsche Telekom

July 29,
March 2013

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

Abstract

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

Status of this This Memo

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

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

This document is a product of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working
(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 as Internet-
Drafts.

Internet-Drafts
approved by the IESG are draft documents valid for a maximum candidate for any level of six months 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 updated, replaced, or obsoleted by other documents obtained at any
time. It
http://www.rfc-editor.org/info/rfc7152.

This document is inappropriate subject to use Internet-Drafts 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 reference
material or they describe your rights and restrictions with respect
to cite them other than this document. Code Components extracted from this document must
include Simplified BSD License text as "work described in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list Section 4.e of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 29, 2014.
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

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

1. Introduction

Considerable

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 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 a an L2VPN service that provides multipoint-
to-multipoint
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) 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 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 Layer-2 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 [Draft EVPN
Req]. [EVPN].

3. MEF Multipoint Ethernet Services

MEF has defined two multipoint Ethernet Service service types:

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

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

3.1. Similarities between E-LAN and E-Tree

Following

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 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 below presents some major E-Tree use cases.

Table 1: E-Tree Use Cases

Common to all use cases, direct layer 2 L2 Leaf-to-Leaf communication is not
required or must be inhibited.

If direct layer 2 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 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. But 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
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 PW, 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 or not
- PE2 does not have sufficient information to enforce the
Leaf-to-Leaf Leaf-to-
Leaf communication restriction

Examples where the problems arise:

- CE2 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, and
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 solutions, but they all come with
significant design complexity or deployment constraints, please refer
to [Draft ETree Frwk] Appendix A. constraints.

5. Requirements

5.1. Functional Requirements

Following

The following are the E-Tree L2VPN functional requirements:

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

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

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

5.2. Applicability

A solution MUST identify the L2VPN technology ([RFC4761], [RFC4762],
E-VPN)
[EVPN]) to which the solution is applicable to. 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 a 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] [Draft EVPN Req]. [RFC4761], [RFC4762], and [EVPN].

7. IANA Considerations

This document has no actions for IANA.

8. Contributors

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

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

9.
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 Kamite,
and Wim Henderickx for their valuable input and support.

10.

9. References

10.1.

9.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 "Ethernet Services Definitions -
Phase 2, 2", Technical Specification MEF 6.1, April 2008 2008,
<http://metroethernetforum.org/Assets/
Technical_Specifications/PDF/MEF6-1.pdf>.

[MEF10.2] Metro Ethernet Forum, Ethernet "Ethernet Services Attributes -
Phase 2, 2", Technical Specification MEF 10.2, October 2009

[MEF22.1] Metro Ethernet Forum, Mobile Backhaul Implementation
Agreement - Phase 2, January 2012
2009,
<http://metroethernetforum.org/Assets/
Technical_Specifications/PDF/MEF10.2.pdf>.

[MEF26.1] Metro Ethernet Forum, External "External Network Network
Interface (ENNI) - Phase 2, 2", Technical Specification, MEF
26.1, January 2012 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 & Kompella, K., Ed., and Y. Rekhter, Virtual Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling,
Signaling", RFC 4761, January 2007 2007.

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

10.2. 2007.

9.2. Informative References

[Draft EVPN Req]

[EVPN] Sajassi, et al., Requirements A., Aggarwal, R., Uttaro, J., Bitar, N.,
Henderickx, W., and A. Isaac, "Requirements for Ethernet
VPN
(EVPN), draft-ietf-l2vpn-evpn-req-04
(work (EVPN)", Work in progress), Progress, February 2014.

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

[TR-101] Broadband Forum, Migration "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] DSL
Aggregation", Technical Report, DSL Forum TR-101, April
2006, <http://www.broadband-
forum.org/technical/download/TR-101.pdf>.

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

Appendix A. Frequently Asked Questions Question

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

VPMS requirements are defined in [Draft VPMS Frmwk]. [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., P2MP, Point-to-Multipoint
(P2MP), from Root to all Leaves). Destination 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., P2P, 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 but 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. 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)
Huawei
Email:
EMail: raymond.key@ieee.org

Simon Delord
Telstra
Email:
EMail: simon.delord@gmail.com

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

Lu Huang
China Mobile
Unit 2, 28 Xuanwumenxi Ave, Xuanwu District
Beijing 100053, China
Email:
EMail: huanglu@chinamobile.com

Zhihua Liu
China Telecom
109 Zhongshan Ave., Guangzhou
510630, China
Email:
EMail: zhliu@gsta.com

Manuel Paul
Deutsche Telekom
Winterfeldtstr. 21-27
10781 Berlin, Germany
Email:
EMail: manuel.paul@telekom.de

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

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.