idnits 2.17.1 draft-salam-l2vpn-evpn-oam-req-frmwk-02.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 (January 23, 2014) is 3739 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TRILL' is mentioned on line 116, but not defined == Missing Reference: 'RFC6136' is mentioned on line 158, but not defined == Missing Reference: 'RFC4379' is mentioned on line 326, but not defined ** Obsolete undefined reference: RFC 4379 (Obsoleted by RFC 8029) == Missing Reference: 'SPB-EVPN' is mentioned on line 183, but not defined == Missing Reference: 'RFC6425' is mentioned on line 326, but not defined == Missing Reference: 'RFC792' is mentioned on line 326, but not defined == Missing Reference: 'RFC5880' is mentioned on line 328, but not defined == Missing Reference: 'RFC5881' is mentioned on line 328, but not defined == Missing Reference: 'RFC5883' is mentioned on line 328, but not defined == Missing Reference: 'RFC5884' is mentioned on line 329, but not defined == Missing Reference: 'RFC6428' is mentioned on line 330, but not defined == Missing Reference: 'RFC2544' is mentioned on line 500, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-l2vpn-evpn-01 == Outdated reference: A later version (-10) exists of draft-ietf-l2vpn-pbb-evpn-03 == Outdated reference: A later version (-02) exists of draft-ietf-l2vpn-trill-evpn-00 == Outdated reference: A later version (-05) exists of draft-ietf-trill-oam-req-01 Summary: 1 error (**), 0 flaws (~~), 17 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Samer Salam 3 Intended Status: Informational Ali Sajassi 4 Cisco 6 Sam Aldrin 7 Huawei 9 John E. Drake 10 Juniper Networks 12 Expires: July 27, 2014 January 23, 2014 14 E-VPN Operations, Administration and Maintenance 15 Requirements and Framework 17 draft-salam-l2vpn-evpn-oam-req-frmwk-02 19 Abstract 21 This document specifies the requirements and reference framework for 22 Ethernet VPN (E-VPN) Operations, Administration and Maintenance 23 (OAM). The requirements cover the OAM aspects of E-VPN, PBB-EVPN and 24 TRILL-EVPN. The framework defines the layered OAM model encompassing 25 the E-VPN service layer, network layer and underlying Packet Switched 26 Network (PSN) transport layer. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as 36 Internet-Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/1id-abstracts.html 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 Copyright and License Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1 Relationship to Other OAM Work . . . . . . . . . . . . . . . 4 68 1.2 Specification of Requirements . . . . . . . . . . . . . . . 5 69 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2 E-VPN OAM Framework . . . . . . . . . . . . . . . . . . . . . . 5 71 2.1 OAM Layering . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2.2 E-VPN Service OAM . . . . . . . . . . . . . . . . . . . . . 7 73 2.3 E-VPN Network OAM . . . . . . . . . . . . . . . . . . . . . 7 74 2.4 Transport OAM for E-VPN . . . . . . . . . . . . . . . . . . 9 75 2.5 Link OAM . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 2.6 OAM Inter-working . . . . . . . . . . . . . . . . . . . . . 9 77 3 E-VPN OAM Requirements . . . . . . . . . . . . . . . . . . . . . 10 78 3.1 Fault Management Requirements . . . . . . . . . . . . . . . 10 79 3.1.1 Proactive Fault Management Functions . . . . . . . . . . 10 80 3.1.1.1 Fault Detection (Continuity Check) . . . . . . . . . 10 81 3.1.1.2 Defect Indication . . . . . . . . . . . . . . . . . 11 82 3.1.2 On-Demand Fault Management Functions . . . . . . . . . . 12 83 3.1.2.1 Connectivity Verification . . . . . . . . . . . . . 12 84 3.1.2.2 Fault Isolation . . . . . . . . . . . . . . . . . . 13 85 3.2 Performance Management . . . . . . . . . . . . . . . . . . . 13 86 3.2.1 Packet Loss . . . . . . . . . . . . . . . . . . . . . . 13 87 3.2.2 Packet Delay . . . . . . . . . . . . . . . . . . . . . . 14 88 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 89 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 91 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 7.1 Normative References . . . . . . . . . . . . . . . . . . . 14 93 7.2 Informative References . . . . . . . . . . . . . . . . . . 15 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 96 1 Introduction 98 This document specifies the requirements and defines a reference 99 framework for Ethernet VPN (E-VPN) Operations, Administration and 100 Maintenance (OAM, [RFC6291]). In this context, we use the term E-VPN 101 OAM to loosely refer to the OAM functions required for and/or 102 applicable to [E-VPN], [PBB-EVPN] as well as [TRILL-EVPN]. 104 E-VPN introduces an L2VPN solution for multipoint Ethernet services, 105 with advanced multi-homing capabilities, using BGP for distributing 106 customer/client MAC address reach-ability information over the core 107 MPLS/IP network. 109 PBB-EVPN combines Provider Backbone Bridging (PBB) [802.1ah] with E- 110 VPN in order to reduce the number of BGP MAC advertisement routes, 111 provide client MAC address mobility using C-MAC aggregation and B-MAC 112 sub-netting, confine the scope of C-MAC learning to only active 113 flows, offer per site policies and avoid C-MAC address flushing on 114 topology changes. 116 TRILL-EVPN provides a solution for interconnecting TRILL [TRILL] 117 networks over an MPLS/IP network using E-VPN, with two key 118 characteristics: C-MAC address transparency on the hand-off point and 119 control-plane isolation among the interconnected TRILL networks. 121 This document focuses on the fault management and performance 122 management aspects of E-VPN OAM. 124 1.1 Relationship to Other OAM Work 126 This document leverages concepts and draws upon elements defined 127 and/or used in the following documents: 129 [RFC6136] specifies the requirements and a reference model for OAM as 130 it relates to L2VPN services, pseudowires and associated Packet 131 Switched Network tunnels. This document focuses on VPLS and VPWS 132 solutions and services. 134 [RFC4379] defines mechanisms for detecting data plane failures in 135 MPLS LSPs, including procedures to check the correct operation of the 136 data plane, as well as mechanisms to verify the data plane against 137 the control plane. 139 [802.1Q] specifies the Ethernet Connectivity Fault Management (CFM) 140 protocol, which defines the concepts of Maintenance Domains, 141 Maintenance Associations, Maintenance End Points, and Maintenance 142 Intermediate Points. 144 [Y.1731] extends Connectivity Fault Management in the following 145 areas: it defines fault notification and alarm suppression functions 146 for Ethernet. It also specifies mechanisms for Ethernet performance 147 management, including loss, delay, jitter, and throughput 148 measurement. 150 1.2 Specification of Requirements 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC 2119 [RFC2119]. 156 1.3 Terminology 158 This document uses the following terminology defined in [RFC6136]: 160 MA Maintenance Association is a set of MEPs belonging to the 161 same Maintenance Domain, established to verify the 162 integrity of a single service instance. 164 MEP Maintenance End Point is responsible for origination and 165 termination of OAM frames for a given MA. 167 MIP Maintenance Intermediate Point is located between peer 168 MEPs and can process and respond to certain OAM frames 169 but does not initiate them. 171 MD Maintenance Domain, an OAM Domain that represents a 172 region over which OAM frames can operate unobstructed. 174 2 E-VPN OAM Framework 176 2.1 OAM Layering 178 Multiple layers come into play for implementing an L2VPN service 179 using the E-VPN family of solutions: 181 - The Service Layer runs end to end between the sites, or Ethernet 182 Segments, that are being interconnected by the E-VPN solution. It can 183 be either Ethernet (as in [E-VPN], [PBB-EVPN] and [SPB-EVPN]) or 184 TRILL (as in [TRILL-EVPN]). 186 - The Network Layer extends in between the E-VPN PE nodes and is 187 mostly transparent to the core nodes (except where Flow Entropy comes 188 into play). It leverages MPLS for service (i.e. EVI) multiplexing and 189 Split-Horizon functions. 191 - The Transport Layer is dictated by the networking technology of the 192 PSN. It may be either based on MPLS LSPs or IP. 194 - The Link Layer is dependent upon the physical technology used. 195 Ethernet is a popular choice for this layer, but other alternatives 196 are deployed (e.g. POS, DWDM etc...). 198 This layering extends to the set of OAM protocols that are involved 199 in the ongoing maintenance and diagnostics of E-VPN networks. The 200 figure below depicts the OAM layering, and shows which devices have 201 visibility into what OAM layer(s). 203 +---+ +---+ 204 +--+ | | +---+ +---+ +---+ | | +--+ 205 |CE|----|PE1|----| P |----| P |----| P |----|PE2|----|CE| 206 +--+ | | +---+ +---+ +---+ | | +--+ 207 +---+ +---+ 209 o--------o--------- Service OAM -------------o--------o 211 o----------- Network OAM -----------o 213 o-------o--------o---------o-------o Transport OAM 215 o-----o o-----o o-----o o-----o o-----o o-----o Link OAM 217 Figure 1: E-VPN OAM Layering 219 Figure 2 below shows an example network where native Ethernet domains 220 are interconnected via E-VPN, and the OAM mechanisms applicable at 221 each layer. The details of the layers are described in the sections 222 that follow. 224 +---+ +---+ 225 +--+ | | +---+ +---+ +---+ | | +--+ 226 |CE|----|PE1|----| P |----| P |----| P |----|PE2|----|CE| 227 +--+ | | +---+ +---+ +---+ | | +--+ 228 +---+ +---+ 230 o--------o--------- Ethernet CFM ------------o--------o 232 o-------- E-VPN Network OAM --------o 234 o-------o--------o---------o-------o MPLS OAM 236 o-----o o-----o o-----o o-----o o-----o o-----o 802.3 OAM 238 Figure 2: E-VPN OAM Example 240 2.2 E-VPN Service OAM 242 The E-VPN Service OAM protocol depends on what service layer 243 technology is being interconnected by the E-VPN solution. In case of 244 [E-VPN] and [PBB-EVPN], the service layer is Ethernet; hence, the 245 corresponding service OAM protocol is Ethernet Connectivity Fault 246 Management (CFM) [802.1Q]. Whereas, in the case of [TRILL-EVPN], the 247 service layer is TRILL and the associated service OAM protocol is 248 TRILL OAM [TRILL-OAM]. 250 E-VPN service OAM is visible to the CEs and E-VPN PEs, but not to the 251 core (P) nodes. This is because the PEs operate at the Ethernet MAC 252 layer in [E-VPN][PBB-EVPN], or the TRILL RBridge layer in [TRILL- 253 EVPN], whereas the P nodes do not. 255 The E-VPN PE MUST support MIP functions in the applicable service OAM 256 protocol (Ethernet CFM or TRILL OAM). 258 The E-VPN PE SHOULD support MEP functions in the applicable service 259 OAM protocol. This includes both Up and Down MEP functions. 261 2.3 E-VPN Network OAM 263 E-VPN Network OAM is visible to the PE nodes only. This OAM layer is 264 analogous to VCCV [RFC5085] in the case of VPLS/VPWS. It provides 265 mechanisms to check the correct operation of the data plane, as well 266 as a mechanism to verify the data plane against the control plane. 267 This includes the ability to perform fault detection and diagnostics 268 on: 270 - the MP2P tunnels used for the transport of unicast traffic between 271 PEs. E-VPN allows for three different models of unicast label 272 assignment: label per EVI, label per and label 273 per MAC address. In all three models, the label is bound to an E-VPN 274 Unicast FEC. 276 E-VPN Network OAM MUST provide mechanisms to check the operation of 277 the data plane and verify that operation against the control plane 278 view for the E-VPN Unicast FEC. 280 - the MP2P tunnels used for aliasing unicast traffic destined to a 281 multi-homed Ethernet Segment. The three label assignment models, 282 discussed above, apply here as well. In all three models, the label 283 is bound to an E-VPN Aliasing FEC. E-VPN Network OAM MUST provide 284 mechanisms to check the operation of the data plane and verify that 285 operation against the control plane view for the E-VPN Aliasing FEC. 287 - the multicast tunnels (either MP2P or P2MP) used for the transport 288 of broadcast, unknown unicast and multicast traffic between PEs. In 289 the case of ingress replication, a label is allocated per EVI or per 290 and is bound to an E-VPN Multicast FEC. In the 291 case of LSM, and more specifically aggregate inclusive trees, again a 292 label may be allocated per EVI or per and is 293 bound to an E-VPN Multicast FEC. 295 E-VPN Network OAM MUST provide mechanisms to check the operation of 296 the data plane and verify that operation against the control plane 297 view for the E-VPN Multicast FEC. 299 - the correct operation of the ESI split-horizon filtering function. 300 In E-VPN, a label is allocated per multi-homed Ethernet Segment for 301 the purpose of performing the access split-horizon enforcement. The 302 label is bound to an E-VPN Ethernet Segment FEC. 304 E-VPN Network OAM MUST provide mechanisms to check the operation of 305 the data plane and verify that operation against the control plane 306 view for the E-VPN Ethernet Segment FEC. 308 - the correct operation of the DF filtering function. 310 E-VPN Network OAM MUST provide provide mechanisms to check the 311 operation of the data plane and verify that operation against the 312 control plane view for the DF filtering function. 314 E-VPN network OAM mechanisms MUST provide in-band management 315 capabilities. As such, OAM messages MUST be encoded so that they 316 exhibit identical entropy characteristics to data traffic. 318 E-VPN network OAM SHOULD provide both proactive and on-demand 319 mechanisms of monitoring the data plane operation and data plane 320 conformance to the state of the control plane. 322 2.4 Transport OAM for E-VPN 324 The transport OAM protocol depends on the nature of the underlying 325 transport technology in the PSN. MPLS OAM mechanisms 326 [RFC4379][RFC6425] as well as ICMP [RFC792] are applicable, depending 327 on whether the PSN employs MPLS or IP transport, respectively. 328 Furthermore, BFD mechanisms per [RFC5880], [RFC5881], [RFC5883] and 329 [RFC5884] apply. Also, the BFD mechanisms pertaining to MPLS-TP LSPs 330 per [RFC6428] are applicable. 332 2.5 Link OAM 334 Link OAM depends on the data link technology being used between the 335 PE and P nodes. For e.g., if Ethernet links are employed, then 336 Ethernet Link OAM [802.3] Clause 57 may be used. 338 2.6 OAM Inter-working 340 When inter-working two networking domains, such as native Ethernet 341 and E-VPN to provide an end-to-end emulated service, there is a need 342 to identify the failure domain and location, even when a PE supports 343 both the Service OAM mechanisms and the E-VPN Network OAM mechanisms. 344 In addition, scalability constraints may not allow running proactive 345 monitoring, such as Ethernet Continuity Check Messages (CCMs), at a 346 PE to detect the failure of an EVI across the E-VPN domain. Thus, the 347 mapping of alarms generated upon failure detection in one domain 348 (e.g. native Ethernet or E-VPN network domain) to the other domain is 349 needed. There are also cases where a PE may not be able to process 350 Service OAM messages received from a remote PE over the PSN even when 351 such messages are defined, as in the Ethernet case, thereby 352 necessitating support for fault notification message mapping between 353 the E-VPN Network domain and the Service domain. 355 OAM inter-working is not limited though to scenarios involving 356 disparate network domains. It is possible to perform OAM inter- 357 working across different layers in the same network domain. In 358 general, alarms generated within an OAM layer, as a result of 359 proactive fault detection mechanisms, may be injected into its client 360 layer OAM mechanisms. This allows the client layer OAM to trigger 361 event-driven (i.e. asynchronous) fault notifications. For example, 362 alarms generated by the Link OAM mechanisms may be injected into the 363 Transport OAM layer, and alarms generated by the Transport OAM 364 mechanism may be injected into the Network OAM mechanism, and so on. 366 E-VPN OAM MUST support inter-working between the Network OAM and 367 Service OAM mechanisms. E-VPN OAM MAY support inter-working among 368 other OAM layers. 370 3 E-VPN OAM Requirements 372 This section discusses the E-VPN OAM requirements pertaining to Fault 373 Management and Performance Management. 375 3.1 Fault Management Requirements 377 3.1.1 Proactive Fault Management Functions 379 Proactive fault management functions are configured by the network 380 operator to run periodically without a time bound. Certain actions, 381 e.g. protection switchover or alarm indication signaling, can be 382 associated with specific events, such as entering or clearing fault 383 states. 385 3.1.1.1 Fault Detection (Continuity Check) 387 Proactive fault detection is performed by periodically monitoring the 388 reachability between service endpoints, i.e. MEPs in a given MA, 389 through the exchange of Continuity Check messages. The reachability 390 between any two arbitrary MEPs may be monitored for: 392 - in-band per-flow monitoring. This enables per flow monitoring 393 between MEPs. E-VPN Network OAM MUST support fault detection with per 394 user flow granularity. E-VPN Service OAM MAY support fault detection 395 with per user flow granularity. 397 - a representative path. This enables liveness check of the nodes 398 hosting the MEPs assuming that the loss of continuity to the MEP is 399 interpreted as a failure of the hosting node. This, however, does not 400 conclusively indicate liveness of the path(s) taken by user data 401 traffic. This enables node failure detection but not path failure 402 detection, through the use of a test flow. E-VPN Network OAM and 403 Service OAM MUST support fault detection using test flows. 405 - all paths. For MPLS/IP networks with ECMP, monitoring of all 406 unicast paths between MEPs (on non-adjacent nodes) may not be 407 possible, since the per-hop ECMP hashing behavior may yield 408 situations where it is impossible for a MEP to pick flow entropy 409 characteristics that result in exercising the exhaustive set of ECMP 410 paths. Monitoring of all ECMP paths between MEPs (on non-adjacent 411 nodes) is not a requirement for E-VPN OAM. 413 The fact that MPLS/IP networks do not enforce congruency between 414 unicast and multicast paths means that the proactive fault detection 415 mechanisms for E-VPN network OAM MUST provide procedures to monitor 416 the unicast paths independently of the multicast paths. This applies 417 to E-VPN Service OAM and Network OAM. 419 3.1.1.2 Defect Indication 421 E-VPN Service OAM MUST support event-driven defect indication upon 422 the detection of a connectivity defect. Defect indications can be 423 categorized into two types: forward and reverse defect indications. 425 3.1.1.2.1 Forward Defect Indication 427 This is used to signal a failure that is detected by a lower layer 428 OAM mechanism. Forward Defect indication is transmitted by a server 429 MEP (i.e. an actual or virtual MEP) in a direction that is away from 430 the direction of the failure (refer to Figure 2 below). 432 Failure 433 | 434 +-----+ +-----+ V +-----+ +-----+ 435 | A |------| B |--XXX--| C |------| D | 436 +-----+ +-----+ +-----+ +-----+ 438 <===========| |============> 439 Forward Forward 440 Defect Defect 441 Indication Indication 443 Figure 3: Forward Defect Indication 445 Forward defect indication may be used for alarm suppression and/or 446 for purpose of inter-working with other layer OAM protocols. Alarm 447 suppression is useful when a transport/network level fault translates 448 to multiple service or flow level faults. In such a scenario, it is 449 enough to alert a network management station (NMS) of the single 450 transport/network level fault in lieu of flooding that NMS with a 451 multitude of Service or Flow granularity alarms. E-VPN PEs SHOULD 452 support Forward Defect Indication in the Service OAM mechanisms. 454 3.1.1.2.2 Reverse Defect Indication (RDI) 456 RDI is used to signal that the advertising MEP has detected a loss of 457 continuity (LoC) defect. RDI is transmitted in the direction of the 458 failure (refer to Figure 3). 460 Failure 461 | 462 +-----+ +-----+ V +-----+ +-----+ 463 | A |------| B |--XXX--| C |------| D | 464 +-----+ +-----+ +-----+ +-----+ 466 |===========> <============| 467 Reverse Reverse 468 Defect Defect 469 Indication Indication 471 Figure 3: Reverse Defect Indication 473 RDI allows single-sided management, where the network operator can 474 examine the state of a single MEP and deduce the overall health of a 475 monitored service. E-VPN PEs SHOULD support Reverse Defect Indication 476 in the Service OAM mechanisms. This includes both the ability to 477 signal LoC defect to a remote MEP, as well as the ability to 478 recognize RDI from a remote MEP. It is worth noting that, in a 479 multipoint MA, RDI is not a useful indicator of unidirectional fault. 480 This is because RDI carries no indication of the affected MEP(s) with 481 which the sender had detected a LoC defect. 483 3.1.2 On-Demand Fault Management Functions 485 On-demand fault management functions are initiated manually by the 486 network operator and continue for a time bound period. These 487 functions enable the operator to run diagnostics to investigate a 488 defect condition. 490 3.1.2.1 Connectivity Verification 492 E-VPN Network OAM MUST support on-demand connectivity verification 493 mechanisms for unicast and multicast destinations. The connectivity 494 verification mechanisms SHOULD provide a means for specifying and 495 carrying in the messages: 497 - variable length payload/padding to test MTU related connectivity 498 problems. 500 - test frame formats as defined in Appendix C of [RFC2544] to detect 501 potential packet corruption. 503 E-VPN Network OAM MUST support connectivity verification at per flow 504 granularity. This includes both user flows (to test a specific path 505 between PEs) as well as test flows (to rest a representative path 506 between PEs). 508 E-VPN Service OAM MUST support connectivity verification on test 509 flows and MAY support connectivity verification on user flows. 511 For multicast connectivity verification, E-VPN Network OAM MUST 512 support reporting on: 514 - the DF filtering status of specific port(s) or all the ports in a 515 given bridge-domain. 517 - the Split Horizon filtering status of specific port(s) or all the 518 ports in a given bridge-domain. 520 3.1.2.2 Fault Isolation 522 E-VPN OAM MUST support an on-demand fault localization function. This 523 involves the capability to narrow down the locality of a fault to a 524 particular port, link or node. The characteristic of forward/reverse 525 path asymmetry, in MPLS/IP, renders fault isolation into a direction- 526 sensitive operation. That is, given two PEs A and B, localization of 527 continuity failures between them requires running fault isolation 528 procedures from PE A to PE B as well as from PE B to PE A. 530 E-VPN Service OAM mechanisms only have visibility to the PEs but not 531 the MPLS/IP P nodes. As such, they can be used to deduce whether the 532 fault is in the customer's own network, the local CE-PE segment or 533 remote CE-PE segment(s). E-VPN Network and Transport OAM mechanisms 534 can be used for fault isolation between the PEs and P nodes. 536 3.2 Performance Management 538 Performance Management functions can be performed both proactively 539 and on-demand. Proactive management involves a recurring function, 540 where the performance management probes are run continuously without 541 a trigger. We cover both proactive and on-demand functions in this 542 section. 544 3.2.1 Packet Loss 546 E-VPN Network OAM SHOULD provide mechanisms for measuring packet loss 547 for a given service. 549 Given that E-VPN provides inherent support for multipoint-to- 550 multipoint connectivity, then packet loss cannot be accurately 551 measured by means of counting user data packets. This is because user 552 packets can be delivered to more PEs or more ports than are necessary 553 (e.g. due to broadcast, un-pruned multicast or unknown unicast 554 flooding). As such, a statistical means of approximating packet loss 555 rate is required. This can be achieved by sending "synthetic" OAM 556 packets that are counted only by those ports (MEPs) that are required 557 to receive them. This provides a statistical approximation of the 558 number of data frames lost, even with multipoint-to-multipoint 559 connectivity. 561 3.2.2 Packet Delay 563 E-VPN Service OAM SHOULD support measurement of one-way and two-way 564 packet delay and delay variation (jitter) across the E-VPN network. 565 Measurement of one-way delay requires clock synchronization between 566 the probe source and target devices. Mechanisms for clock 567 synchronization are outside the scope of this document. Note that 568 Service OAM performance management mechanisms defined in [Y.1731] and 569 [TRILL-LOSS-DELAY] can be used. 571 E-VPN Network OAM MAY support measurement of one-way and two-way 572 packet delay and delay variation (jitter) across the E-VPN network. 574 4. Security Considerations 576 E-VPN OAM must provide mechanisms for: 578 - Preventing denial of service attacks caused by exploitation of the 579 OAM message channel. 581 - Optionally authenticate communicating endpoints (MEPs and MIPs) 583 - Preventing OAM packets from leaking outside of the E-VPN network or 584 outside their corresponding Maintenance Domain. This can be done by 585 having MEPs implement a filtering function based on the Maintenance 586 Level associated with received OAM packets. 588 5. Acknowledgements 590 The authors would like to thank Gregory Mirsky for his thorough 591 review of this work and invaluable comments. 593 6. IANA Considerations 595 None. 597 7. References 599 7.1 Normative References 601 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 602 Requirement Levels", BCP 14, RFC 2119, March 1997. 604 [RFC6291] Andersson et al., BCP 161 "Guidelines for the Use of the 605 "OAM" Acronym in the IETF", June 2011. 607 [E-VPN] Sajassi et al., "BGP MPLS Based Ethernet VPN", draft-ietf- 608 l2vpn-evpn-01.txt, work in progress, July 2012. 610 [PBB-EVPN] Sajassi et al., "PBB-EVPN", draft-ietf-l2vpn-pbb-evpn- 611 03.txt, work in progress, June 2012. 613 [TRILL-EVPN] Sajassi et al., "TRILL-EVPN", draft-ietf-l2vpn-trill- 614 evpn-00.txt, work in progress, June 2012. 616 7.2 Informative References 618 [802.1Q] "IEEE Standard for Local and metropolitan area networks - 619 Media Access Control (MAC) Bridges and Virtual Bridge Local Area 620 Networks", 31 August 2011. 622 [Y.1731] "ITU-T Recommendation Y.1731 (02/08) - OAM functions and 623 mechanisms for Ethernet based networks", February 2008. 625 [TRILL-OAM] Senevirathne et al., "Requirements for Operations, 626 Administration and Maintenance (OAM) in TRILL", draft-ietf-trill-oam- 627 req-01.txt, work in progress, August 2012. 629 [RFC5085] Nadeau et al., "Pseudowire Virtual Circuit Connectivity 630 Verification (VCCV): A Control Channel for Pseudowires", December 631 2007. 633 [TRILL-LOSS-DELAY] Mizrahi et al., "Loss and Delay Measurement in 634 TRILL", draft-mizrahi-trill-loss-delay, work in progress, February 635 2013. 637 Authors' Addresses 639 Samer Salam 640 Cisco 641 595 Burrard Street, Suite 2123 642 Vancouver, BC V7X 1J1, Canada 643 Email: ssalam@cisco.com 645 Ali Sajassi 646 Cisco 647 170 West Tasman Drive 648 San Jose, CA 95134, USA 649 Email: sajassi@cisco.com 650 Sam Aldrin 651 Huawei Technologies 652 2330 Central Express Way 653 Santa Clara, CA 95951, USA 654 Email: aldrin.ietf@gmail.com 656 John E. Drake 657 Juniper Networks 658 1194 N. Mathilda Ave. 659 Sunnyvale, CA 94089, USA 660 Email: jdrake@juniper.net