idnits 2.17.00 (12 Aug 2021) /tmp/idnits32243/draft-zheng-l3vpn-pm-analysis-03.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 (July 3, 2014) is 2872 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: Informational S. Aldrin 5 Expires: January 4, 2015 Huawei Technologies 6 B. Parise 7 Cisco Systems 8 July 3, 2014 10 Performance Monitoring Analysis for L3VPN 11 draft-zheng-l3vpn-pm-analysis-03 13 Abstract 15 To perform the measurement of packet loss, delay and other metrics on 16 a particular VPN flow, the egress PE need to tell to which specific 17 ingress VRF a packet belongs to. But for L3VPN, multipoint-to-point 18 network model applies, flow identifying is a challenge. This 19 document summarizes the current performance monitoring mechanisms for 20 L3VPN in MPLS networks, and analyzes various solutions and challenges 21 for measuring performance metrics within these networks. This 22 document also identifies various key points which needs to be taken 23 in consideration when designing L3VPN performance monitoring 24 mechanisms. Performance measurements within non-MPLS L3VPN networks 25 is not within the scope of the document. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 4, 2015. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Requirement of L3VPN Performance Monitoring . . . . . . . . . 3 69 3. Overview of Current Mechanisms for MPLS Networks . . . . . . 4 70 3.1. Packet Loss and Delay Measurement for MPLS Networks . . . 4 71 3.2. Synthetic Measurements . . . . . . . . . . . . . . . . . 4 72 3.3. Real packet Measurements . . . . . . . . . . . . . . . . 5 73 3.4. Profile for MPLS-based Transport Networks . . . . . . . . 5 74 4. Challenge for L3VPN Performance Monitoring . . . . . . . . . 5 75 5. Design Consideration . . . . . . . . . . . . . . . . . . . . 7 76 5.1. P2P Pseudo Connection . . . . . . . . . . . . . . . . . . 7 77 5.2. Hierarchy L3VPN . . . . . . . . . . . . . . . . . . . . . 7 78 5.3. Control Plane . . . . . . . . . . . . . . . . . . . . . . 7 79 5.4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . 7 80 5.5. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . . . 7 81 5.6. QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 5.7. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 6. Manageability Consideration . . . . . . . . . . . . . . . . . 8 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 88 9.2. Informative References . . . . . . . . . . . . . . . . . 9 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 91 1. Introduction 93 Level 3 Virtual Private Network (L3VPN) [RFC4364]service is widely 94 deployed in the production network. It is deployed to provide 95 enterprise interconnection, Voice over IP (VoIP), video, mobile, etc. 96 services. Most of these services are sensitive to the packet loss 97 and delay. The capability of performance metrics measurement for 98 packet loss, delay, as well as related metrics is essential for 99 performance monitoring and Service Level Agreement (SLA). The 100 requirement for SLA measurement for MPLS networks has been documented 101 in [RFC4377]. 103 One popular deployment of L3VPN nowadays is in mobile backhaul 104 networks. When deploying MPLS-TP in mobile backhaul networks, due to 105 the scaling issue with PWs, L3VPN is used either for end-to-end 106 service delivery, or L2VPN and L3VPN are used in hybrid networking. 107 The measurement capability of L3VPN provides operators with greater 108 visibility into the performance characteristics of their networks, 109 and provides diagnostic information in case of performance 110 degradation or failure and helps for fault localization. 112 To perform the measurement of packet loss, delay and other metrics on 113 a particular VPN flow, the egress PE need to tell to which specific 114 ingress VRF a packet belongs. But for L3VPN, there multipoint-to- 115 point (MP2P) network model applies, flow identifying is a challenge. 116 This document summarizes the current performance monitoring 117 mechanisms for MPLS networks, and analyzes the challenges for L3VPN 118 performance monitoring. This document also discuss the key points 119 need to be taken into consideration when designing L3VPN performance 120 monitoring mechanisms. All references to L3VPN in the document 121 refers to MPLS L3VPN networks. 123 2. Requirement of L3VPN Performance Monitoring 125 The specific user's traffic is usually tranported by the VPN of the 126 service provider. The performance mornitoring needs to be done on 127 the aggregation flow beween a pair of VRFs which belong to the same 128 VPN for a specific user. And the correpsonding performance 129 mornitoring report should be provided against the Service Level 130 Agreement (SLA) by the service provider. For example, in the 131 following figure, the VRF11 and VRF12 belongs to VPN1 which is used 132 to bear the service traffic for the specific user USER1, and the 133 VRF21 and VRF22 belongs to VPN2 which is used to bear the service 134 traffic for the specific user USER2. Then the performance monitoring 135 needs to be implemented on the aggregation traffic flow between VRF11 136 and VRF12 for the USER1. And the performance monitoring needs to be 137 implemented on the aggregation traffic flow between VRF21 and VRF22 138 for the USER2. 140 +-----+-----+ VPN FLOW 1 +----+-----+ 141 |VRF11| <------------------------> |VRF12| 142 |-----+ | | +-----+ 143 +--+ | | +---+ | | +--+ 144 |CE|----| PE1 |------| P |------| PE2 |----|CE| 145 +--+ | | +---+ | | +--+ 146 +-----+ | | +-----+ 147 |VRF21| <------------------------> |VRF22| 148 +-----+-----+ VPN FLOW 2 +----+-----+ 150 Figure 1: Performance Monitoring between VRFs 152 In order to facilitate the description, we introduce two 153 terminologies in this document: 155 -- VPN flow: a VPN flow is the aggregate traffic flow between an 156 ingress VRF and an egress VRF belongs to the same VPN. 158 -- L3VPN Performance Monitoring (PM): L3VPN PM means the performance 159 mornitoring on a VPN flow. 161 3. Overview of Current Mechanisms for MPLS Networks 163 3.1. Packet Loss and Delay Measurement for MPLS Networks 165 [RFC6374]defines procedure and protocol mechanisms to enable the 166 efficient and accurate measurement of packet loss, delay, as well as 167 related metrics in MPLS networks. 169 The Loss Measurement (LM) protocol can perform two distinct kinds of 170 loss measurement. In inferred mode, it can measure the loss of 171 specially generated test packets (in order to infer the approximate 172 data-plane loss level). In direct mode, it can directly measure 173 data-plane packet loss. Direct mode measurements provide perfect 174 loss accounting, but may require specialized hardware support and is 175 only applicable to some LSP types. Inferred measurement provides 176 only approximate loss measurments but is generally applicable. The 177 LM and Delay Measurement (DM) protocols are initiated from a single 178 node. A query message may be received either by a single node or by 179 multiple nodes; i.e. these protocols provide point-to-point or point- 180 to-multipoint measurement capabilities. 182 3.2. Synthetic Measurements 184 Performance measurements are done using synthetic packets sent over 185 the network. Metrics like response time, jitter, packet loss could 186 be inferred using these synthetic packet measurements. In order to 187 perform inferred measurements, the crafted packets have to behave 188 like data packets and take the same path as data packets. 190 3.3. Real packet Measurements 192 Measurements of actual data packets is resource intensive and 193 requires special way of accounting for the measurements. Counters 194 within the network devices are primarily used to measure various 195 metrics. Various technologies like Netflow, IPFIX, etc are used to 196 collect the data and process it offline to derive performance 197 measurements. When the data is aggregated, collecting per flow or 198 per VPN customer traffic data becomes complex. 200 3.4. Profile for MPLS-based Transport Networks 202 Procedures for the measurement of packet loss, delay, and throughput 203 in MPLS networks are defined in [RFC6374]. [RFC6375]describes a 204 profile, i.e. a simplified subset, of procedures that suffices to 205 meet the specific requirements of MPLS-based transport networks 206 [RFC5921] as defined in [RFC5860]. This profile is presented for the 207 convenience of implementers who are concerned exclusively with the 208 transport network context. 210 LM session is externally configured and the values of several 211 protocol parameters can be fixed in advance at the endpoints involved 212 in the session, so that inspection or negotiation of these parameters 213 is not required. 215 4. Challenge for L3VPN Performance Monitoring 217 To perform the measurement of packet loss, delay and other metrics on 218 a particular VPN flow, the egress PE need to tell to which specific 219 ingress VRF a packet belongs. 221 The above mentioned existing mechanisms for MPLS networks provide 222 either point-to-point or point-to-multipoint measurement 223 capabilities. For a specific receiver, it could easily identify a 224 specific flow by the label stack information, when LDP is not used 225 and Penultimate Hop Pop (PHP) function is disabled. 227 But in the case of L3VPN, multipoint-to-point network model applies , 228 it makes the identification of a flow a challenge, for packet loss 229 and delay measurement. According to the label allocation mechanisms 230 of L3VPN, a private label itself cannot uniquely identify a specific 231 VPN flow. That is, when the egress PE allocates VPN label for a 232 specific prefix of a VPN, the same label will be advertised to all 233 its peers. Given a VPN flow, the egress PE cannot tell which ingress 234 VRF is from based on the private label it carries. As a result, it's 235 not feasible to perform the loss or delay measurement on this flow. 237 Some people may argue this could be solved by using " tunnel label + 238 private label" for flow identification, but it is not true. In L3VPN 239 when LDP LSP applies[RFC5036], the LSPs may be merged at any 240 intermediate nodes along the LSP. The egress PE cannot derive a 241 unique identifier of the source PE from label stack. The tunnel 242 label cannot help for flow identification due to the LSP merge. When 243 TE LSP applies [RFC3209] in L3VPN, the ingress VRF could be 244 identified by the " tunnel label + private label" only if no extranet 245 exist. The egress PE cannot tell which specific VRF a packet belongs 246 to, when extranet (If the various sites in a VPN are owned by 247 different enterprises) exist on ingress PE. Figure 1 shows an 248 example of extranet VPN. In the extranet VPN, both Site 11 and Site 249 12 can access to Site 1. But Site 11 and Site 12 cannot access to 250 each other. Then VRF1 on PE1 allocates the same label L for the 251 specific prefix to VRF11 and VRF12 on PE2. Thus when PE1 receives 252 the VPN flow from PE3, it cannot tell if the flow is from VRF11 or 253 VRF12 by the label stack. 255 +------+ +------------+ +-------------+ +------+ 256 | SITE |----+----| PE1 +----+ PE3 +-----+-----+ SITE | 257 | 1 | |VRF1| | | |VRF13| | 13 | 258 +------+ +----+------------+ +------+------+-----+ +------+ 259 | | 260 | | 261 | +------+------+ 262 +----------+ PE2 | 263 | | 264 +-----+-+-----+ 265 |VRF11| |VRF12| 266 +-----+ +-----+ 267 | | 268 | | 269 +------+ +------+ 270 | SITE | | SITE | 271 | 11 | | 12 | 272 +------+ +------+ 274 Figure3: Extranet VPN on Ingress PE 276 The current label allocation mechanism of L3VPN makes the flow 277 identification a challenge for L3VPN performance monitoring, as a 278 result the current performance monitoring mechanisms for MPLS 279 networks cannot be applied to L3VPN networks. Without any backward 280 compatible extensions or alteration to current label allocation 281 mechanisms, performance measurements cannot be performed in L3VPN 282 networks. 284 5. Design Consideration 286 This section discuss the key points need to be taken in consideration 287 when designing L3VPN performance monitoring mechanism. 289 5.1. P2P Pseudo Connection 291 As analyzed above, to perform the packet loss or delay measurement on 292 a specific VPN flow, it is critical for the egress PE to uniquely 293 identify the ingress VRF, i.e. to establish the Point-to-Point pseudo 294 connection between the two VRFs. Current allocation mechanism may 295 need extension or alteration to help build up the Point-to-Point 296 pseudo connection. Once the Point-to-Point pesudo connection is 297 built up, current measurement mechanisms may be applied to L3VPN . 299 5.2. Hierarchy L3VPN 301 There are flexible hierarchy L3VPN deployment scenarios such as 302 inter-AS, carrier's carrier, etc. [RFC4364]. The the design of LM 303 and DM mechanisms should take these scenarios into account. 305 5.3. Control Plane 307 In L3VPN, BGP is used to distribute a particular route, as well as an 308 MPLS label that is mapped to that route [RFC4364]. The label mapping 309 information for a particular route is piggybacked in the same BGP 310 Update message that is used to distribute the route itself. In order 311 to setup the Point-to-Point pseudo connection between ingress and 312 egress VRFs the current label distribution mechanism may be altered. 313 For compatibility, this alteration SHOULD NOT change the current 314 label distribution mechanism dramatically. 316 5.4. Data Plane 318 Same as for control plane, for compatibility reason, the data plane 319 should as far as possible be compatible with the current L3VPN 320 forwarding procedure. 322 5.5. MPLS OAM 324 [RFC6374], [RFC6375]defines procedure and protocol mechanisms to 325 enable the measurement of packet loss, delay, as well as related 326 metrics for MPLS networks. These mechanisms SHOULD be reasonably 327 reused in L3VPN networks. The addressing of source an destination of 328 Loss Measurement (LM) and Delay Measurement (DM) messages may needed 329 to be changed to identify the measured VRF. 331 LSP ping and trace based on [RFC4379] are used to perform various 332 metric measurement which includes jitter etc. Most of the 333 measurements like response time, jitter, etc., are inferred 334 measurements with synthetic measurements and not necessarily the true 335 representation of the data packets traversing the network, especially 336 with respect to packet loss measurements. 338 5.6. QoS 340 Performing the packet loss or delay measurement in L3VPN network, 341 either proactive or on-demand, SHOULD NOT impact the customer QoS 342 experience. 344 5.7. ECMP 346 Performance measurements within ECMP networks poses a bigger 347 challenge. When the data packet traverse the network, the logic of 348 hashing on to a ECMP path is a local decision based on the header 349 information it is carrying. Number of labels, IP header, UDP header 350 could play a role in considering which path the packet traverses. 351 When PM is measured with synthetic packets, the crafted packets have 352 to be constructed to ensure various ECMP paths are measured. This 353 poses a big challenge for the source, which generates these packets, 354 to reflect the behavior of the actual data traffic and measure the 355 metrics. [RFC4379] provides various mechanisms to perform LM and DM 356 measurements over ECMP networks. 358 6. Manageability Consideration 360 [RFC6374] describes manageability consideration of packet loss and 361 delay measurement for MPLS network. The defined mechanisms should be 362 reused for L3VPN PM. 364 7. Security Considerations 366 This document does not change the security properties of L3VPN. 368 8. IANA Considerations 370 This document makes no request to IANA. 372 9. References 374 9.1. Normative References 376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, March 1997. 379 9.2. Informative References 381 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 382 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 383 Tunnels", RFC 3209, December 2001. 385 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 386 Networks (VPNs)", RFC 4364, February 2006. 388 [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. 389 Matsushima, "Operations and Management (OAM) Requirements 390 for Multi-Protocol Label Switched (MPLS) Networks", RFC 391 4377, February 2006. 393 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 394 Label Switched (MPLS) Data Plane Failures", RFC 4379, 395 February 2006. 397 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 398 Specification", RFC 5036, October 2007. 400 [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 401 Operations, Administration, and Maintenance (OAM) in MPLS 402 Transport Networks", RFC 5860, May 2010. 404 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 405 Berger, "A Framework for MPLS in Transport Networks", RFC 406 5921, July 2010. 408 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 409 Measurement for MPLS Networks", RFC 6374, September 2011. 411 [RFC6375] Frost, D. and S. Bryant, "A Packet Loss and Delay 412 Measurement Profile for MPLS-Based Transport Networks", 413 RFC 6375, September 2011. 415 Authors' Addresses 416 Lianshu Zheng 417 Huawei Technologies 418 Huawei Building, No.156 Beiqing Rd. 419 Beijing 100095 420 China 422 Email: vero.zheng@huawei.com 424 Zhenbin Li 425 Huawei Technologies 426 Huawei Building, No.156 Beiqing Rd. 427 Beijing 100095 428 China 430 Email: lizhenbin@huawei.com 432 Sam K. Aldrin 433 Huawei Technologies 435 Email: aldrin.ietf@gmail.com 437 Bhavani Parise 438 Cisco Systems 440 Email: bhavani@cisco.com