idnits 2.17.1 draft-ietf-bess-evpn-oam-req-frmwk-08.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 (April 6, 2021) is 1116 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Samer Salam 2 Intended Status: Informational Ali Sajassi 3 Cisco 4 Sam Aldrin 5 Google 6 John E. Drake 7 Juniper 8 Donald Eastlake 9 Futurewei 10 Expires: October 5, 2021 April 6, 2021 12 EVPN Operations, Administration and Maintenance 13 Requirements and Framework 14 draft-ietf-bess-evpn-oam-req-frmwk-08 16 Abstract 18 This document specifies the requirements and reference framework for 19 Ethernet VPN (EVPN) Operations, Administration and Maintenance (OAM). 20 The requirements cover the OAM aspects of EVPN and PBB-EVPN (Provider 21 Backbone Bridge EVPN). The framework defines the layered OAM model 22 encompassing the EVPN service layer, network layer, underlying Packet 23 Switched Network (PSN) transport layer, and link layer but focuses on 24 the service and network layers. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 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 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 43 Shadow Directories can be accessed at http://www.ietf.org/shadow.html 45 Copyright and License Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction............................................4 63 1.1 Relationship to Other OAM Work.........................4 64 1.2 Specification of Requirements..........................5 65 1.3 Terminology............................................5 67 2. EVPN OAM Framework......................................7 68 2.1 OAM Layering...........................................7 69 2.2 EVPN Service OAM.......................................8 70 2.3 EVPN Network OAM.......................................9 71 2.4 Transport OAM for EVPN................................10 72 2.5 Link OAM..............................................11 73 2.6 OAM Inter-working.....................................11 75 3. EVPN OAM Requirements..................................12 76 3.1 Fault Management Requirements.........................12 77 3.1.1 Proactive Fault Management Functions................12 78 3.1.1.1 Fault Detection (Continuity Check)................12 79 3.1.1.2 Defect Indication.................................13 80 3.1.1.2.1 Forward Defect Indication.......................13 81 3.1.1.2.2 Reverse Defect Indication (RDI).................14 82 3.1.2 On-Demand Fault Management Functions................14 83 3.1.2.1 Connectivity Verification.........................14 84 3.1.2.2 Fault Isolation...................................15 85 3.2 Performance Management................................15 86 3.2.1 Packet Loss.........................................16 87 3.2.2 Packet Delay and Jitter.............................16 89 4. Security Considerations................................17 90 5. IANA Considerations....................................17 92 6. Acknowledgements.......................................17 94 Normative References......................................18 95 Informative References....................................19 97 1. Introduction 99 This document specifies the requirements and defines a reference 100 framework for Ethernet VPN (EVPN) Operations, Administration and 101 Maintenance (OAM, [RFC6291]). In this context, we use the term EVPN 102 OAM to loosely refer to the OAM functions required for and/or 103 applicable to [RFC7432] and [RFC7623]. 105 EVPN is an Layer 2 VPN (L2VPN) solution for multipoint Ethernet 106 services, with advanced multi-homing capabilities, using BGP for 107 distributing customer/client MAC address reachability information 108 over the core MPLS/IP network. 110 PBB-EVPN combines Provider Backbone Bridging (PBB) [802.1Q] with EVPN 111 in order to reduce the number of BGP MAC advertisement routes, 112 provide client MAC address mobility using C-MAC aggregation and B-MAC 113 sub-netting, confine the scope of C-MAC learning to only active 114 flows, offer per site policies, and avoid C-MAC address flushing on 115 topology changes. 117 This document focuses on the fault management and performance 118 management aspects of EVPN OAM. It defines the layered OAM model 119 encompassing the EVPN service layer, network layer, underlying Packet 120 Switched Network (PSN) transport layer, and link layer but focuses on 121 the service and network layers. 123 1.1 Relationship to Other OAM Work 125 This document leverages concepts and draws upon elements defined 126 and/or used in the following documents: 128 [RFC6136] specifies the requirements and a reference model for OAM as 129 it relates to L2VPN services, pseudowires and associated Packet 130 Switched Network (PSN) tunnels. This document focuses on VPLS and 131 VPWS solutions and services. 133 [RFC8029] defines mechanisms for detecting data plane failures in 134 MPLS LSPs, including procedures to check the correct operation of the 135 data plane, as well as mechanisms to verify the data plane against 136 the control plane. 138 [802.1Q] specifies the Ethernet Connectivity Fault Management (CFM) 139 protocol, which defines the concepts of Maintenance Domains, 140 Maintenance Associations, Maintenance End Points, and Maintenance 141 Intermediate Points. 143 [Y.1731] extends Connectivity Fault Management in the following 144 areas: it defines fault notification and alarm suppression functions 145 for Ethernet. It also specifies mechanisms for Ethernet performance 146 management, including loss, delay, jitter, and throughput 147 measurement. 149 1.2 Specification of Requirements 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in BCP 154 14 [RFC2119] [RFC8174] when, and only when, they appear in all 155 capitals, as shown here. 157 1.3 Terminology 159 This document uses the following terminology much of which is defined 160 in [RFC6136]: 162 CE Customer Edge device, e.g., a host, router, or switch. 164 DF Designated Forwarder 166 Down MEP A MEP that originates traffic away from and terminates 167 traffic towards the device in whose port it is logically 168 located. 170 EVI An EVPN instance spanning the Provider Edge (PE) devices 171 participating in that EVPN. 173 L2VPN Layer 2 VPN. 175 MA Maintenance Association is a set of MEPs belonging to the same 176 Maintenance Domain, established to verify the integrity of a 177 single service instance. 179 MEP Maintenance End Point is responsible for origination and 180 termination of OAM frames for a given MA. A MEP is logically 181 located in a device's port. 183 MIP Maintenance Intermediate Point is located between peer MEPs and 184 can process and respond to certain OAM frames but does not 185 initiate them. A MIP is logically located in a device's port. 187 MD Maintenance Domain, an OAM Domain that represents a region over 188 which OAM frames can operate unobstructed. 190 MP2P Multipoint to Point. 192 P Provider (non-edge) device. 194 P2MP Point to Multipoint. 196 PBB Provider Backbone Bridge. 198 PE Provider Edge device. 200 Up MEP A MEP that originates traffic towards and terminates traffic 201 from the device in whose port it is logically located. 203 VPN Virtual Private Network 205 2. EVPN OAM Framework 207 2.1 OAM Layering 209 Multiple layers come into play for implementing an L2VPN service 210 using the EVPN family of solutions as listed below. The focus of this 211 document is the Service and Network layers. 213 - The Service Layer runs end to end between the sites or Ethernet 214 Segments that are being interconnected by the EVPN solution. 216 - The Network Layer extends between the EVPN PE (Provider Edge) nodes 217 and is mostly transparent to the core P (Provider) nodes (except 218 where Flow Entropy comes into play). It leverages MPLS for service 219 (i.e., EVI) multiplexing and Split-Horizon functions. 221 - The Transport Layer is dictated by the networking technology of the 222 PSN. It may be either based on MPLS LSPs or IP. 224 - The Link Layer is dependent upon the physical technology used. 225 Ethernet is a popular choice for this layer, but other alternatives 226 are deployed (e.g., POS, DWDM etc.). 228 This layering extends to the set of OAM protocols that are involved 229 in the ongoing maintenance and diagnostics of EVPN networks. Figure 1 230 below depicts the OAM layering, and shows which devices have 231 visibility into what OAM layer(s). 233 +---+ +---+ 234 +--+ | | +---+ +---+ +---+ | | +--+ 235 |CE|----|PE1|----| P |----| P |----| P |----|PE2|----|CE| 236 +--+ | | +---+ +---+ +---+ | | +--+ 237 +---+ +---+ 239 o--------o---------- Service OAM ------------o--------o 241 o----------- Network OAM -----------o 243 o--------o--------o--------o--------o Transport OAM 245 o----o o----o o----o o----o o----o o----o Link OAM 247 Figure 1: OAM Layering 249 Service OAM and Network OAM mechanisms only have visibility to the PE 250 (Provider Edge) nodes but not the P nodes (Provider network interior 251 nodes). As such, they can be used to deduce whether the fault is in 252 the customer's own network, the local CE-PE segment, the PE-PE 253 segment or the remote CE-PE segment(s). EVPN Transport OAM mechanisms 254 can be used for fault isolation between the PEs and P nodes. 256 Figure 2 below shows an example network where native Ethernet domains 257 are interconnected via EVPN using MPLS and gives the OAM mechanisms 258 applicable at each layer. The details of the layers are described in 259 the sections below. 261 +---+ +---+ 262 +--+ | | +---+ +---+ +---+ | | +--+ 263 |CE|----|PE1|----| P |----| P |----| P |----|PE2|----|CE| 264 +--+ | | +---+ +---+ +---+ | | +--+ 265 +---+ +---+ 267 o--------o---------- Service CFM ------------o--------o 269 o-------- EVPN Network OAM ---------o 271 o--------o--------o--------o--------o MPLS OAM 273 o----o o----o o----o o----o o----o o----o 802.3 OAM 275 Figure 2: EVPN OAM Example 277 2.2 EVPN Service OAM 279 The EVPN Service OAM protocol depends on what service layer 280 technology is being interconnected by the EVPN solution. In case of 281 [RFC7432] and [RFC7623], the service layer is Ethernet; hence, the 282 corresponding service OAM protocol is Ethernet Connectivity Fault 283 Management (CFM) [802.1Q]. 285 EVPN service OAM is visible to the CEs and EVPN PEs, but not to the 286 core (P) nodes. This is because the PEs operate at the Ethernet MAC 287 layer in [RFC7432] [RFC7623] whereas the P nodes do not. 289 The EVPN PE MUST support MIP functions in the applicable service OAM 290 protocol, for example Ethernet CFM. The EVPN PE SHOULD support MEP 291 functions in the applicable service OAM protocol. This includes both 292 Up and Down MEP functions. 294 As shown in Figure 3, the MIP and MEP functions being referred to are 295 logically located within the device's port operating at the customer 296 level. (There could be MEPs/MIPs within PE ports facing the provider 297 network but they would not be relevant to EVPN Service OAM as the 298 traffic passing through them will be encapsulated/tunneled so any 299 customer level OAM messages will just be treated as data.) Down MEP 300 functions are away from the device while up MEP functions are towards 301 the device (towards the PE forwarding mechanism in the case of a PE). 302 OAM messages between the PE Up MEPs shown are a type of EVPN Network 303 OAM while such messages between the CEs or from a PE to its local CE 304 or to the remote CE are Service OAM. 306 +-------+ +----------------+ +----------------+ +-------+ 307 |+-----+| |+--------------+| |+--------------+| |+-----+| 308 || CE || || PE1 || ... || PE2 || || CE || 309 |+--+--+| |+---+--------+-+| |+-+--------+---+| |+--+--+| 310 | | | | | | | | | | | | | | 311 |+--+--+| |+---+-----+ . | | . +-----+---+| |+--+--+| 312 || MEP || || | Up^ | . | ... | . |Up^ | || || MEP || 313 ||DownV|| ||MIP|MEP | . | | . |MEP |MIP|| ||downV|| 314 |+--+--+| || |DownV| . | | . |DownV| || |+--+--+| 315 | | | |+---+-----+ | | | | +-----+---+| | | | 316 +---|---+ +----|--------|--+ +--|--------|----+ +---|---+ 317 | | | | | | 318 +------------+ +--- ... ---+ +------------+ 320 Figure 3: CFM Details 322 The EVPN PE MUST learn the MAC address of locally attached CE MEPs by 323 snooping on CFM frames and advertising them to remote PEs as a MAC/IP 324 Advertisement route. 326 The EVPN PE SHOULD advertise any MEP/MIP local to the PE as a MAC/IP 327 Advertisement route. Since these are not subject to mobility, they 328 SHOULD be advertised with the static (sticky) bit set (see Section 329 15.2 of [RFC7432]). 331 2.3 EVPN Network OAM 333 EVPN Network OAM is visible to the PE nodes only. This OAM layer is 334 analogous to VCCV [RFC5085] in the case of VPLS/VPWS. It provides 335 mechanisms to check the correct operation of the data plane, as well 336 as a mechanism to verify the data plane against the control plane. 337 This includes the ability to perform fault detection and diagnostics 338 on: 340 - the MP2P tunnels used for the transport of unicast traffic between 341 PEs. EVPN allows for three different models of unicast label 342 assignment: label per EVI, label per and label 343 per MAC address. In all three models, the label is bound to an EVPN 344 Unicast FEC. EVPN Network OAM MUST provide mechanisms to check the 345 operation of the data plane and verify that operation against the 346 control plane view. 348 - the MP2P tunnels used for aliasing unicast traffic destined to a 349 multi-homed Ethernet Segment. The three label assignment models, 350 discussed above, apply here as well. In all three models, the label 351 is bound to an EVPN Aliasing FEC. EVPN Network OAM MUST provide 352 mechanisms to check the operation of the data plane and verify that 353 operation against the control plane view. 355 - the multicast tunnels (either MP2P or P2MP) used for the transport 356 of broadcast, unknown unicast and multicast traffic between PEs. In 357 the case of ingress replication, a label is allocated per EVI or 358 per and is bound to an EVPN Multicast FEC. In 359 the case of LSM (Label Switched Multicast), and more specifically 360 aggregate inclusive trees, again a label may be allocated per EVI 361 or per and is bound to the tunnel FEC. 363 - the correct operation of the ESI split-horizon filtering function. 364 In EVPN, a label is allocated per multi-homed Ethernet Segment for 365 the purpose of performing the access split-horizon enforcement. The 366 label is bound to an EVPN Ethernet Segment. 368 - the correct operation of the DF (Designated Forwarder) filtering 369 function. EVPN Network OAM MUST provide mechanisms to check the 370 operation of the data plane and verify that operation against the 371 control plane view for the DF filtering function. 373 EVPN Network OAM mechanisms MUST provide in-band monitoring 374 capabilities. As such, OAM messages MUST be encoded so that they 375 exhibit identical entropy characteristics to data traffic in order 376 that they share the same fate. 378 EVPN Network OAM SHOULD provide both proactive and on-demand 379 mechanisms of monitoring the data plane operation and data plane 380 conformance to the state of the control plane. 382 2.4 Transport OAM for EVPN 384 The transport OAM protocol depends on the nature of the underlying 385 transport technology in the PSN. MPLS OAM mechanisms [RFC8029] 386 [RFC6425] as well as ICMP [RFC792] / ICMPv6 [RFC4443] are applicable, 387 depending on whether the PSN employs MPLS or IP transport, 388 respectively. Furthermore, BFD mechanisms per [RFC5880], [RFC5881], 389 [RFC5883] and [RFC5884] apply. Also, the BFD mechanisms pertaining to 390 MPLS-TP LSPs per [RFC6428] are applicable. 392 2.5 Link OAM 394 Link OAM depends on the data link technology being used between the 395 PE and P nodes. For example, if Ethernet links are employed, then 396 Ethernet Link OAM ([802.3] Clause 57) may be used. 398 2.6 OAM Inter-working 400 When inter-working two networking domains, such as native Ethernet 401 and EVPN to provide an end-to-end emulated service, there is a need 402 to identify the failure domain and location, even when a PE supports 403 both the Service OAM mechanisms and the EVPN Network OAM mechanisms. 404 In addition, scalability constraints may not allow running proactive 405 monitoring, such as Ethernet Continuity Check Messages (CCMs), at a 406 PE to detect the failure of an EVI across the EVPN domain. Thus, the 407 mapping of alarms generated upon failure detection in one domain 408 (e.g., native Ethernet or EVPN network domain) to the other domain is 409 needed. There are also cases where a PE may not be able to process 410 Service OAM messages received from a remote PE over the PSN even when 411 such messages are defined, as in the Ethernet case, thereby 412 necessitating support for fault notification message mapping between 413 the EVPN Network domain and the Service domain. 415 OAM inter-working is not limited though to scenarios involving 416 disparate network domains. It is possible to perform OAM inter- 417 working across different layers in the same network domain. In 418 general, alarms generated within an OAM layer, as a result of 419 proactive fault detection mechanisms, may be injected into its client 420 layer OAM mechanisms. This allows the client layer OAM to trigger 421 event-driven (i.e., asynchronous) fault notifications. For example, 422 alarms generated by the Link OAM mechanisms may be injected into the 423 Transport OAM layer, and alarms generated by the Transport OAM 424 mechanism may be injected into the Network OAM mechanism, and so on. 426 EVPN OAM MUST support inter-working between the Network OAM and 427 Service OAM mechanisms. EVPN OAM MAY support inter-working among 428 other OAM layers. 430 3. EVPN OAM Requirements 432 This section discusses the EVPN OAM requirements pertaining to Fault 433 Management and Performance Management. 435 3.1 Fault Management Requirements 437 3.1.1 Proactive Fault Management Functions 439 The network operator configures proactive fault management functions 440 to run periodically without a time bound. Certain actions, for 441 example protection switchover or alarm indication signaling, can be 442 associated with specific events, such as entering or clearing fault 443 states. 445 3.1.1.1 Fault Detection (Continuity Check) 447 Proactive fault detection is performed by periodically monitoring the 448 reachability between service endpoints, i.e., MEPs in a given MA, 449 through the exchange of Continuity Check messages. The reachability 450 between any two arbitrary MEPs may be monitored for: 452 - in-band per-flow monitoring. This enables per flow monitoring 453 between MEPs. EVPN Network OAM MUST support fault detection with 454 per user flow granularity. EVPN Service OAM MAY support fault 455 detection with per user flow granularity. 457 - a representative path. This enables liveness check of the nodes 458 hosting the MEPs assuming that the loss of continuity to the MEP is 459 interpreted as a failure of the hosting node. This, however, does 460 not conclusively indicate liveness of the path(s) taken by user 461 data traffic. This enables node failure detection but not path 462 failure detection, through the use of a test flow. EVPN Network OAM 463 and Service OAM MUST support fault detection using test flows. 465 - all paths. For MPLS/IP networks with ECMP, monitoring of all 466 unicast paths between MEPs (on non-adjacent nodes) may not be 467 possible, since the per-hop ECMP hashing behavior may yield 468 situations where it is impossible for a MEP to pick flow entropy 469 characteristics that result in exercising the exhaustive set of 470 ECMP paths. Monitoring of all ECMP paths between MEPs (on non- 471 adjacent nodes) is not a requirement for EVPN OAM. 473 The fact that MPLS/IP networks do not enforce congruency between 474 unicast and multicast paths means that the proactive fault detection 475 mechanisms for EVPN networks MUST provide procedures to monitor the 476 unicast paths independently of the multicast paths. This applies to 477 EVPN Service OAM and Network OAM. 479 3.1.1.2 Defect Indication 481 Defect indications can be categorized into two types: forward and 482 reverse defect indications as described below. EVPN Service OAM MUST 483 support at least one of these types of event-driven defect indication 484 upon the detection of a connectivity defect. 486 3.1.1.2.1 Forward Defect Indication 488 This is used to signal a failure that is detected by a lower layer 489 OAM mechanism. A server MEP (i.e., an actual or virtual MEP) 490 transmits a Forward Defect Indication in a direction that is away 491 from the direction of the failure (refer to Figure 4 below). 493 Failure 494 | 495 +-----+ +-----+ V +-----+ +-----+ 496 | A |------| B |--XXX--| C |------| D | 497 +-----+ +-----+ +-----+ +-----+ 499 <===========| |============> 500 Forward Forward 501 Defect Defect 502 Indication Indication 504 Figure 4: Forward Defect Indication 506 Forward defect indication may be used for alarm suppression and/or 507 for purpose of inter-working with other layer OAM protocols. Alarm 508 suppression is useful when a transport/network level fault translates 509 to multiple service or flow level faults. In such a scenario, it is 510 enough to alert a network management station (NMS) of the single 511 transport/network level fault in lieu of flooding that NMS with a 512 multitude of Service or Flow granularity alarms. EVPN PEs SHOULD 513 support Forward Defect Indication in the Service OAM mechanisms. 515 3.1.1.2.2 Reverse Defect Indication (RDI) 517 RDI is used to signal that the advertising MEP has detected a loss of 518 continuity (LoC) defect. RDI is transmitted in the direction of the 519 failure (refer to Figure 5). 521 Failure 522 | 523 +-----+ +-----+ V +-----+ +-----+ 524 | A |------| B |--XXX--| C |------| D | 525 +-----+ +-----+ +-----+ +-----+ 527 |===========> <============| 528 Reverse Reverse 529 Defect Defect 530 Indication Indication 532 Figure 5: Reverse Defect Indication 534 RDI allows single-sided management, where the network operator can 535 examine the state of a single MEP and deduce the overall health of a 536 monitored service. EVPN PEs SHOULD support Reverse Defect Indication 537 in the Service OAM mechanisms. This includes both the ability to 538 signal LoC defect to a remote MEP, as well as the ability to 539 recognize RDI from a remote MEP. Note that, in a multipoint MA, RDI 540 is not a useful indicator of unidirectional fault. This is because 541 RDI carries no indication of the affected MEP(s) with which the 542 sender had detected a LoC defect. 544 3.1.2 On-Demand Fault Management Functions 546 On-demand fault management functions are initiated manually by the 547 network operator and continue for a time bound period. These 548 functions enable the operator to run diagnostics to investigate a 549 defect condition. 551 3.1.2.1 Connectivity Verification 553 EVPN Network OAM MUST support on-demand connectivity verification 554 mechanisms for unicast and multicast destinations. The connectivity 555 verification mechanisms SHOULD provide a means for specifying and 556 carrying in the messages: 558 - variable length payload/padding to test MTU related connectivity 559 problems. 561 - test frame formats as defined in Appendix C of [RFC2544] to detect 562 potential packet corruption. 564 EVPN Network OAM MUST support connectivity verification at per flow 565 granularity. This includes both user flows (to test a specific path 566 between PEs) as well as test flows (to test a representative path 567 between PEs). 569 EVPN Service OAM MUST support connectivity verification on test flows 570 and MAY support connectivity verification on user flows. 572 For multicast connectivity verification, EVPN Network OAM MUST 573 support reporting on: 575 - the DF filtering status of specific port(s) or all the ports in a 576 given bridge-domain. 578 - the Split Horizon filtering status of specific port(s) or all the 579 ports in a given bridge-domain. 581 3.1.2.2 Fault Isolation 583 EVPN OAM MUST support an on-demand fault localization function. This 584 involves the capability to narrow down the locality of a fault to a 585 particular port, link or node. The characteristic of forward/reverse 586 path asymmetry, in MPLS/IP, makes fault isolation a direction- 587 sensitive operation. That is, given two PEs A and B, localization of 588 continuity failures between them requires running fault isolation 589 procedures from PE A to PE B as well as from PE B to PE A. 591 EVPN Service OAM mechanisms only have visibility to the PEs but not 592 the MPLS/IP P nodes. As such, they can be used to deduce whether the 593 fault is in the customer's own network, the local CE-PE segment or 594 remote CE-PE segment(s). EVPN Network and Transport OAM mechanisms 595 can be used for fault isolation between the PEs and P nodes. 597 3.2 Performance Management 599 Performance Management functions can be performed both proactively 600 and on-demand. Proactive management involves a recurring function, 601 where the performance management probes are run continuously without 602 a trigger. We cover both proactive and on-demand functions in this 603 section. 605 3.2.1 Packet Loss 607 EVPN Network OAM SHOULD provide mechanisms for measuring packet loss 608 for a given service [RFC7680] [RFC6673]. 610 Given that EVPN provides inherent support for multipoint-to- 611 multipoint connectivity, then packet loss cannot be accurately 612 measured by means of counting user data packets. This is because user 613 packets can be delivered to more PEs or more ports than are necessary 614 (e.g., due to broadcast, un-pruned multicast or unknown unicast 615 flooding). As such, a statistical means of approximating packet loss 616 rate is required. This can be achieved by sending "synthetic" OAM 617 packets that are counted only by those ports (MEPs) that are required 618 to receive them. This provides a statistical approximation of the 619 number of data frames lost, even with multipoint-to-multipoint 620 connectivity. 622 3.2.2 Packet Delay and Jitter 624 EVPN Service OAM SHOULD support measurement of one-way and two-way 625 packet delay and delay variation (jitter) across the EVPN network. 626 Measurement of one-way delay requires clock synchronization between 627 the probe source and target devices. Mechanisms for clock 628 synchronization are outside the scope of this document. Note that 629 Service OAM performance management mechanisms defined in [Y.1731] can 630 be used. See also [RFC7679], [RFC2681], and [RFC3393] 632 EVPN Network OAM MAY support measurement of one-way and two-way 633 packet delay and delay variation (jitter) across the EVPN network. 635 4. Security Considerations 637 EVPN OAM MUST prevent OAM packets from leaking outside of the EVPN 638 network or outside their corresponding Maintenance Domain. This can 639 be done for CFM, for example, by having MEPs implement a filtering 640 function based on the Maintenance Level associated with received OAM 641 packets. 643 EVPN OAM SHOULD provide mechanisms for implementation and optional 644 use to: 646 - Prevent denial of service attacks caused by exploitation of the OAM 647 message channel (for example by forging messages to exceed a 648 maintenance end point's capacity to maintain state). 650 - Authenticate communicating endpoints (for example MEPs and MIPs). 652 5. IANA Considerations 654 This document requires no IANA actions. 656 6. Acknowledgements 658 The authors would like to thank the following for their review of 659 this work and valuable comments: 661 David Black, Martin Duke, Xiao Min, Gregory Mirsky, Dave Schinazi, 662 Melinda Shore, Alexander Vainshtein, and Stig Venaas. 664 Normative References 666 [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 667 792, DOI 10.17487/RFC0792, September 1981, 668 . 670 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 671 Requirement Levels", BCP 14, RFC 2119, DOI 672 10.17487/RFC2119, March 1997, . 675 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 676 Control Message Protocol (ICMPv6) for the Internet Protocol 677 Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 678 10.17487/RFC4443, March 2006, . 681 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 682 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 683 . 685 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 686 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 687 10.17487/RFC5881, June 2010, . 690 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 691 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 692 June 2010, . 694 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 695 "Bidirectional Forwarding Detection (BFD) for MPLS Label 696 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 697 June 2010, .< 699 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., 700 and S. Mansfield, "Guidelines for the Use of the "OAM" 701 Acronym in the IETF", BCP 161, RFC 6291, DOI 702 10.17487/RFC6291, June 2011, . 705 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 706 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures 707 in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 708 6425, DOI 10.17487/RFC6425, November 2011, 709 . 711 [RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed., 712 "Proactive Connectivity Verification, Continuity Check, and 713 Remote Defect Indication for the MPLS Transport Profile", 714 RFC 6428, DOI 10.17487/RFC6428, November 2011, 715 . 717 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 718 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 719 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 720 2015, . 722 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 723 Henderickx, "Provider Backbone Bridging Combined with 724 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 725 September 2015, . 727 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 728 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 729 Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 730 10.17487/RFC8029, March 2017, . 733 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 734 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 735 2017, 737 Informative References 739 [802.1Q] "IEEE Standard for Local and metropolitan area networks - 740 Media Access Control (MAC) Bridges and Virtual Bridge Local 741 Area Networks", 2014. 743 [Y.1731] "ITU-T Recommendation Y.1731 (02/08) - OAM functions and 744 mechanisms for Ethernet based networks", February 2008. 746 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 747 Network Interconnect Devices", RFC 2544, DOI 748 10.17487/RFC2544, March 1999, . 751 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 752 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 753 September 1999, . 755 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 756 Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 757 10.17487/RFC3393, November 2002, . 760 [RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual 761 Circuit Connectivity Verification (VCCV): A Control Channel 762 for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 763 2007, . 765 [RFC6136] Sajassi, A., Ed., and D. Mohan, Ed., "Layer 2 Virtual 766 Private Network (L2VPN) Operations, Administration, and 767 Maintenance (OAM) Requirements and Framework", RFC 6136, 768 DOI 10.17487/RFC6136, March 2011, . 771 [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, DOI 772 10.17487/RFC6673, August 2012, . 775 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 776 Ed., "A One-Way Delay Metric for IP Performance Metrics 777 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 778 2016, . 780 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 781 Ed., "A One-Way Loss Metric for IP Performance Metrics 782 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 783 2016, . 785 Authors' Addresses 787 Samer Salam 788 Cisco 790 Email: ssalam@cisco.com 792 Ali Sajassi 793 Cisco 794 170 West Tasman Drive 795 San Jose, CA 95134, USA 797 Email: sajassi@cisco.com 799 Sam Aldrin 800 Google, Inc. 801 1600 Amphitheatre Parkway 802 Mountain View, CA 94043 USA 804 Email: aldrin.ietf@gmail.com 806 John E. Drake 807 Juniper Networks 808 1194 N. Mathilda Ave. 809 Sunnyvale, CA 94089, USA 811 Email: jdrake@juniper.net 813 Donald E. Eastlake, 3rd 814 Futurewei Technologies 815 2386 Panoramic Circle 816 Apopka, FL 32703 USA 818 Tel: +1-508-333-2270 819 Email: d3e3e3@gmail.com