idnits 2.17.1 draft-ietf-bess-evpn-oam-req-frmwk-05.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 17, 2021) is 1135 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: August 16, 2021 February 17, 2021 12 EVPN Operations, Administration and Maintenance 13 Requirements and Framework 14 draft-ietf-bess-evpn-oam-req-frmwk-05 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..............................................10 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).................13 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.........................................15 87 3.2.2 Packet Delay........................................16 89 4. Security Considerations................................17 90 5. IANA Considerations....................................17 91 6. Acknowledgements.......................................17 93 Normative References......................................18 94 Informative References....................................19 96 Authors' Addresses........................................20 98 1. Introduction 100 This document specifies the requirements and defines a reference 101 framework for Ethernet VPN (EVPN) Operations, Administration and 102 Maintenance (OAM, [RFC6291]). In this context, we use the term EVPN 103 OAM to loosely refer to the OAM functions required for and/or 104 applicable to [RFC7432] and [RFC7623]. 106 EVPN is an Layer 2 VPN (L2VPN) solution for multipoint Ethernet 107 services, with advanced multi-homing capabilities, using BGP for 108 distributing customer/client MAC address reachability information 109 over the core MPLS/IP network. 111 PBB-EVPN combines Provider Backbone Bridging (PBB) [802.1Q] with EVPN 112 in order to reduce the number of BGP MAC advertisement routes, 113 provide client MAC address mobility using C-MAC aggregation and B-MAC 114 sub-netting, confine the scope of C-MAC learning to only active 115 flows, offer per site policies, and avoid C-MAC address flushing on 116 topology changes. 118 This document focuses on the fault management and performance 119 management aspects of EVPN OAM. It defines the layered OAM model 120 encompassing the EVPN service layer, network layer, underlying Packet 121 Switched Network (PSN) transport layer, and link layer but focuses on 122 the service and network layers. 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 (PSN) tunnels. This document focuses on VPLS and 132 VPWS solutions and services. 134 [RFC8029] 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 [RFC2119] [RFC8174] 155 when, and only when, they appear in all 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 EVI An EVPN instance spanning the Provider Edge (PE) devices 167 participating in that EVPN. 169 L2VPN Layer 2 VPN. 171 MA Maintenance Association is a set of MEPs belonging to the same 172 Maintenance Domain, established to verify the integrity of a 173 single service instance. 175 MEP Maintenance End Point is responsible for origination and 176 termination of OAM frames for a given MA. 178 MIP Maintenance Intermediate Point is located between peer MEPs and 179 can process and respond to certain OAM frames but does not 180 initiate them. 182 MD Maintenance Domain, an OAM Domain that represents a region over 183 which OAM frames can operate unobstructed. 185 MP2P Multipoint to Point. 187 P Provider (non-edge) device. 189 P2MP Point to Multipoint. 191 PBB Provider Backbone Bridge. 193 PE Provider Edge device. 195 VPN Virtual Private Network 197 2. EVPN OAM Framework 199 2.1 OAM Layering 201 Multiple layers come into play for implementing an L2VPN service 202 using the EVPN family of solutions as listed below. The focus of this 203 document is the Service and Network layers. 205 - The Service Layer runs end to end between the sites or Ethernet 206 Segments that are being interconnected by the EVPN solution. 208 - The Network Layer extends between the EVPN PE (Provider Edge) nodes 209 and is mostly transparent to the core P (Provider) nodes (except 210 where Flow Entropy comes into play). It leverages MPLS for service 211 (i.e., EVI) multiplexing and Split-Horizon functions. 213 - The Transport Layer is dictated by the networking technology of the 214 PSN. It may be either based on MPLS LSPs or IP. 216 - The Link Layer is dependent upon the physical technology used. 217 Ethernet is a popular choice for this layer, but other alternatives 218 are deployed (e.g., POS, DWDM etc.). 220 This layering extends to the set of OAM protocols that are involved 221 in the ongoing maintenance and diagnostics of EVPN networks. Figure 1 222 below depicts the OAM layering, and shows which devices have 223 visibility into what OAM layer(s). 225 +---+ +---+ 226 +--+ | | +---+ +---+ +---+ | | +--+ 227 |CE|----|PE1|----| P |----| P |----| P |----|PE2|----|CE| 228 +--+ | | +---+ +---+ +---+ | | +--+ 229 +---+ +---+ 231 o--------o---------- Service OAM ------------o--------o 233 o----------- Network OAM -----------o 235 o--------o--------o--------o--------o Transport OAM 237 o----o o----o o----o o----o o----o o----o Link OAM 239 Figure 1: OAM Layering 241 Service OAM and Network OAM mechanisms only have visibility to the PE 242 (Provider Edge) nodes but not the P nodes (Provider network interior 243 nodes). As such, they can be used to deduce whether the fault is in 244 the customer's own network, the local CE-PE segment, the PE-PE 245 segment or the remote CE-PE segment(s). EVPN Transport OAM mechanisms 246 can be used for fault isolation between the PEs and P nodes. 248 Figure 2 below shows an example network where native Ethernet domains 249 are interconnected via EVPN using MPLS and gives the OAM mechanisms 250 applicable at each layer. The details of the layers are described in 251 the sections below. 253 +---+ +---+ 254 +--+ | | +---+ +---+ +---+ | | +--+ 255 |CE|----|PE1|----| P |----| P |----| P |----|PE2|----|CE| 256 +--+ | | +---+ +---+ +---+ | | +--+ 257 +---+ +---+ 259 o--------o---------- Service CFM ------------o--------o 261 o-------- EVPN Network OAM ---------o 263 o--------o--------o--------o--------o MPLS OAM 265 o----o o----o o----o o----o o----o o----o 802.3 OAM 267 Figure 2: EVPN OAM Example 269 2.2 EVPN Service OAM 271 The EVPN Service OAM protocol depends on what service layer 272 technology is being interconnected by the EVPN solution. In case of 273 [RFC7432] and [RFC7623], the service layer is Ethernet; hence, the 274 corresponding service OAM protocol is Ethernet Connectivity Fault 275 Management (CFM) [802.1Q]. 277 EVPN service OAM is visible to the CEs and EVPN PEs, but not to the 278 core (P) nodes. This is because the PEs operate at the Ethernet MAC 279 layer in [RFC7432] [RFC7623] whereas the P nodes do not. 281 The EVPN PE MUST support MIP functions in the applicable service OAM 282 protocol, for example Ethernet CFM. The EVPN PE SHOULD support MEP 283 functions in the applicable service OAM protocol. This includes both 284 Up and Down MEP functions. As shown in Figure 3, the MIP and MEP 285 functions being referred to are logically located within the CE 286 facing port of a PE. Down MEP functions are towards the CE. Up MEP 287 functions are towards the PE forwarding mechanism. CFM between the PE 288 Up MEPs is a type of EVPN Network OAM while CFM between the CEs or 289 from a PE to its local CE or to the remote CE is Service OAM. 291 +-------+ +---------------+ +---------------+ +-------+ 292 | CE | | PE1 | ... | PE2 | | CE | 293 +---+---+ +---+--------+--+ +--+--------+---+ +---+---+ 294 | | | | | | 295 | +----+----+ | | +----+----+ | 296 +--+--+ | | up^ | . . |up^ | | +--+--+ 297 | MEP | |MIP|MEP | . ... . |MEP |MIP| | MEP | 298 |downV| | |downV| . . |downV| | |downV| 299 +--+--+ +----+----+ | | +----+----+ +--+--+ 300 | | | | | | 301 +-----------+ +--- ... ---+ +------------+ 303 Figure 3: CFM Details 305 The EVPN PE MUST learn the MAC address of locally attached CE MEPs by 306 snooping on CFM frames and advertising them to remote PEs as a MAC/IP 307 Advertisement route. 309 The EVPN PE SHOULD advertise any MEP/MIP local to the PE as a MAC/IP 310 Advertisement route. Since these are not subject to mobility, they 311 SHOULD be advertised with the static (sticky) bit set (see Section 312 15.2 of [RFC7432]). 314 2.3 EVPN Network OAM 316 EVPN Network OAM is visible to the PE nodes only. This OAM layer is 317 analogous to VCCV [RFC5085] in the case of VPLS/VPWS. It provides 318 mechanisms to check the correct operation of the data plane, as well 319 as a mechanism to verify the data plane against the control plane. 320 This includes the ability to perform fault detection and diagnostics 321 on: 323 - the MP2P tunnels used for the transport of unicast traffic between 324 PEs. EVPN allows for three different models of unicast label 325 assignment: label per EVI, label per and label 326 per MAC address. In all three models, the label is bound to an EVPN 327 Unicast FEC. EVPN Network OAM MUST provide mechanisms to check the 328 operation of the data plane and verify that operation against the 329 control plane view. 331 - the MP2P tunnels used for aliasing unicast traffic destined to a 332 multi-homed Ethernet Segment. The three label assignment models, 333 discussed above, apply here as well. In all three models, the label 334 is bound to an EVPN Aliasing FEC. EVPN Network OAM MUST provide 335 mechanisms to check the operation of the data plane and verify that 336 operation against the control plane view. 338 - the multicast tunnels (either MP2P or P2MP) used for the transport 339 of broadcast, unknown unicast and multicast traffic between PEs. In 340 the case of ingress replication, a label is allocated per EVI or 341 per and is bound to an EVPN Multicast FEC. In 342 the case of LSM, and more specifically aggregate inclusive trees, 343 again a label may be allocated per EVI or per 344 and is bound to the tunnel FEC. 346 - the correct operation of the ESI split-horizon filtering function. 347 In EVPN, a label is allocated per multi-homed Ethernet Segment for 348 the purpose of performing the access split-horizon enforcement. The 349 label is bound to an EVPN Ethernet Segment. 351 - the correct operation of the DF (Designated Forwarder) filtering 352 function. EVPN Network OAM MUST provide mechanisms to check the 353 operation of the data plane and verify that operation against the 354 control plane view for the DF filtering function. 356 EVPN network OAM mechanisms MUST provide in-band monitoring 357 capabilities. As such, OAM messages MUST be encoded so that they 358 exhibit identical entropy characteristics to data traffic in order 359 that they share the same fate. 361 EVPN network OAM SHOULD provide both proactive and on-demand 362 mechanisms of monitoring the data plane operation and data plane 363 conformance to the state of the control plane. 365 2.4 Transport OAM for EVPN 367 The transport OAM protocol depends on the nature of the underlying 368 transport technology in the PSN. MPLS OAM mechanisms [RFC8029] 369 [RFC6425] as well as ICMP [RFC792] are applicable, depending on 370 whether the PSN employs MPLS or IP transport, respectively. 371 Furthermore, BFD mechanisms per [RFC5880], [RFC5881], [RFC5883] and 372 [RFC5884] apply. Also, the BFD mechanisms pertaining to MPLS-TP LSPs 373 per [RFC6428] are applicable. 375 2.5 Link OAM 377 Link OAM depends on the data link technology being used between the 378 PE and P nodes. For example, if Ethernet links are employed, then 379 Ethernet Link OAM [802.3] Clause 57 may be used. 381 2.6 OAM Inter-working 383 When inter-working two networking domains, such as native Ethernet 384 and EVPN to provide an end-to-end emulated service, there is a need 385 to identify the failure domain and location, even when a PE supports 386 both the Service OAM mechanisms and the EVPN Network OAM mechanisms. 387 In addition, scalability constraints may not allow running proactive 388 monitoring, such as Ethernet Continuity Check Messages (CCMs), at a 389 PE to detect the failure of an EVI across the EVPN domain. Thus, the 390 mapping of alarms generated upon failure detection in one domain 391 (e.g., native Ethernet or EVPN network domain) to the other domain is 392 needed. There are also cases where a PE may not be able to process 393 Service OAM messages received from a remote PE over the PSN even when 394 such messages are defined, as in the Ethernet case, thereby 395 necessitating support for fault notification message mapping between 396 the EVPN Network domain and the Service domain. 398 OAM inter-working is not limited though to scenarios involving 399 disparate network domains. It is possible to perform OAM inter- 400 working across different layers in the same network domain. In 401 general, alarms generated within an OAM layer, as a result of 402 proactive fault detection mechanisms, may be injected into its client 403 layer OAM mechanisms. This allows the client layer OAM to trigger 404 event-driven (i.e., asynchronous) fault notifications. For example, 405 alarms generated by the Link OAM mechanisms may be injected into the 406 Transport OAM layer, and alarms generated by the Transport OAM 407 mechanism may be injected into the Network OAM mechanism, and so on. 409 EVPN OAM MUST support inter-working between the Network OAM and 410 Service OAM mechanisms. EVPN OAM MAY support inter-working among 411 other OAM layers. 413 3. EVPN OAM Requirements 415 This section discusses the EVPN OAM requirements pertaining to Fault 416 Management and Performance Management. 418 3.1 Fault Management Requirements 420 3.1.1 Proactive Fault Management Functions 422 The network operator configures proactive fault management functions 423 to run periodically without a time bound. Certain actions, for 424 example protection switchover or alarm indication signaling, can be 425 associated with specific events, such as entering or clearing fault 426 states. 428 3.1.1.1 Fault Detection (Continuity Check) 430 Proactive fault detection is performed by periodically monitoring the 431 reachability between service endpoints, i.e., MEPs in a given MA, 432 through the exchange of Continuity Check messages. The reachability 433 between any two arbitrary MEPs may be monitored for: 435 - in-band per-flow monitoring. This enables per flow monitoring 436 between MEPs. EVPN Network OAM MUST support fault detection with 437 per user flow granularity. EVPN Service OAM MAY support fault 438 detection with per user flow granularity. 440 - a representative path. This enables liveness check of the nodes 441 hosting the MEPs assuming that the loss of continuity to the MEP is 442 interpreted as a failure of the hosting node. This, however, does 443 not conclusively indicate liveness of the path(s) taken by user 444 data traffic. This enables node failure detection but not path 445 failure detection, through the use of a test flow. EVPN Network OAM 446 and Service OAM MUST support fault detection using test flows. 448 - all paths. For MPLS/IP networks with ECMP, monitoring of all 449 unicast paths between MEPs (on non-adjacent nodes) may not be 450 possible, since the per-hop ECMP hashing behavior may yield 451 situations where it is impossible for a MEP to pick flow entropy 452 characteristics that result in exercising the exhaustive set of 453 ECMP paths. Monitoring of all ECMP paths between MEPs (on non- 454 adjacent nodes) is not a requirement for EVPN OAM. 456 The fact that MPLS/IP networks do not enforce congruency between 457 unicast and multicast paths means that the proactive fault detection 458 mechanisms for EVPN networks MUST provide procedures to monitor the 459 unicast paths independently of the multicast paths. This applies to 460 EVPN Service OAM and Network OAM. 462 3.1.1.2 Defect Indication 464 EVPN Service OAM MUST support event-driven defect indication upon the 465 detection of a connectivity defect. Defect indications can be 466 categorized into two types: forward and reverse defect indications. 468 3.1.1.2.1 Forward Defect Indication 470 This is used to signal a failure that is detected by a lower layer 471 OAM mechanism. A server MEP (i.e., an actual or virtual MEP) 472 transmits a Forward Defect Indication in a direction that is away 473 from the direction of the failure (refer to Figure 4 below). 475 Failure 476 | 477 +-----+ +-----+ V +-----+ +-----+ 478 | A |------| B |--XXX--| C |------| D | 479 +-----+ +-----+ +-----+ +-----+ 481 <===========| |============> 482 Forward Forward 483 Defect Defect 484 Indication Indication 486 Figure 4: Forward Defect Indication 488 Forward defect indication may be used for alarm suppression and/or 489 for purpose of inter-working with other layer OAM protocols. Alarm 490 suppression is useful when a transport/network level fault translates 491 to multiple service or flow level faults. In such a scenario, it is 492 enough to alert a network management station (NMS) of the single 493 transport/network level fault in lieu of flooding that NMS with a 494 multitude of Service or Flow granularity alarms. EVPN PEs SHOULD 495 support Forward Defect Indication in the Service OAM mechanisms. 497 3.1.1.2.2 Reverse Defect Indication (RDI) 499 RDI is used to signal that the advertising MEP has detected a loss of 500 continuity (LoC) defect. RDI is transmitted in the direction of the 501 failure (refer to Figure 5). 503 Failure 504 | 505 +-----+ +-----+ V +-----+ +-----+ 506 | A |------| B |--XXX--| C |------| D | 507 +-----+ +-----+ +-----+ +-----+ 509 |===========> <============| 510 Reverse Reverse 511 Defect Defect 512 Indication Indication 514 Figure 5: Reverse Defect Indication 516 RDI allows single-sided management, where the network operator can 517 examine the state of a single MEP and deduce the overall health of a 518 monitored service. EVPN PEs SHOULD support Reverse Defect Indication 519 in the Service OAM mechanisms. This includes both the ability to 520 signal LoC defect to a remote MEP, as well as the ability to 521 recognize RDI from a remote MEP. Note that, in a multipoint MA, RDI 522 is not a useful indicator of unidirectional fault. This is because 523 RDI carries no indication of the affected MEP(s) with which the 524 sender had detected a LoC defect. 526 3.1.2 On-Demand Fault Management Functions 528 On-demand fault management functions are initiated manually by the 529 network operator and continue for a time bound period. These 530 functions enable the operator to run diagnostics to investigate a 531 defect condition. 533 3.1.2.1 Connectivity Verification 535 EVPN Network OAM MUST support on-demand connectivity verification 536 mechanisms for unicast and multicast destinations. The connectivity 537 verification mechanisms SHOULD provide a means for specifying and 538 carrying in the messages: 540 - variable length payload/padding to test MTU related connectivity 541 problems. 543 - test frame formats as defined in Appendix C of [RFC2544] to detect 544 potential packet corruption. 546 EVPN Network OAM MUST support connectivity verification at per flow 547 granularity. This includes both user flows (to test a specific path 548 between PEs) as well as test flows (to test a representative path 549 between PEs). 551 EVPN Service OAM MUST support connectivity verification on test flows 552 and MAY support connectivity verification on user flows. 554 For multicast connectivity verification, EVPN Network OAM MUST 555 support reporting on: 557 - the DF filtering status of specific port(s) or all the ports in a 558 given bridge-domain. 560 - the Split Horizon filtering status of specific port(s) or all the 561 ports in a given bridge-domain. 563 3.1.2.2 Fault Isolation 565 EVPN OAM MUST support an on-demand fault localization function. This 566 involves the capability to narrow down the locality of a fault to a 567 particular port, link or node. The characteristic of forward/reverse 568 path asymmetry, in MPLS/IP, makes fault isolation a direction- 569 sensitive operation. That is, given two PEs A and B, localization of 570 continuity failures between them requires running fault isolation 571 procedures from PE A to PE B as well as from PE B to PE A. 573 EVPN Service OAM mechanisms only have visibility to the PEs but not 574 the MPLS/IP P nodes. As such, they can be used to deduce whether the 575 fault is in the customer's own network, the local CE-PE segment or 576 remote CE-PE segment(s). EVPN Network and Transport OAM mechanisms 577 can be used for fault isolation between the PEs and P nodes. 579 3.2 Performance Management 581 Performance Management functions can be performed both proactively 582 and on-demand. Proactive management involves a recurring function, 583 where the performance management probes are run continuously without 584 a trigger. We cover both proactive and on-demand functions in this 585 section. 587 3.2.1 Packet Loss 589 EVPN Network OAM SHOULD provide mechanisms for measuring packet loss 590 for a given service. 592 Given that EVPN provides inherent support for multipoint-to- 593 multipoint connectivity, then packet loss cannot be accurately 594 measured by means of counting user data packets. This is because user 595 packets can be delivered to more PEs or more ports than are necessary 596 (e.g., due to broadcast, un-pruned multicast or unknown unicast 597 flooding). As such, a statistical means of approximating packet loss 598 rate is required. This can be achieved by sending "synthetic" OAM 599 packets that are counted only by those ports (MEPs) that are required 600 to receive them. This provides a statistical approximation of the 601 number of data frames lost, even with multipoint-to-multipoint 602 connectivity. 604 3.2.2 Packet Delay 606 EVPN Service OAM SHOULD support measurement of one-way and two-way 607 packet delay and delay variation (jitter) across the EVPN network. 608 Measurement of one-way delay requires clock synchronization between 609 the probe source and target devices. Mechanisms for clock 610 synchronization are outside the scope of this document. Note that 611 Service OAM performance management mechanisms defined in [Y.1731] can 612 be used. 614 EVPN Network OAM MAY support measurement of one-way and two-way 615 packet delay and delay variation (jitter) across the EVPN network. 617 4. Security Considerations 619 EVPN OAM MUST prevent OAM packets from leaking outside of the EVPN 620 network or outside their corresponding Maintenance Domain. This can 621 be done for CFM, for example, by having MEPs implement a filtering 622 function based on the Maintenance Level associated with received OAM 623 packets. 625 EVPN OAM SHOULD provide mechanisms for implementation and optional 626 use to: 628 - Prevent denial of service attacks caused by exploitation of the OAM 629 message channel (for example by forging messages to exceed a 630 maintenance end point's capacity to maintain state). 632 - Authenticate communicating endpoints (for example MEPs and MIPs). 634 5. IANA Considerations 636 This document requires no IANA actions. 638 6. Acknowledgements 640 The authors would like to thank the following for their review of 641 this work and valuable comments: 643 David Black, Xiao Min, Gregory Mirsky, Dave Schinazi, Melinda 644 Shore, Alexander Vainshtein, and Stig Venaas. 646 Normative References 648 [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 649 792, DOI 10.17487/RFC0792, September 1981, 650 . 652 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 653 Requirement Levels", BCP 14, RFC 2119, DOI 654 10.17487/RFC2119, March 1997, . 657 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 658 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 659 . 661 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 662 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 663 10.17487/RFC5881, June 2010, . 666 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 667 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 668 June 2010, . 670 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 671 "Bidirectional Forwarding Detection (BFD) for MPLS Label 672 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 673 June 2010, .< 675 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., 676 and S. Mansfield, "Guidelines for the Use of the "OAM" 677 Acronym in the IETF", BCP 161, RFC 6291, DOI 678 10.17487/RFC6291, June 2011, . 681 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 682 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures 683 in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 684 6425, DOI 10.17487/RFC6425, November 2011, 685 . 687 [RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed., 688 "Proactive Connectivity Verification, Continuity Check, and 689 Remote Defect Indication for the MPLS Transport Profile", 690 RFC 6428, DOI 10.17487/RFC6428, November 2011, 691 . 693 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 694 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 695 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 696 2015, . 698 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 699 Henderickx, "Provider Backbone Bridging Combined with 700 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 701 September 2015, . 703 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 704 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 705 Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 706 10.17487/RFC8029, March 2017, . 709 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 710 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 711 2017, 713 Informative References 715 [802.1Q] "IEEE Standard for Local and metropolitan area networks - 716 Media Access Control (MAC) Bridges and Virtual Bridge Local 717 Area Networks", 2014. 719 [Y.1731] "ITU-T Recommendation Y.1731 (02/08) - OAM functions and 720 mechanisms for Ethernet based networks", February 2008. 722 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 723 Network Interconnect Devices", RFC 2544, DOI 724 10.17487/RFC2544, March 1999, . 727 [RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual 728 Circuit Connectivity Verification (VCCV): A Control Channel 729 for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 730 2007, . 732 [RFC6136] Sajassi, A., Ed., and D. Mohan, Ed., "Layer 2 Virtual 733 Private Network (L2VPN) Operations, Administration, and 734 Maintenance (OAM) Requirements and Framework", RFC 6136, 735 DOI 10.17487/RFC6136, March 2011, . 738 Authors' Addresses 740 Samer Salam 741 Cisco 743 Email: ssalam@cisco.com 745 Ali Sajassi 746 Cisco 747 170 West Tasman Drive 748 San Jose, CA 95134, USA 750 Email: sajassi@cisco.com 752 Sam Aldrin 753 Google, Inc. 754 1600 Amphitheatre Parkway 755 Mountain View, CA 94043 USA 757 Email: aldrin.ietf@gmail.com 759 John E. Drake 760 Juniper Networks 761 1194 N. Mathilda Ave. 762 Sunnyvale, CA 94089, USA 764 Email: jdrake@juniper.net 766 Donald E. Eastlake, 3rd 767 Futurewei Technologies 768 2386 Panoramic Circle 769 Apopka, FL 32703 USA 771 Tel: +1-508-333-2270 772 Email: d3e3e3@gmail.com