Internet DRAFT - draft-zheng-l2vpn-evpn-pm-framework
draft-zheng-l2vpn-evpn-pm-framework
Network Working Group L. Zheng
Internet-Draft Z. Li
Intended status: Standards Track S. Aldrin
Expires: August 17, 2014 Huawei Technologies
February 13, 2014
A Framework for E-VPN Performance Monitoring
draft-zheng-l2vpn-evpn-pm-framework-01
Abstract
The capability of Ethernet VPN performance monitoring (PM) is
important to meet the Service Level Agreement(SLA) for the service
beared. Since multipoint-to-point or multipoint-to-multipoint
(MP2MP) network model applies, flow identifying is a big challenge
for E-VPN PM. This document specifies the framework and mechanisms
for the application of E-VPN PM.
Requirements Language
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 RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 17, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zheng, et al. Expires August 17, 2014 [Page 1]
Internet-Draft A Framework for EVPN PM February 2014
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview and Concepts . . . . . . . . . . . . . . . . . . . . 4
3.1. EVI-to-EVI Tunnel . . . . . . . . . . . . . . . . . . . . 4
4. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. E-VPN Membership Auto-Discovery . . . . . . . . . . . . . 4
4.2. EVI-to-EVI Tunnel Label Allocation . . . . . . . . . . . 4
5. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Additional Label for Ingress EVI Identification . . . . . 5
5.2. Replace MAC Label with ET Label . . . . . . . . . . . . . 6
6. E-VPN Performance Monitoring . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Virtual Private LAN Service (VPLS) is a proven and widely deployed
Ethernet L2VPN solution. However, it has a number of limitations
when it comes to redundancy, multicast optimization and provisioning
simplicity. Also, new applications are driving several new
requirements for other L2VPN services such as E-TREE, VPWS, and VPMS.
Furthermore, data center interconnect applications are driving the
need for new service interface types, the "VLAN-aware Bundling"
service interfaces. Then the Ethernet VPN (E-VPN) solution (defined
in [I-D.ietf-l2vpn-evpn]) has been proposed to meet these
requirements which is documented in [I-D.ietf-l2vpn-evpn-req].
An E-VPN comprises PEs that form the edge of the MPLS infrastructure
and CEs that are connected to PEs. The PEs provide virtual Layer 2
bridged connectivity between the CEs. In E-VPN, MAC learning between
PEs occurs not in the data plane but in the control plane. PEs
Zheng, et al. Expires August 17, 2014 [Page 2]
Internet-Draft A Framework for EVPN PM February 2014
advertise the MAC addresses learned from the CEs, along with the
associated MPLS label, to other PEs in the control plane by using MP-
BGP.
The requirements and reference framework for Ethernet VPN (E-VPN)
Operations, Administration and Maintenance (OAM) has been specified
in [I-D.salam-l2vpn-evpn-oam-req-frmwk]. The capability of E-VPN to
measure and monitor performance metrics for packet loss, packet
delay, etc. is essential for meeting the Service Level Agreement
(SLA). This measurement capability also provides operators with
greater visibility into the performance characteristics of the
services in their networks, and provides diagnostic information in
case of performance degradation or failure and helps for fault
localization. To perform the measurement of packet loss, delay and
other metrics on a particular E-VPN flow, the egress PE needs to
determine which specific ingress EVI packets belongs to. There
exists complete and mature performance monitoring mechanism for the
traditional L2VPN based on the point-to-point PW. But in the case of
E-VPN, multipoint-to-point (MP2P) or multipoint-to-multipoint (MP2MP)
network model applies, it makes the flow identifying a big challenge
for packets loss and delay measurement. This MP2P or MP2MP model
also apply to L3VPN, please refer to [I-D.zheng-l3vpn-pm-analysis]
for detailed description of the challenge for performance monitoring
of such network model.
Statistical approximation of packet loss by using synthetic OAM
packets is briefly discussed in [I-D.salam-l2vpn-evpn-oam-req-frmwk].
This document defines a framework for accurate performance monitoring
of E-VPN, especially for packet loss measurement. The point-to-point
connection named as EVI-to-EVI tunnel is introduced in E-VPN. And
the corresponding process of control plane and data plane is defined.
2. Terminology
E-VPN: Ethernet VPN
EVI: Ethernet VPN Instance
ET: EVI-to-EVI Tunnel
MP2P: Multi-Point to Point
MP2MP: Multi-Point to Multi-Point
P2P: Point to Point
PM: Performance Monitoring
Zheng, et al. Expires August 17, 2014 [Page 3]
Internet-Draft A Framework for EVPN PM February 2014
3. Overview and Concepts
Based on the mechanisms in [I-D.ietf-l2vpn-evpn], for a particular
MAC address route, the directly connected PE allocates the same MPLS
label to all the remote PEs which maintain the MAC routing and
forwarding instance (EVI) of that E-VPN. Thus for the egress PE, it
is unable to identify the source EVI of the received E-VPN packets.
To perform the packet loss or delay measurement on a specific E-VPN
flow, it is critical to establish the Point-to-Point connection
between the two EVIs. Once the Point-to-Point connection is built
up, current measurement mechanisms for MPLS networks may be applied
to E-VPN. A new concept "EVI-to-EVI Tunnel" is introduced in the
following section to establish such Point-to-Point connection in
E-VPN.
3.1. EVI-to-EVI Tunnel
In order to perform performance monitoring in E-VPN, a point-to-point
connection between any two EVIs of a particular E-VPN needs to be
established. This point-to-point connection enables the egress PE
identifying the ingress EVI of the received E-VPN packet, thus
enables the measurement of the packet loss and delay between the
ingress and egress EVIs. Such point-to-point connection between an
ingress EVI and an egress EVI is called "EVI-to-EVI Tunnel (ET)".
4. Control Plane
This section describes the control plane mechanisms for E-VPN
performance monitoring.
4.1. E-VPN Membership Auto-Discovery
Before the Point-to-Point connections between EVIs could be
established, each PE attaching a given E-VPN needs to learn all the
remote PEs that attach to the same E-VPN. This could be achieved by
the Ethernet A-D route per EVI defined in [I-D.ietf-l2vpn-evpn].
Please refer to section 9.4.1 [I-D.ietf-l2vpn-evpn] for details.
4.2. EVI-to-EVI Tunnel Label Allocation
After obtaining the E-VPN membership information, each PE needs to
allocate MPLS labels to identify the EVI-to-EVI tunnel from the
remote EVI to the local EVI. We call such labels as ET labels in
this document. For each local EVI, the egress PE SHOULD allocate
different ET labels for each remote EVI in PEs belonging to the same
E-VPN. As such, the egress PE could identify the E-VPN flow received
from different ingress EVIs, and the packet loss and delay
Zheng, et al. Expires August 17, 2014 [Page 4]
Internet-Draft A Framework for EVPN PM February 2014
measurement could be performed between each ingress EVI and the local
EVI.
5. Data Plane
This section introduces two new MPLS label stack encapsulations when
ET label applies.
5.1. Additional Label for Ingress EVI Identification
When a E-VPN data packet is to be sent on the ingress PE, firstly the
label advertised by the MP-BGP for the Mac address route is pushed
onto the label stack. The ET label allocated by the egress EVI for
the ingress EVI should then be pushed onto the label stack to
identify the Point-to-Point connection between the sending and
receiving EVI. Finally the MPLS tunnel label is pushed onto the
label stack. The process of TTL and COS fields between the E-VPN
label encapsulation and the tunnel label encapsulation is done
according to the Pipe and Uniform Models defined by [RFC3270] and
[RFC3443].The value of the TTL and COS field in the MAC label's
encapsulation SHOULD be copied to the corresponding fields of the ET
label's encapsulation. As such, one extra label is carried in the
label stack compared with E-VPN data plane defined in
[I-D.ietf-l2vpn-evpn].
When the E-VPN data packet received by the egress PE, the outermost
tunnel label is popped, then the egress PE could use the ET label to
identify the ingress EVI of the packet. The process of TTL and COS
fields at the egress node should be done according to the Pipe and
Uniform Models defined by [RFC3270] and [RFC3443]. Since the value
of the TTL and COS fields of the MAC label encapsulation and the ET
label encapsulation are the same, the TTL and COS fields of the ET
label encapsulation could be ignored during the course of the TTL and
COS process at the egress node.
+--------------+ +--------------+
| Tunnel Label | | Tunnel Label |
+--------------+ \ +--------------+
| MAC Label | -------\ | ET Label |
+--------------+ -------/ +--------------+
| Payload | / | MAC Label |
+--------------+ +--------------+
| Payload |
+--------------+
Fig.1 Additional Label for Ingress EVI Identification
Zheng, et al. Expires August 17, 2014 [Page 5]
Internet-Draft A Framework for EVPN PM February 2014
5.2. Replace MAC Label with ET Label
Since the ET label identifies the connection between the ingress EVI
and egress EVI, it could also be used to identify the egress EVI
forwarding table in which the MAC prefix lookup should be performed.
Thus when encapsulating the E-VPN data packets, the ingress PE could
simply replace the MAC label with the ET label, then push the tunnel
label. The process of TTL and COS fields between the MAC label
encapsulation and the tunnel label encapsulation is done according to
the Pipe and Uniform Models defined by [RFC3270] and [RFC3443]. The
TTL and COS value of the MAC label entry should be copied to the TTL
and COS field of the ET label entry respectively. In this way the
depth of the MPLS label stack is unchanged.
The encapsulation method would require the egress PE to perform MAC
prefix lookup in the egress EVI forwarding table before the packet
can be forwarded to a specific CE. The similar procedure is also
required when per-instance EVI label allocation mechanism is used.
The process of TTL and COS fields at the egress node should be done
according to the Pipe and Uniform Models defined by [RFC3270] and
[RFC3443]. Since the MAC label encapsulation is replaced with the ET
label encapsulation, the TTL and COS fields of the VT label
encapsulation should be used as those of the MAC label encapsulation
during the course of the TTL and COS process at the egress node.
+--------------+ +--------------+
| Tunnel Label | | Tunnel Label |
+--------------+ \ +--------------+
| MAC Label | -------\ | ET Label |
+--------------+ -------/ +--------------+
| Payload | / | Payload |
+--------------+ +--------------+
Fig.2 Replace the MAC Label with ET Label
6. E-VPN Performance Monitoring
[RFC6374] defines procedure and protocol mechanisms to enable the
efficient and accurate measurement of packet loss, delay, as well as
related metrics in MPLS networks. It provides either point-to-point
or point-to-multipoint measurement capabilities. Once the point-to-
point connection EVI-to-EVI Tunnel is established between the ingress
and egress EVIs, the procedures for the packet loss and delay
measurement as defined in [RFC6374] can be utilized for E-VPN
performance monitoring. The main difference between performance
monitoring of E-VPN and MPLS is the format of identifiers in the Loss
Measurement (LM) and Delay Measurement (DM) messages. Specifically,
for E-VPN, the source and destination addresses of the LM and DM
Zheng, et al. Expires August 17, 2014 [Page 6]
Internet-Draft A Framework for EVPN PM February 2014
messages should be set to the concatenation of the Route
Distinguisher (RD) of the particular EVI and the IP address of the
ingress and egress PE respectively.
7. IANA Considerations
This document makes no request of IANA.
8. Security Considerations
TBD
9. Acknowledgements
TBD
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.
10.2. Informative References
[I-D.ietf-l2vpn-evpn-req]
Sajassi, A., Aggarwal, R., Bitar, N., and A. Isaac,
"Requirements for Ethernet VPN (EVPN)", draft-ietf-l2vpn-
evpn-req-07 (work in progress), February 2014.
[I-D.ietf-l2vpn-evpn]
Sajassi, A., Aggarwal, R., Henderickx, W., Isaac, A., and
J. Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-
l2vpn-evpn-05 (work in progress), February 2014.
[I-D.salam-l2vpn-evpn-oam-req-frmwk]
Salam, S., Sajassi, A., Aldrin, S., and J. Drake, "E-VPN
Operations, Administration and Maintenance Requirements
and Framework", draft-salam-l2vpn-evpn-oam-req-frmwk-02
(work in progress), January 2014.
[I-D.zheng-l3vpn-pm-analysis]
Zheng, L., Li, Z., Aldrin, S., and B. Parise, "Performance
Monitoring Analysis for L3VPN", draft-zheng-l3vpn-pm-
analysis-02 (work in progress), October 2013.
Zheng, et al. Expires August 17, 2014 [Page 7]
Internet-Draft A Framework for EVPN PM February 2014
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, May 2002.
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
in Multi-Protocol Label Switching (MPLS) Networks", RFC
3443, January 2003.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011.
Authors' Addresses
Lianshu Zheng
Huawei Technologies
Huawei Campus, No.156 Beiqing Rd.
Beijing 100095
China
Email: vero.zheng@huawei.com
Zhenbin Li
Huawei Technologies
Huawei Campus, No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Sam K. Aldrin
Huawei Technologies
Email: aldrin.ietf@gmail.com
Zheng, et al. Expires August 17, 2014 [Page 8]
