idnits 2.17.00 (12 Aug 2021) /tmp/idnits31726/draft-zheng-l2vpn-evpn-pm-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 13, 2014) is 3012 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-l2vpn-evpn-req has been published as RFC 7209 == Outdated reference: draft-ietf-l2vpn-evpn has been published as RFC 7432 == Outdated reference: A later version (-03) exists of draft-zheng-l3vpn-pm-analysis-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Zheng 3 Internet-Draft Z. Li 4 Intended status: Standards Track S. Aldrin 5 Expires: August 17, 2014 Huawei Technologies 6 February 13, 2014 8 A Framework for E-VPN Performance Monitoring 9 draft-zheng-l2vpn-evpn-pm-framework-01 11 Abstract 13 The capability of Ethernet VPN performance monitoring (PM) is 14 important to meet the Service Level Agreement(SLA) for the service 15 beared. Since multipoint-to-point or multipoint-to-multipoint 16 (MP2MP) network model applies, flow identifying is a big challenge 17 for E-VPN PM. This document specifies the framework and mechanisms 18 for the application of E-VPN PM. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 17, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Overview and Concepts . . . . . . . . . . . . . . . . . . . . 4 63 3.1. EVI-to-EVI Tunnel . . . . . . . . . . . . . . . . . . . . 4 64 4. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4.1. E-VPN Membership Auto-Discovery . . . . . . . . . . . . . 4 66 4.2. EVI-to-EVI Tunnel Label Allocation . . . . . . . . . . . 4 67 5. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 5.1. Additional Label for Ingress EVI Identification . . . . . 5 69 5.2. Replace MAC Label with ET Label . . . . . . . . . . . . . 6 70 6. E-VPN Performance Monitoring . . . . . . . . . . . . . . . . 6 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 76 10.2. Informative References . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 Virtual Private LAN Service (VPLS) is a proven and widely deployed 82 Ethernet L2VPN solution. However, it has a number of limitations 83 when it comes to redundancy, multicast optimization and provisioning 84 simplicity. Also, new applications are driving several new 85 requirements for other L2VPN services such as E-TREE, VPWS, and VPMS. 86 Furthermore, data center interconnect applications are driving the 87 need for new service interface types, the "VLAN-aware Bundling" 88 service interfaces. Then the Ethernet VPN (E-VPN) solution (defined 89 in [I-D.ietf-l2vpn-evpn]) has been proposed to meet these 90 requirements which is documented in [I-D.ietf-l2vpn-evpn-req]. 92 An E-VPN comprises PEs that form the edge of the MPLS infrastructure 93 and CEs that are connected to PEs. The PEs provide virtual Layer 2 94 bridged connectivity between the CEs. In E-VPN, MAC learning between 95 PEs occurs not in the data plane but in the control plane. PEs 96 advertise the MAC addresses learned from the CEs, along with the 97 associated MPLS label, to other PEs in the control plane by using MP- 98 BGP. 100 The requirements and reference framework for Ethernet VPN (E-VPN) 101 Operations, Administration and Maintenance (OAM) has been specified 102 in [I-D.salam-l2vpn-evpn-oam-req-frmwk]. The capability of E-VPN to 103 measure and monitor performance metrics for packet loss, packet 104 delay, etc. is essential for meeting the Service Level Agreement 105 (SLA). This measurement capability also provides operators with 106 greater visibility into the performance characteristics of the 107 services in their networks, and provides diagnostic information in 108 case of performance degradation or failure and helps for fault 109 localization. To perform the measurement of packet loss, delay and 110 other metrics on a particular E-VPN flow, the egress PE needs to 111 determine which specific ingress EVI packets belongs to. There 112 exists complete and mature performance monitoring mechanism for the 113 traditional L2VPN based on the point-to-point PW. But in the case of 114 E-VPN, multipoint-to-point (MP2P) or multipoint-to-multipoint (MP2MP) 115 network model applies, it makes the flow identifying a big challenge 116 for packets loss and delay measurement. This MP2P or MP2MP model 117 also apply to L3VPN, please refer to [I-D.zheng-l3vpn-pm-analysis] 118 for detailed description of the challenge for performance monitoring 119 of such network model. 121 Statistical approximation of packet loss by using synthetic OAM 122 packets is briefly discussed in [I-D.salam-l2vpn-evpn-oam-req-frmwk]. 123 This document defines a framework for accurate performance monitoring 124 of E-VPN, especially for packet loss measurement. The point-to-point 125 connection named as EVI-to-EVI tunnel is introduced in E-VPN. And 126 the corresponding process of control plane and data plane is defined. 128 2. Terminology 130 E-VPN: Ethernet VPN 132 EVI: Ethernet VPN Instance 134 ET: EVI-to-EVI Tunnel 136 MP2P: Multi-Point to Point 138 MP2MP: Multi-Point to Multi-Point 140 P2P: Point to Point 142 PM: Performance Monitoring 144 3. Overview and Concepts 146 Based on the mechanisms in [I-D.ietf-l2vpn-evpn], for a particular 147 MAC address route, the directly connected PE allocates the same MPLS 148 label to all the remote PEs which maintain the MAC routing and 149 forwarding instance (EVI) of that E-VPN. Thus for the egress PE, it 150 is unable to identify the source EVI of the received E-VPN packets. 152 To perform the packet loss or delay measurement on a specific E-VPN 153 flow, it is critical to establish the Point-to-Point connection 154 between the two EVIs. Once the Point-to-Point connection is built 155 up, current measurement mechanisms for MPLS networks may be applied 156 to E-VPN. A new concept "EVI-to-EVI Tunnel" is introduced in the 157 following section to establish such Point-to-Point connection in 158 E-VPN. 160 3.1. EVI-to-EVI Tunnel 162 In order to perform performance monitoring in E-VPN, a point-to-point 163 connection between any two EVIs of a particular E-VPN needs to be 164 established. This point-to-point connection enables the egress PE 165 identifying the ingress EVI of the received E-VPN packet, thus 166 enables the measurement of the packet loss and delay between the 167 ingress and egress EVIs. Such point-to-point connection between an 168 ingress EVI and an egress EVI is called "EVI-to-EVI Tunnel (ET)". 170 4. Control Plane 172 This section describes the control plane mechanisms for E-VPN 173 performance monitoring. 175 4.1. E-VPN Membership Auto-Discovery 177 Before the Point-to-Point connections between EVIs could be 178 established, each PE attaching a given E-VPN needs to learn all the 179 remote PEs that attach to the same E-VPN. This could be achieved by 180 the Ethernet A-D route per EVI defined in [I-D.ietf-l2vpn-evpn]. 181 Please refer to section 9.4.1 [I-D.ietf-l2vpn-evpn] for details. 183 4.2. EVI-to-EVI Tunnel Label Allocation 185 After obtaining the E-VPN membership information, each PE needs to 186 allocate MPLS labels to identify the EVI-to-EVI tunnel from the 187 remote EVI to the local EVI. We call such labels as ET labels in 188 this document. For each local EVI, the egress PE SHOULD allocate 189 different ET labels for each remote EVI in PEs belonging to the same 190 E-VPN. As such, the egress PE could identify the E-VPN flow received 191 from different ingress EVIs, and the packet loss and delay 192 measurement could be performed between each ingress EVI and the local 193 EVI. 195 5. Data Plane 197 This section introduces two new MPLS label stack encapsulations when 198 ET label applies. 200 5.1. Additional Label for Ingress EVI Identification 202 When a E-VPN data packet is to be sent on the ingress PE, firstly the 203 label advertised by the MP-BGP for the Mac address route is pushed 204 onto the label stack. The ET label allocated by the egress EVI for 205 the ingress EVI should then be pushed onto the label stack to 206 identify the Point-to-Point connection between the sending and 207 receiving EVI. Finally the MPLS tunnel label is pushed onto the 208 label stack. The process of TTL and COS fields between the E-VPN 209 label encapsulation and the tunnel label encapsulation is done 210 according to the Pipe and Uniform Models defined by [RFC3270] and 211 [RFC3443].The value of the TTL and COS field in the MAC label's 212 encapsulation SHOULD be copied to the corresponding fields of the ET 213 label's encapsulation. As such, one extra label is carried in the 214 label stack compared with E-VPN data plane defined in 215 [I-D.ietf-l2vpn-evpn]. 217 When the E-VPN data packet received by the egress PE, the outermost 218 tunnel label is popped, then the egress PE could use the ET label to 219 identify the ingress EVI of the packet. The process of TTL and COS 220 fields at the egress node should be done according to the Pipe and 221 Uniform Models defined by [RFC3270] and [RFC3443]. Since the value 222 of the TTL and COS fields of the MAC label encapsulation and the ET 223 label encapsulation are the same, the TTL and COS fields of the ET 224 label encapsulation could be ignored during the course of the TTL and 225 COS process at the egress node. 227 +--------------+ +--------------+ 228 | Tunnel Label | | Tunnel Label | 229 +--------------+ \ +--------------+ 230 | MAC Label | -------\ | ET Label | 231 +--------------+ -------/ +--------------+ 232 | Payload | / | MAC Label | 233 +--------------+ +--------------+ 234 | Payload | 235 +--------------+ 237 Fig.1 Additional Label for Ingress EVI Identification 239 5.2. Replace MAC Label with ET Label 241 Since the ET label identifies the connection between the ingress EVI 242 and egress EVI, it could also be used to identify the egress EVI 243 forwarding table in which the MAC prefix lookup should be performed. 244 Thus when encapsulating the E-VPN data packets, the ingress PE could 245 simply replace the MAC label with the ET label, then push the tunnel 246 label. The process of TTL and COS fields between the MAC label 247 encapsulation and the tunnel label encapsulation is done according to 248 the Pipe and Uniform Models defined by [RFC3270] and [RFC3443]. The 249 TTL and COS value of the MAC label entry should be copied to the TTL 250 and COS field of the ET label entry respectively. In this way the 251 depth of the MPLS label stack is unchanged. 253 The encapsulation method would require the egress PE to perform MAC 254 prefix lookup in the egress EVI forwarding table before the packet 255 can be forwarded to a specific CE. The similar procedure is also 256 required when per-instance EVI label allocation mechanism is used. 257 The process of TTL and COS fields at the egress node should be done 258 according to the Pipe and Uniform Models defined by [RFC3270] and 259 [RFC3443]. Since the MAC label encapsulation is replaced with the ET 260 label encapsulation, the TTL and COS fields of the VT label 261 encapsulation should be used as those of the MAC label encapsulation 262 during the course of the TTL and COS process at the egress node. 264 +--------------+ +--------------+ 265 | Tunnel Label | | Tunnel Label | 266 +--------------+ \ +--------------+ 267 | MAC Label | -------\ | ET Label | 268 +--------------+ -------/ +--------------+ 269 | Payload | / | Payload | 270 +--------------+ +--------------+ 272 Fig.2 Replace the MAC Label with ET Label 274 6. E-VPN Performance Monitoring 276 [RFC6374] defines procedure and protocol mechanisms to enable the 277 efficient and accurate measurement of packet loss, delay, as well as 278 related metrics in MPLS networks. It provides either point-to-point 279 or point-to-multipoint measurement capabilities. Once the point-to- 280 point connection EVI-to-EVI Tunnel is established between the ingress 281 and egress EVIs, the procedures for the packet loss and delay 282 measurement as defined in [RFC6374] can be utilized for E-VPN 283 performance monitoring. The main difference between performance 284 monitoring of E-VPN and MPLS is the format of identifiers in the Loss 285 Measurement (LM) and Delay Measurement (DM) messages. Specifically, 286 for E-VPN, the source and destination addresses of the LM and DM 287 messages should be set to the concatenation of the Route 288 Distinguisher (RD) of the particular EVI and the IP address of the 289 ingress and egress PE respectively. 291 7. IANA Considerations 293 This document makes no request of IANA. 295 8. Security Considerations 297 TBD 299 9. Acknowledgements 301 TBD 303 10. References 305 10.1. Normative References 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, March 1997. 310 10.2. Informative References 312 [I-D.ietf-l2vpn-evpn-req] 313 Sajassi, A., Aggarwal, R., Bitar, N., and A. Isaac, 314 "Requirements for Ethernet VPN (EVPN)", draft-ietf-l2vpn- 315 evpn-req-07 (work in progress), February 2014. 317 [I-D.ietf-l2vpn-evpn] 318 Sajassi, A., Aggarwal, R., Henderickx, W., Isaac, A., and 319 J. Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf- 320 l2vpn-evpn-05 (work in progress), February 2014. 322 [I-D.salam-l2vpn-evpn-oam-req-frmwk] 323 Salam, S., Sajassi, A., Aldrin, S., and J. Drake, "E-VPN 324 Operations, Administration and Maintenance Requirements 325 and Framework", draft-salam-l2vpn-evpn-oam-req-frmwk-02 326 (work in progress), January 2014. 328 [I-D.zheng-l3vpn-pm-analysis] 329 Zheng, L., Li, Z., Aldrin, S., and B. Parise, "Performance 330 Monitoring Analysis for L3VPN", draft-zheng-l3vpn-pm- 331 analysis-02 (work in progress), October 2013. 333 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 334 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 335 Protocol Label Switching (MPLS) Support of Differentiated 336 Services", RFC 3270, May 2002. 338 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 339 in Multi-Protocol Label Switching (MPLS) Networks", RFC 340 3443, January 2003. 342 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 343 Measurement for MPLS Networks", RFC 6374, September 2011. 345 Authors' Addresses 347 Lianshu Zheng 348 Huawei Technologies 349 Huawei Campus, No.156 Beiqing Rd. 350 Beijing 100095 351 China 353 Email: vero.zheng@huawei.com 355 Zhenbin Li 356 Huawei Technologies 357 Huawei Campus, No.156 Beiqing Rd. 358 Beijing 100095 359 China 361 Email: lizhenbin@huawei.com 363 Sam K. Aldrin 364 Huawei Technologies 366 Email: aldrin.ietf@gmail.com