idnits 2.17.1 draft-ietf-bess-evpn-oam-req-frmwk-06.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 (March 19, 2021) is 1105 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: September 18, 2021 March 19, 2021 12 EVPN Operations, Administration and Maintenance 13 Requirements and Framework 14 draft-ietf-bess-evpn-oam-req-frmwk-06 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", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in BCP 155 14 [RFC2119] [RFC8174] when, and only when, they appear in all 156 capitals, as shown here. 158 1.3 Terminology 160 This document uses the following terminology much of which is defined 161 in [RFC6136]: 163 CE Customer Edge device, e.g., a host, router, or switch. 165 DF Designated Forwarder 167 EVI An EVPN instance spanning the Provider Edge (PE) devices 168 participating in that EVPN. 170 L2VPN Layer 2 VPN. 172 MA Maintenance Association is a set of MEPs belonging to the same 173 Maintenance Domain, established to verify the integrity of a 174 single service instance. 176 MEP Maintenance End Point is responsible for origination and 177 termination of OAM frames for a given MA. 179 MIP Maintenance Intermediate Point is located between peer MEPs and 180 can process and respond to certain OAM frames but does not 181 initiate them. 183 MD Maintenance Domain, an OAM Domain that represents a region over 184 which OAM frames can operate unobstructed. 186 MP2P Multipoint to Point. 188 P Provider (non-edge) device. 190 P2MP Point to Multipoint. 192 PBB Provider Backbone Bridge. 194 PE Provider Edge device. 196 VPN Virtual Private Network 198 2. EVPN OAM Framework 200 2.1 OAM Layering 202 Multiple layers come into play for implementing an L2VPN service 203 using the EVPN family of solutions as listed below. The focus of this 204 document is the Service and Network layers. 206 - The Service Layer runs end to end between the sites or Ethernet 207 Segments that are being interconnected by the EVPN solution. 209 - The Network Layer extends between the EVPN PE (Provider Edge) nodes 210 and is mostly transparent to the core P (Provider) nodes (except 211 where Flow Entropy comes into play). It leverages MPLS for service 212 (i.e., EVI) multiplexing and Split-Horizon functions. 214 - The Transport Layer is dictated by the networking technology of the 215 PSN. It may be either based on MPLS LSPs or IP. 217 - The Link Layer is dependent upon the physical technology used. 218 Ethernet is a popular choice for this layer, but other alternatives 219 are deployed (e.g., POS, DWDM etc.). 221 This layering extends to the set of OAM protocols that are involved 222 in the ongoing maintenance and diagnostics of EVPN networks. Figure 1 223 below depicts the OAM layering, and shows which devices have 224 visibility into what OAM layer(s). 226 +---+ +---+ 227 +--+ | | +---+ +---+ +---+ | | +--+ 228 |CE|----|PE1|----| P |----| P |----| P |----|PE2|----|CE| 229 +--+ | | +---+ +---+ +---+ | | +--+ 230 +---+ +---+ 232 o--------o---------- Service OAM ------------o--------o 234 o----------- Network OAM -----------o 236 o--------o--------o--------o--------o Transport OAM 238 o----o o----o o----o o----o o----o o----o Link OAM 240 Figure 1: OAM Layering 242 Service OAM and Network OAM mechanisms only have visibility to the PE 243 (Provider Edge) nodes but not the P nodes (Provider network interior 244 nodes). As such, they can be used to deduce whether the fault is in 245 the customer's own network, the local CE-PE segment, the PE-PE 246 segment or the remote CE-PE segment(s). EVPN Transport OAM mechanisms 247 can be used for fault isolation between the PEs and P nodes. 249 Figure 2 below shows an example network where native Ethernet domains 250 are interconnected via EVPN using MPLS and gives the OAM mechanisms 251 applicable at each layer. The details of the layers are described in 252 the sections below. 254 +---+ +---+ 255 +--+ | | +---+ +---+ +---+ | | +--+ 256 |CE|----|PE1|----| P |----| P |----| P |----|PE2|----|CE| 257 +--+ | | +---+ +---+ +---+ | | +--+ 258 +---+ +---+ 260 o--------o---------- Service CFM ------------o--------o 262 o-------- EVPN Network OAM ---------o 264 o--------o--------o--------o--------o MPLS OAM 266 o----o o----o o----o o----o o----o o----o 802.3 OAM 268 Figure 2: EVPN OAM Example 270 2.2 EVPN Service OAM 272 The EVPN Service OAM protocol depends on what service layer 273 technology is being interconnected by the EVPN solution. In case of 274 [RFC7432] and [RFC7623], the service layer is Ethernet; hence, the 275 corresponding service OAM protocol is Ethernet Connectivity Fault 276 Management (CFM) [802.1Q]. 278 EVPN service OAM is visible to the CEs and EVPN PEs, but not to the 279 core (P) nodes. This is because the PEs operate at the Ethernet MAC 280 layer in [RFC7432] [RFC7623] whereas the P nodes do not. 282 The EVPN PE MUST support MIP functions in the applicable service OAM 283 protocol, for example Ethernet CFM. The EVPN PE SHOULD support MEP 284 functions in the applicable service OAM protocol. This includes both 285 Up and Down MEP functions. As shown in Figure 3, the MIP and MEP 286 functions being referred to are logically located within the CE 287 facing port of a PE. Down MEP functions are towards the CE. Up MEP 288 functions are towards the PE forwarding mechanism. CFM between the PE 289 Up MEPs is a type of EVPN Network OAM while CFM between the CEs or 290 from a PE to its local CE or to the remote CE is Service OAM. 292 +-------+ +---------------+ +---------------+ +-------+ 293 | CE | | PE1 | ... | PE2 | | CE | 294 +---+---+ +---+--------+--+ +--+--------+---+ +---+---+ 295 | | | | | | 296 | +----+----+ | | +----+----+ | 297 +--+--+ | | up^ | . . |up^ | | +--+--+ 298 | MEP | |MIP|MEP | . ... . |MEP |MIP| | MEP | 299 |downV| | |downV| . . |downV| | |downV| 300 +--+--+ +----+----+ | | +----+----+ +--+--+ 301 | | | | | | 302 +-----------+ +--- ... ---+ +------------+ 304 Figure 3: CFM Details 306 The EVPN PE MUST learn the MAC address of locally attached CE MEPs by 307 snooping on CFM frames and advertising them to remote PEs as a MAC/IP 308 Advertisement route. 310 The EVPN PE SHOULD advertise any MEP/MIP local to the PE as a MAC/IP 311 Advertisement route. Since these are not subject to mobility, they 312 SHOULD be advertised with the static (sticky) bit set (see Section 313 15.2 of [RFC7432]). 315 2.3 EVPN Network OAM 317 EVPN Network OAM is visible to the PE nodes only. This OAM layer is 318 analogous to VCCV [RFC5085] in the case of VPLS/VPWS. It provides 319 mechanisms to check the correct operation of the data plane, as well 320 as a mechanism to verify the data plane against the control plane. 321 This includes the ability to perform fault detection and diagnostics 322 on: 324 - the MP2P tunnels used for the transport of unicast traffic between 325 PEs. EVPN allows for three different models of unicast label 326 assignment: label per EVI, label per and label 327 per MAC address. In all three models, the label is bound to an EVPN 328 Unicast FEC. EVPN Network OAM MUST provide mechanisms to check the 329 operation of the data plane and verify that operation against the 330 control plane view. 332 - the MP2P tunnels used for aliasing unicast traffic destined to a 333 multi-homed Ethernet Segment. The three label assignment models, 334 discussed above, apply here as well. In all three models, the label 335 is bound to an EVPN Aliasing FEC. EVPN Network OAM MUST provide 336 mechanisms to check the operation of the data plane and verify that 337 operation against the control plane view. 339 - the multicast tunnels (either MP2P or P2MP) used for the transport 340 of broadcast, unknown unicast and multicast traffic between PEs. In 341 the case of ingress replication, a label is allocated per EVI or 342 per and is bound to an EVPN Multicast FEC. In 343 the case of LSM (Label Switched Multicast), and more specifically 344 aggregate inclusive trees, again a label may be allocated per EVI 345 or per and is bound to the tunnel FEC. 347 - the correct operation of the ESI split-horizon filtering function. 348 In EVPN, a label is allocated per multi-homed Ethernet Segment for 349 the purpose of performing the access split-horizon enforcement. The 350 label is bound to an EVPN Ethernet Segment. 352 - the correct operation of the DF (Designated Forwarder) filtering 353 function. EVPN Network OAM MUST provide mechanisms to check the 354 operation of the data plane and verify that operation against the 355 control plane view for the DF filtering function. 357 EVPN Network OAM mechanisms MUST provide in-band monitoring 358 capabilities. As such, OAM messages MUST be encoded so that they 359 exhibit identical entropy characteristics to data traffic in order 360 that they share the same fate. 362 EVPN Network OAM SHOULD provide both proactive and on-demand 363 mechanisms of monitoring the data plane operation and data plane 364 conformance to the state of the control plane. 366 2.4 Transport OAM for EVPN 368 The transport OAM protocol depends on the nature of the underlying 369 transport technology in the PSN. MPLS OAM mechanisms [RFC8029] 370 [RFC6425] as well as ICMP [RFC792] are applicable, depending on 371 whether the PSN employs MPLS or IP transport, respectively. 372 Furthermore, BFD mechanisms per [RFC5880], [RFC5881], [RFC5883] and 373 [RFC5884] apply. Also, the BFD mechanisms pertaining to MPLS-TP LSPs 374 per [RFC6428] are applicable. 376 2.5 Link OAM 378 Link OAM depends on the data link technology being used between the 379 PE and P nodes. For example, if Ethernet links are employed, then 380 Ethernet Link OAM [802.3] Clause 57 may be used. 382 2.6 OAM Inter-working 384 When inter-working two networking domains, such as native Ethernet 385 and EVPN to provide an end-to-end emulated service, there is a need 386 to identify the failure domain and location, even when a PE supports 387 both the Service OAM mechanisms and the EVPN Network OAM mechanisms. 388 In addition, scalability constraints may not allow running proactive 389 monitoring, such as Ethernet Continuity Check Messages (CCMs), at a 390 PE to detect the failure of an EVI across the EVPN domain. Thus, the 391 mapping of alarms generated upon failure detection in one domain 392 (e.g., native Ethernet or EVPN network domain) to the other domain is 393 needed. There are also cases where a PE may not be able to process 394 Service OAM messages received from a remote PE over the PSN even when 395 such messages are defined, as in the Ethernet case, thereby 396 necessitating support for fault notification message mapping between 397 the EVPN Network domain and the Service domain. 399 OAM inter-working is not limited though to scenarios involving 400 disparate network domains. It is possible to perform OAM inter- 401 working across different layers in the same network domain. In 402 general, alarms generated within an OAM layer, as a result of 403 proactive fault detection mechanisms, may be injected into its client 404 layer OAM mechanisms. This allows the client layer OAM to trigger 405 event-driven (i.e., asynchronous) fault notifications. For example, 406 alarms generated by the Link OAM mechanisms may be injected into the 407 Transport OAM layer, and alarms generated by the Transport OAM 408 mechanism may be injected into the Network OAM mechanism, and so on. 410 EVPN OAM MUST support inter-working between the Network OAM and 411 Service OAM mechanisms. EVPN OAM MAY support inter-working among 412 other OAM layers. 414 3. EVPN OAM Requirements 416 This section discusses the EVPN OAM requirements pertaining to Fault 417 Management and Performance Management. 419 3.1 Fault Management Requirements 421 3.1.1 Proactive Fault Management Functions 423 The network operator configures proactive fault management functions 424 to run periodically without a time bound. Certain actions, for 425 example protection switchover or alarm indication signaling, can be 426 associated with specific events, such as entering or clearing fault 427 states. 429 3.1.1.1 Fault Detection (Continuity Check) 431 Proactive fault detection is performed by periodically monitoring the 432 reachability between service endpoints, i.e., MEPs in a given MA, 433 through the exchange of Continuity Check messages. The reachability 434 between any two arbitrary MEPs may be monitored for: 436 - in-band per-flow monitoring. This enables per flow monitoring 437 between MEPs. EVPN Network OAM MUST support fault detection with 438 per user flow granularity. EVPN Service OAM MAY support fault 439 detection with per user flow granularity. 441 - a representative path. This enables liveness check of the nodes 442 hosting the MEPs assuming that the loss of continuity to the MEP is 443 interpreted as a failure of the hosting node. This, however, does 444 not conclusively indicate liveness of the path(s) taken by user 445 data traffic. This enables node failure detection but not path 446 failure detection, through the use of a test flow. EVPN Network OAM 447 and Service OAM MUST support fault detection using test flows. 449 - all paths. For MPLS/IP networks with ECMP, monitoring of all 450 unicast paths between MEPs (on non-adjacent nodes) may not be 451 possible, since the per-hop ECMP hashing behavior may yield 452 situations where it is impossible for a MEP to pick flow entropy 453 characteristics that result in exercising the exhaustive set of 454 ECMP paths. Monitoring of all ECMP paths between MEPs (on non- 455 adjacent nodes) is not a requirement for EVPN OAM. 457 The fact that MPLS/IP networks do not enforce congruency between 458 unicast and multicast paths means that the proactive fault detection 459 mechanisms for EVPN networks MUST provide procedures to monitor the 460 unicast paths independently of the multicast paths. This applies to 461 EVPN Service OAM and Network OAM. 463 3.1.1.2 Defect Indication 465 EVPN Service OAM MUST support event-driven defect indication upon the 466 detection of a connectivity defect. Defect indications can be 467 categorized into two types: forward and reverse defect indications. 469 3.1.1.2.1 Forward Defect Indication 471 This is used to signal a failure that is detected by a lower layer 472 OAM mechanism. A server MEP (i.e., an actual or virtual MEP) 473 transmits a Forward Defect Indication in a direction that is away 474 from the direction of the failure (refer to Figure 4 below). 476 Failure 477 | 478 +-----+ +-----+ V +-----+ +-----+ 479 | A |------| B |--XXX--| C |------| D | 480 +-----+ +-----+ +-----+ +-----+ 482 <===========| |============> 483 Forward Forward 484 Defect Defect 485 Indication Indication 487 Figure 4: Forward Defect Indication 489 Forward defect indication may be used for alarm suppression and/or 490 for purpose of inter-working with other layer OAM protocols. Alarm 491 suppression is useful when a transport/network level fault translates 492 to multiple service or flow level faults. In such a scenario, it is 493 enough to alert a network management station (NMS) of the single 494 transport/network level fault in lieu of flooding that NMS with a 495 multitude of Service or Flow granularity alarms. EVPN PEs SHOULD 496 support Forward Defect Indication in the Service OAM mechanisms. 498 3.1.1.2.2 Reverse Defect Indication (RDI) 500 RDI is used to signal that the advertising MEP has detected a loss of 501 continuity (LoC) defect. RDI is transmitted in the direction of the 502 failure (refer to Figure 5). 504 Failure 505 | 506 +-----+ +-----+ V +-----+ +-----+ 507 | A |------| B |--XXX--| C |------| D | 508 +-----+ +-----+ +-----+ +-----+ 510 |===========> <============| 511 Reverse Reverse 512 Defect Defect 513 Indication Indication 515 Figure 5: Reverse Defect Indication 517 RDI allows single-sided management, where the network operator can 518 examine the state of a single MEP and deduce the overall health of a 519 monitored service. EVPN PEs SHOULD support Reverse Defect Indication 520 in the Service OAM mechanisms. This includes both the ability to 521 signal LoC defect to a remote MEP, as well as the ability to 522 recognize RDI from a remote MEP. Note that, in a multipoint MA, RDI 523 is not a useful indicator of unidirectional fault. This is because 524 RDI carries no indication of the affected MEP(s) with which the 525 sender had detected a LoC defect. 527 3.1.2 On-Demand Fault Management Functions 529 On-demand fault management functions are initiated manually by the 530 network operator and continue for a time bound period. These 531 functions enable the operator to run diagnostics to investigate a 532 defect condition. 534 3.1.2.1 Connectivity Verification 536 EVPN Network OAM MUST support on-demand connectivity verification 537 mechanisms for unicast and multicast destinations. The connectivity 538 verification mechanisms SHOULD provide a means for specifying and 539 carrying in the messages: 541 - variable length payload/padding to test MTU related connectivity 542 problems. 544 - test frame formats as defined in Appendix C of [RFC2544] to detect 545 potential packet corruption. 547 EVPN Network OAM MUST support connectivity verification at per flow 548 granularity. This includes both user flows (to test a specific path 549 between PEs) as well as test flows (to test a representative path 550 between PEs). 552 EVPN Service OAM MUST support connectivity verification on test flows 553 and MAY support connectivity verification on user flows. 555 For multicast connectivity verification, EVPN Network OAM MUST 556 support reporting on: 558 - the DF filtering status of specific port(s) or all the ports in a 559 given bridge-domain. 561 - the Split Horizon filtering status of specific port(s) or all the 562 ports in a given bridge-domain. 564 3.1.2.2 Fault Isolation 566 EVPN OAM MUST support an on-demand fault localization function. This 567 involves the capability to narrow down the locality of a fault to a 568 particular port, link or node. The characteristic of forward/reverse 569 path asymmetry, in MPLS/IP, makes fault isolation a direction- 570 sensitive operation. That is, given two PEs A and B, localization of 571 continuity failures between them requires running fault isolation 572 procedures from PE A to PE B as well as from PE B to PE A. 574 EVPN Service OAM mechanisms only have visibility to the PEs but not 575 the MPLS/IP P nodes. As such, they can be used to deduce whether the 576 fault is in the customer's own network, the local CE-PE segment or 577 remote CE-PE segment(s). EVPN Network and Transport OAM mechanisms 578 can be used for fault isolation between the PEs and P nodes. 580 3.2 Performance Management 582 Performance Management functions can be performed both proactively 583 and on-demand. Proactive management involves a recurring function, 584 where the performance management probes are run continuously without 585 a trigger. We cover both proactive and on-demand functions in this 586 section. 588 3.2.1 Packet Loss 590 EVPN Network OAM SHOULD provide mechanisms for measuring packet loss 591 for a given service. 593 Given that EVPN provides inherent support for multipoint-to- 594 multipoint connectivity, then packet loss cannot be accurately 595 measured by means of counting user data packets. This is because user 596 packets can be delivered to more PEs or more ports than are necessary 597 (e.g., due to broadcast, un-pruned multicast or unknown unicast 598 flooding). As such, a statistical means of approximating packet loss 599 rate is required. This can be achieved by sending "synthetic" OAM 600 packets that are counted only by those ports (MEPs) that are required 601 to receive them. This provides a statistical approximation of the 602 number of data frames lost, even with multipoint-to-multipoint 603 connectivity. 605 3.2.2 Packet Delay 607 EVPN Service OAM SHOULD support measurement of one-way and two-way 608 packet delay and delay variation (jitter) across the EVPN network. 609 Measurement of one-way delay requires clock synchronization between 610 the probe source and target devices. Mechanisms for clock 611 synchronization are outside the scope of this document. Note that 612 Service OAM performance management mechanisms defined in [Y.1731] can 613 be used. 615 EVPN Network OAM MAY support measurement of one-way and two-way 616 packet delay and delay variation (jitter) across the EVPN network. 618 4. Security Considerations 620 EVPN OAM MUST prevent OAM packets from leaking outside of the EVPN 621 network or outside their corresponding Maintenance Domain. This can 622 be done for CFM, for example, by having MEPs implement a filtering 623 function based on the Maintenance Level associated with received OAM 624 packets. 626 EVPN OAM SHOULD provide mechanisms for implementation and optional 627 use to: 629 - Prevent denial of service attacks caused by exploitation of the OAM 630 message channel (for example by forging messages to exceed a 631 maintenance end point's capacity to maintain state). 633 - Authenticate communicating endpoints (for example MEPs and MIPs). 635 5. IANA Considerations 637 This document requires no IANA actions. 639 6. Acknowledgements 641 The authors would like to thank the following for their review of 642 this work and valuable comments: 644 David Black, Xiao Min, Gregory Mirsky, Dave Schinazi, Melinda 645 Shore, Alexander Vainshtein, and Stig Venaas. 647 Normative References 649 [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 650 792, DOI 10.17487/RFC0792, September 1981, 651 . 653 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 654 Requirement Levels", BCP 14, RFC 2119, DOI 655 10.17487/RFC2119, March 1997, . 658 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 659 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 660 . 662 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 663 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 664 10.17487/RFC5881, June 2010, . 667 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 668 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 669 June 2010, . 671 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 672 "Bidirectional Forwarding Detection (BFD) for MPLS Label 673 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 674 June 2010, .< 676 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., 677 and S. Mansfield, "Guidelines for the Use of the "OAM" 678 Acronym in the IETF", BCP 161, RFC 6291, DOI 679 10.17487/RFC6291, June 2011, . 682 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 683 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures 684 in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 685 6425, DOI 10.17487/RFC6425, November 2011, 686 . 688 [RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed., 689 "Proactive Connectivity Verification, Continuity Check, and 690 Remote Defect Indication for the MPLS Transport Profile", 691 RFC 6428, DOI 10.17487/RFC6428, November 2011, 692 . 694 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 695 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 696 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 697 2015, . 699 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 700 Henderickx, "Provider Backbone Bridging Combined with 701 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 702 September 2015, . 704 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 705 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 706 Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 707 10.17487/RFC8029, March 2017, . 710 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 711 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 712 2017, 714 Informative References 716 [802.1Q] "IEEE Standard for Local and metropolitan area networks - 717 Media Access Control (MAC) Bridges and Virtual Bridge Local 718 Area Networks", 2014. 720 [Y.1731] "ITU-T Recommendation Y.1731 (02/08) - OAM functions and 721 mechanisms for Ethernet based networks", February 2008. 723 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 724 Network Interconnect Devices", RFC 2544, DOI 725 10.17487/RFC2544, March 1999, . 728 [RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual 729 Circuit Connectivity Verification (VCCV): A Control Channel 730 for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 731 2007, . 733 [RFC6136] Sajassi, A., Ed., and D. Mohan, Ed., "Layer 2 Virtual 734 Private Network (L2VPN) Operations, Administration, and 735 Maintenance (OAM) Requirements and Framework", RFC 6136, 736 DOI 10.17487/RFC6136, March 2011, . 739 Authors' Addresses 741 Samer Salam 742 Cisco 744 Email: ssalam@cisco.com 746 Ali Sajassi 747 Cisco 748 170 West Tasman Drive 749 San Jose, CA 95134, USA 751 Email: sajassi@cisco.com 753 Sam Aldrin 754 Google, Inc. 755 1600 Amphitheatre Parkway 756 Mountain View, CA 94043 USA 758 Email: aldrin.ietf@gmail.com 760 John E. Drake 761 Juniper Networks 762 1194 N. Mathilda Ave. 763 Sunnyvale, CA 94089, USA 765 Email: jdrake@juniper.net 767 Donald E. Eastlake, 3rd 768 Futurewei Technologies 769 2386 Panoramic Circle 770 Apopka, FL 32703 USA 772 Tel: +1-508-333-2270 773 Email: d3e3e3@gmail.com