Internet DRAFT - draft-jiang-l2vpn-evpn-etree-2vlan
draft-jiang-l2vpn-evpn-etree-2vlan
Internet Working Group Y. Jiang
Huawei
Internet Draft
Intended status: Standards Track
Expires: March 2013 September 21, 2012
E-Tree Support with 2VLAN in E-VPN
draft-jiang-l2vpn-evpn-etree-2vlan-00.txt
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 March 21, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Jiang Expires March 21, 2013 [Page 1]
Internet-Draft E-Tree Support with 2VLAN in E-VPN September 2012
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Abstract
This document discusses how the Dual-VLAN approach as described in
[Etree-vlan] can be used to support the transport of E-Tree service
in E-VPN. Thus a single convergent solution is possible for both VPLS
and E-VPN.
Table of Contents
1. Introduction ............................................. 2
2. Conventions used in this document ........................ 3
3. Terminology .............................................. 3
4. E-VPN Extensions for E-Tree Support ...................... 3
5. OAM Considerations ....................................... 5
6. Applicability ............................................ 5
7. Security Considerations .................................. 5
8. IANA Considerations ...................................... 5
9. References ............................................... 5
9.1. Normative References .................................. 5
9.2. Informative References ................................ 5
10. Acknowledgments .......................................... 6
1. Introduction
The E-Tree service is defined in Metro Ethernet Forum (MEF) as a
Rooted-Multipoint EVC service. It is a multipoint Ethernet service
with special restrictions: the frames from a root may be received by
any other root or leaf, and the frames from a leaf may be received by
any root, but MUST not be received by a leaf. Further, an E-Tree
service may include multiple roots and multiple leaves.
[Etree-req] gives the requirements for providing E-Tree solutions in
the VPLS and the need to filter leaf-to-leaf traffic.
Section 10 of [EVPN-req] discusses the requirements of providing the
ability to support hub and spoke (i.e., root and leaf) in E-VPN.
[EVPN-etree] proposed to use another layer of MPLS label to indicate
the E-Tree attributes of the port whereupon the packet is received.
This document discusses how the Dual-VLAN approach as described in
[Etree-vlan] can be used to support the transport of E-Tree service
Jiang Expires March 21, 2013 [Page 2]
Internet-Draft E-Tree Support with 2VLAN in E-VPN September 2012
in E-VPN. Thus a single convergent solution can be used for both VPLS
and E-VPN, and hopefully save the work in implementation.
2. 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].
3. Terminology
E-Tree: a Rooted-Multipoint EVC service as defined in MEF 6.1
EVC: Ethernet Virtual Connection, as defined in MEF 4.0
Root VLAN, a VLAN ID used to indicate all the frames that are
originated at a root AC
Leaf VLAN, a VLAN ID used to indicate all the frames that are
originated at a leaf AC
4. E-Tree Support with 2VLAN in E-VPN
The same E-Tree extended community as proposed in [Etree-vlan] can be
used for E-Tree signaling in E-VPN (copied here for convenience):
+------------------------------------+
| Extended community type (2 octets) |
+------------------------------------+
| Root VLAN (2 octets) |
+------------------------------------+
| Leaf VLAN (2 octets) |
+------------------------------------+
| Reserved |P|
+------------------------------------+
Figure 1 E-Tree Extended Community
Where:
o Root VLAN ID is the value of the local root VLAN.
Jiang Expires March 21, 2013 [Page 3]
Internet-Draft E-Tree Support with 2VLAN in E-VPN September 2012
o Leaf VLAN ID is the value of the local leaf VLAN.
o Reserved, 15 bits MUST be set to zero on transmit and be ignored
on receive.
o P is a Leaf-only bit, it is set to 1 to indicate that the PE is
attached with only leaf nodes, and set to 0 otherwise.
The PEs attached with root and/or leaf node(s) must support BGP E-
Tree signaling as described in [Etree-vlan], and must be capable of
VLAN mapping in their data planes.
In E-VPN signaling for E-Tree, the E-Tree extended community SHOULD
be further attached to the following E-VPN Route types:
- MAC Advertisement Routes
- Ethernet A-D Routes
- Inclusive Multicast Routes
For Point-to-Point connectivity, or for Point-to-MultiPoint
connectivity when ingress replication is used, since the ESI MPLS
label is a downstream assigned MPLS label, the same E-Tree signaling
as specified for BGP VPLS SHOULD be used. Furthermore, a PE that
receives a BGP UPDATE message attached with an E-Tree Extended
Community from its peer PE MUST process it as specified in Section 7
of [Etree-vlan] (after processing procedures as specified in [EVPN]).
For Point-to-MultiPoint connectivity when a P2MP or MP2MP LSP tunnel
as described in [EVPN] is used, since the ESI MPLS label is an
upstream assigned MPLS label, the ingress PEs in the P2MP LSP or
MP2MP LSP MUST set VLAN-Mapping-Mode to FALSE, and the egress PEs
MUST set VLAN-Mapping-Mode to TRUE if global VLANs are not
provisioned for the E-Tree. In E-Tree signaling, the E-Tree extended
community SHOULD only be used to notify which root and leaf VLANs are
used in each PE.
When an E-Tree frame arrives at a PE, a root VLAN or a leaf VLAN tag
is added according to the attribute (root or leaf) of the AC upon
which it is received. E-VPN data plane processing for the frame is
the same as described in [EVPN], and E-Tree data plane processing as
described at the end of Section 6 of [Etree-vlan] can be applied
further.
Jiang Expires March 21, 2013 [Page 4]
Internet-Draft E-Tree Support with 2VLAN in E-VPN September 2012
5. OAM Considerations
VPLS OAM requirements and framework as specified in [RFC6136] are
applicable to E-VPN, as both Ethernet OAM frames and data traffic are
transported over the same path.
Ethernet OAM for E-Tree including both service OAM and segment OAM
frames shall undergo the same VLAN mapping as the E-VPN data traffic;
and root VLAN SHOULD be applied to segment OAM frames so that they
are not filtered.
6. Applicability
The solution is applicable to E-VPN as specified in [EVPN].
7. Security Considerations
This solution prevents leaf to leaf communication in the data plane
of E-VPN even when its PEs are fully interconnected. In this regard,
security can be enhanced for customers with this solution.
8. IANA Considerations
Nothing special is needed for IANA consideration except those already
defined in [EVPN] and [Etree-VLAN].
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4761] Kompella, K. and Rekhter, Y., "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling", RFC
4761, January 2007
[RFC6136] Sajassi, A. and Mohan, D., "L2VPN OAM Requirements and
Framework", RFC 6136, March 2011
9.2. Informative References
[ETree-req] Key, R., et al, "Requirements for MEF E-Tree Support in
VPLS", draft-ietf-l2vpn-etree-reqt-01, Work in Progress
[Etree-vlan] Jiang, Y., and et al, "VPLS PE Model for E-Tree Support
", draft-ietf-l2vpn-vpls-pe-etree-00, Work in Progress
Jiang Expires March 21, 2013 [Page 5]
Internet-Draft E-Tree Support with 2VLAN in E-VPN September 2012
[EVPN] Sajassi, A., and et al., "BGP MPLS Based Ethernet VPN", draft-
ietf-l2vpn-evpn-01, work in progress
[EVPN-req] Sajassi, A., and et al., "Requirements for Ethernet VPN
(E-VPN)", draft-ietf-l2vpn-evpn-req-00, work in progress
[EVPN-etree] Sajassi, A., and et al., "E-TREE Support in E-VPN",
draft-sajassi-l2vpn-evpn-etree-00, work in progress
10. Acknowledgments
TBD
Authors' Addresses
Yuanlong Jiang
Huawei Technologies Co., Ltd.
Bantian, Longgang district
Shenzhen 518129, China
Email: jiangyuanlong@huawei.com
Jiang Expires March 21, 2013 [Page 6]
