idnits 2.17.1 draft-ietf-bess-evpn-oam-req-frmwk-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2020) is 1386 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: January 2, 2021 July 3, 2020 12 EVPN Operations, Administration and Maintenance 13 Requirements and Framework 14 draft-ietf-bess-evpn-oam-req-frmwk-03 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. The 21 framework defines the layered OAM model encompassing the EVPN service 22 layer, network layer and underlying Packet Switched Network (PSN) 23 transport layer. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 42 Shadow Directories can be accessed at http://www.ietf.org/shadow.html 44 Copyright and License Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction............................................4 62 1.1 Relationship to Other OAM Work.........................4 63 1.2 Specification of Requirements..........................5 64 1.3 Terminology............................................5 66 2. EVPN OAM Framework......................................6 67 2.1 OAM Layering...........................................6 68 2.2 EVPN Service OAM.......................................7 69 2.3 EVPN Network OAM.......................................8 70 2.4 Transport OAM for EVPN.................................9 71 2.5 Link OAM...............................................9 72 2.6 OAM Inter-working.....................................10 74 3. EVPN OAM Requirements..................................11 75 3.1 Fault Management Requirements.........................11 76 3.1.1 Proactive Fault Management Functions................11 77 3.1.1.1 Fault Detection (Continuity Check)................11 78 3.1.1.2 Defect Indication.................................12 79 3.1.1.2.1 Forward Defect Indication.......................12 80 3.1.1.2.2 Reverse Defect Indication (RDI).................12 81 3.1.2 On-Demand Fault Management Functions................13 82 3.1.2.1 Connectivity Verification.........................13 83 3.1.2.2 Fault Isolation...................................14 84 3.2 Performance Management................................14 85 3.2.1 Packet Loss.........................................14 86 3.2.2 Packet Delay........................................15 88 4. Security Considerations................................16 89 5. Acknowledgements.......................................16 90 6. IANA Considerations....................................16 92 Normative References......................................17 93 Informative References....................................18 95 1. Introduction 97 This document specifies the requirements and defines a reference 98 framework for Ethernet VPN (EVPN) Operations, Administration and 99 Maintenance (OAM, [RFC6291]). In this context, we use the term EVPN 100 OAM to loosely refer to the OAM functions required for and/or 101 applicable to [RFC7432] and [RFC7623]. 103 EVPN is an Layer 2 VPN (L2VPN) solution for multipoint Ethernet 104 services, with advanced multi-homing capabilities, using BGP for 105 distributing customer/client MAC address reachability information 106 over the core MPLS/IP network. 108 PBB-EVPN combines Provider Backbone Bridging (PBB) [802.1Q] with EVPN 109 in order to reduce the number of BGP MAC advertisement routes, 110 provide client MAC address mobility using C-MAC aggregation and B-MAC 111 sub-netting, confine the scope of C-MAC learning to only active 112 flows, offer per site policies, and avoid C-MAC address flushing on 113 topology changes. 115 This document focuses on the fault management and performance 116 management aspects of EVPN OAM. 118 1.1 Relationship to Other OAM Work 120 This document leverages concepts and draws upon elements defined 121 and/or used in the following documents: 123 [RFC6136] specifies the requirements and a reference model for OAM as 124 it relates to L2VPN services, pseudowires and associated Packet 125 Switched Network (PSN) tunnels. This document focuses on VPLS and 126 VPWS solutions and services. 128 [RFC8029] defines mechanisms for detecting data plane failures in 129 MPLS LSPs, including procedures to check the correct operation of the 130 data plane, as well as mechanisms to verify the data plane against 131 the control plane. 133 [802.1Q] specifies the Ethernet Connectivity Fault Management (CFM) 134 protocol, which defines the concepts of Maintenance Domains, 135 Maintenance Associations, Maintenance End Points, and Maintenance 136 Intermediate Points. 138 [Y.1731] extends Connectivity Fault Management in the following 139 areas: it defines fault notification and alarm suppression functions 140 for Ethernet. It also specifies mechanisms for Ethernet performance 141 management, including loss, delay, jitter, and throughput 142 measurement. 144 1.2 Specification of Requirements 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119] [RFC8174] 149 when, and only when, they appear in all capitals, as shown here. 151 1.3 Terminology 153 This document uses the following terminology defined in [RFC6136]: 155 CE Customer Edge device, e.g., a host, router, or switch. 157 DF Designated Forwarder 159 EVI An EVPN instance spanning the Provider Edge (PE) devices 160 participating in that EVPN. 162 MA Maintenance Association is a set of MEPs belonging to the same 163 Maintenance Domain, established to verify the integrity of a 164 single service instance. 166 MEP Maintenance End Point is responsible for origination and 167 termination of OAM frames for a given MA. 169 MIP Maintenance Intermediate Point is located between peer MEPs and 170 can process and respond to certain OAM frames but does not 171 initiate them. 173 MD Maintenance Domain, an OAM Domain that represents a region over 174 which OAM frames can operate unobstructed. 176 MP2P Multipoint to Point. 178 P2MP Point to Multipoint. 180 PE Provider Edge device. 182 2. EVPN OAM Framework 184 2.1 OAM Layering 186 Multiple layers come into play for implementing an L2VPN service 187 using the EVPN family of solutions: 189 - The Service Layer runs end to end between the sites or Ethernet 190 Segments that are being interconnected by the EVPN solution. 192 - The Network Layer extends between the EVPN PE nodes and is mostly 193 transparent to the core nodes (except where Flow Entropy comes into 194 play). It leverages MPLS for service (i.e. EVI) multiplexing and 195 Split-Horizon functions. 197 - The Transport Layer is dictated by the networking technology of the 198 PSN. It may be either based on MPLS LSPs or IP. 200 - The Link Layer is dependent upon the physical technology used. 201 Ethernet is a popular choice for this layer, but other alternatives 202 are deployed (e.g. POS, DWDM etc.). 204 This layering extends to the set of OAM protocols that are involved 205 in the ongoing maintenance and diagnostics of EVPN networks. The 206 figure below depicts the OAM layering, and shows which devices have 207 visibility into what OAM layer(s). 209 +---+ +---+ 210 +--+ | | +---+ +---+ +---+ | | +--+ 211 |CE|----|PE1|----| P |----| P |----| P |----|PE2|----|CE| 212 +--+ | | +---+ +---+ +---+ | | +--+ 213 +---+ +---+ 215 o--------o--------- Service OAM -------------o--------o 217 o----------- Network OAM -----------o 219 o--------o--------o---------o-------o Transport OAM 221 o-----o o-----o o-----o o-----o o-----o o-----o Link OAM 223 Figure 1: OAM Layering 225 Service OAM and Network OAM mechanisms only have visibility to the 226 PEs but not the P nodes. As such, they can be used to deduce whether 227 the fault is in the customer's own network, the local CE-PE segment, 228 the PE-PE segment or the remote CE-PE segment(s). EVPN Transport OAM 229 mechanisms can be used for fault isolation between the PEs and P 230 nodes. 232 Figure 2 below shows an example network where native Ethernet domains 233 are interconnected via EVPN, and the OAM mechanisms applicable at 234 each layer. The details of the layers are described in the sections 235 below. 237 +---+ +---+ 238 +--+ | | +---+ +---+ +---+ | | +--+ 239 |CE|----|PE1|----| P |----| P |----| P |----|PE2|----|CE| 240 +--+ | | +---+ +---+ +---+ | | +--+ 241 +---+ +---+ 243 o--------o--------- Service CFM -------------o--------o 245 o-------- EVPN Network OAM ---------o 247 o--------o--------o---------o-------o MPLS OAM 249 o-----o o-----o o-----o o-----o o-----o o-----o 802.3 OAM 251 Figure 2: EVPN OAM Example 253 2.2 EVPN Service OAM 255 The EVPN Service OAM protocol depends on what service layer 256 technology is being interconnected by the EVPN solution. In case of 257 [RFC7432] and [RFC7623], the service layer is Ethernet; hence, the 258 corresponding service OAM protocol is Ethernet Connectivity Fault 259 Management (CFM) [802.1Q]. 261 EVPN service OAM is visible to the CEs and EVPN PEs, but not to the 262 core (P) nodes. This is because the PEs operate at the Ethernet MAC 263 layer in [RFC7432] [RFC7623] whereas the P nodes do not. 265 The EVPN PE MUST support MIP functions in the applicable service OAM 266 protocol, for example Ethernet CFM. The EVPN PE SHOULD support MEP 267 functions in the applicable service OAM protocol. This includes both 268 Up and Down MEP functions. As shown in Figure 3, the MIP and MEP 269 functions being referred to are logically located within the CE 270 facing port of a PE. Down MEP functions are towards the CE. Up MEP 271 functions are towards the PE forwarding mechanism. CFM between the PE 272 Up MEPs is a type of EVPN Network OAM while CFM between the CEs or 273 from a PE to its local CE or to the remote CE is Service OAM. 275 +-------+ +---------------+ +---------------+ +-------+ 276 | CE | | PE1 | ... | PE2 | | CE | 277 +---+---+ +---+--------+--+ +--+--------+---+ +---+---+ 278 | | | | | | 279 | +----+----+ | | +----+----+ | 280 +--+--+ | up^ | . . |up^ | +--+--+ 281 | MEP | |MIP|MEP | . ... . |MEP |MIP| | MEP | 282 |downV| | downV| . . |downV | |downV| 283 +--+--+ +----+----+ | | +----+----+ +--+--+ 284 | | | | | | 285 +-----------+ +--- ... ---+ +------------+ 287 Figure 3: CFM Details 289 The EVPN PE MUST learn the MAC address of locally attached CE MEPs by 290 snooping on CFM frames and advertising them to remote PEs as a MAC/IP 291 Advertisement route. 293 The EVPN PE SHOULD advertise any MEP/MIP local to the PE as a MAC/IP 294 Advertisement route. Since these are not subject to mobility, they 295 SHOULD be advertised with the static (sticky) bit set (see Section 296 15.2 of [RFC7432]). 298 2.3 EVPN Network OAM 300 EVPN Network OAM is visible to the PE nodes only. This OAM layer is 301 analogous to VCCV [RFC5085] in the case of VPLS/VPWS. It provides 302 mechanisms to check the correct operation of the data plane, as well 303 as a mechanism to verify the data plane against the control plane. 304 This includes the ability to perform fault detection and diagnostics 305 on: 307 - the MP2P tunnels used for the transport of unicast traffic between 308 PEs. EVPN allows for three different models of unicast label 309 assignment: label per EVI, label per and label 310 per MAC address. In all three models, the label is bound to an EVPN 311 Unicast FEC. 313 EVPN Network OAM MUST provide mechanisms to check the operation of 314 the data plane and verify that operation against the control plane 315 view. 317 - the MP2P tunnels used for aliasing unicast traffic destined to a 318 multi-homed Ethernet Segment. The three label assignment models, 319 discussed above, apply here as well. In all three models, the label 320 is bound to an EVPN Aliasing FEC. EVPN Network OAM MUST provide 321 mechanisms to check the operation of the data plane and verify that 322 operation against the control plane view. 324 - the multicast tunnels (either MP2P or P2MP) used for the transport 325 of broadcast, unknown unicast and multicast traffic between PEs. In 326 the case of ingress replication, a label is allocated per EVI or 327 per and is bound to an EVPN Multicast FEC. In 328 the case of LSM, and more specifically aggregate inclusive trees, 329 again a label may be allocated per EVI or per 330 and is bound to the tunnel FEC. 332 - the correct operation of the ESI split-horizon filtering function. 333 In EVPN, a label is allocated per multi-homed Ethernet Segment for 334 the purpose of performing the access split-horizon enforcement. The 335 label is bound to an EVPN Ethernet Segment. 337 - the correct operation of the DF filtering function. 339 EVPN Network OAM MUST provide mechanisms to check the operation of 340 the data plane and verify that operation against the control plane 341 view for the DF filtering function. 343 EVPN network OAM mechanisms MUST provide in-band management 344 capabilities. As such, OAM messages MUST be encoded so that they 345 exhibit identical entropy characteristics to data traffic. 347 EVPN network OAM SHOULD provide both proactive and on-demand 348 mechanisms of monitoring the data plane operation and data plane 349 conformance to the state of the control plane. 351 2.4 Transport OAM for EVPN 353 The transport OAM protocol depends on the nature of the underlying 354 transport technology in the PSN. MPLS OAM mechanisms [RFC8029] 355 [RFC6425] as well as ICMP [RFC792] are applicable, depending on 356 whether the PSN employs MPLS or IP transport, respectively. 357 Furthermore, BFD mechanisms per [RFC5880], [RFC5881], [RFC5883] and 358 [RFC5884] apply. Also, the BFD mechanisms pertaining to MPLS-TP LSPs 359 per [RFC6428] are applicable. 361 2.5 Link OAM 363 Link OAM depends on the data link technology being used between the 364 PE and P nodes. For example, if Ethernet links are employed, then 365 Ethernet Link OAM [802.3] Clause 57 may be used. 367 2.6 OAM Inter-working 369 When inter-working two networking domains, such as native Ethernet 370 and EVPN to provide an end-to-end emulated service, there is a need 371 to identify the failure domain and location, even when a PE supports 372 both the Service OAM mechanisms and the EVPN Network OAM mechanisms. 373 In addition, scalability constraints may not allow running proactive 374 monitoring, such as Ethernet Continuity Check Messages (CCMs), at a 375 PE to detect the failure of an EVI across the EVPN domain. Thus, the 376 mapping of alarms generated upon failure detection in one domain 377 (e.g. native Ethernet or EVPN network domain) to the other domain is 378 needed. There are also cases where a PE may not be able to process 379 Service OAM messages received from a remote PE over the PSN even when 380 such messages are defined, as in the Ethernet case, thereby 381 necessitating support for fault notification message mapping between 382 the EVPN Network domain and the Service domain. 384 OAM inter-working is not limited though to scenarios involving 385 disparate network domains. It is possible to perform OAM inter- 386 working across different layers in the same network domain. In 387 general, alarms generated within an OAM layer, as a result of 388 proactive fault detection mechanisms, may be injected into its client 389 layer OAM mechanisms. This allows the client layer OAM to trigger 390 event-driven (i.e., asynchronous) fault notifications. For example, 391 alarms generated by the Link OAM mechanisms may be injected into the 392 Transport OAM layer, and alarms generated by the Transport OAM 393 mechanism may be injected into the Network OAM mechanism, and so on. 395 EVPN OAM MUST support inter-working between the Network OAM and 396 Service OAM mechanisms. EVPN OAM MAY support inter-working among 397 other OAM layers. 399 3. EVPN OAM Requirements 401 This section discusses the EVPN OAM requirements pertaining to Fault 402 Management and Performance Management. 404 3.1 Fault Management Requirements 406 3.1.1 Proactive Fault Management Functions 408 The network operator configures proactive fault management functions 409 to run periodically without a time bound. Certain actions, for 410 example protection switchover or alarm indication signaling, can be 411 associated with specific events, such as entering or clearing fault 412 states. 414 3.1.1.1 Fault Detection (Continuity Check) 416 Proactive fault detection is performed by periodically monitoring the 417 reachability between service endpoints, i.e., MEPs in a given MA, 418 through the exchange of Continuity Check messages. The reachability 419 between any two arbitrary MEPs may be monitored for: 421 - in-band per-flow monitoring. This enables per flow monitoring 422 between MEPs. EVPN Network OAM MUST support fault detection with 423 per user flow granularity. EVPN Service OAM MAY support fault 424 detection with per user flow granularity. 426 - a representative path. This enables liveness check of the nodes 427 hosting the MEPs assuming that the loss of continuity to the MEP is 428 interpreted as a failure of the hosting node. This, however, does 429 not conclusively indicate liveness of the path(s) taken by user 430 data traffic. This enables node failure detection but not path 431 failure detection, through the use of a test flow. EVPN Network OAM 432 and Service OAM MUST support fault detection using test flows. 434 - all paths. For MPLS/IP networks with ECMP, monitoring of all 435 unicast paths between MEPs (on non-adjacent nodes) may not be 436 possible, since the per-hop ECMP hashing behavior may yield 437 situations where it is impossible for a MEP to pick flow entropy 438 characteristics that result in exercising the exhaustive set of 439 ECMP paths. Monitoring of all ECMP paths between MEPs (on non- 440 adjacent nodes) is not a requirement for EVPN OAM. 442 The fact that MPLS/IP networks do not enforce congruency between 443 unicast and multicast paths means that the proactive fault detection 444 mechanisms for EVPN networks MUST provide procedures to monitor the 445 unicast paths independently of the multicast paths. This applies to 446 EVPN Service OAM and Network OAM. 448 3.1.1.2 Defect Indication 450 EVPN Service OAM MUST support event-driven defect indication upon the 451 detection of a connectivity defect. Defect indications can be 452 categorized into two types: forward and reverse defect indications. 454 3.1.1.2.1 Forward Defect Indication 456 This is used to signal a failure that is detected by a lower layer 457 OAM mechanism. A server MEP (i.e. an actual or virtual MEP) transmits 458 a Forward Defect Indication in a direction that is away from the 459 direction of the failure (refer to Figure 4 below). 461 Failure 462 | 463 +-----+ +-----+ V +-----+ +-----+ 464 | A |------| B |--XXX--| C |------| D | 465 +-----+ +-----+ +-----+ +-----+ 467 <===========| |============> 468 Forward Forward 469 Defect Defect 470 Indication Indication 472 Figure 4: Forward Defect Indication 474 Forward defect indication may be used for alarm suppression and/or 475 for purpose of inter-working with other layer OAM protocols. Alarm 476 suppression is useful when a transport/network level fault translates 477 to multiple service or flow level faults. In such a scenario, it is 478 enough to alert a network management station (NMS) of the single 479 transport/network level fault in lieu of flooding that NMS with a 480 multitude of Service or Flow granularity alarms. EVPN PEs SHOULD 481 support Forward Defect Indication in the Service OAM mechanisms. 483 3.1.1.2.2 Reverse Defect Indication (RDI) 485 RDI is used to signal that the advertising MEP has detected a loss of 486 continuity (LoC) defect. RDI is transmitted in the direction of the 487 failure (refer to Figure 5). 489 Failure 490 | 491 +-----+ +-----+ V +-----+ +-----+ 492 | A |------| B |--XXX--| C |------| D | 493 +-----+ +-----+ +-----+ +-----+ 495 |===========> <============| 496 Reverse Reverse 497 Defect Defect 498 Indication Indication 500 Figure 5: Reverse Defect Indication 502 RDI allows single-sided management, where the network operator can 503 examine the state of a single MEP and deduce the overall health of a 504 monitored service. EVPN PEs SHOULD support Reverse Defect Indication 505 in the Service OAM mechanisms. This includes both the ability to 506 signal LoC defect to a remote MEP, as well as the ability to 507 recognize RDI from a remote MEP. Note that, in a multipoint MA, RDI 508 is not a useful indicator of unidirectional fault. This is because 509 RDI carries no indication of the affected MEP(s) with which the 510 sender had detected a LoC defect. 512 3.1.2 On-Demand Fault Management Functions 514 On-demand fault management functions are initiated manually by the 515 network operator and continue for a time bound period. These 516 functions enable the operator to run diagnostics to investigate a 517 defect condition. 519 3.1.2.1 Connectivity Verification 521 EVPN Network OAM MUST support on-demand connectivity verification 522 mechanisms for unicast and multicast destinations. The connectivity 523 verification mechanisms SHOULD provide a means for specifying and 524 carrying in the messages: 526 - variable length payload/padding to test MTU related connectivity 527 problems. 529 - test frame formats as defined in Appendix C of [RFC2544] to detect 530 potential packet corruption. 532 EVPN Network OAM MUST support connectivity verification at per flow 533 granularity. This includes both user flows (to test a specific path 534 between PEs) as well as test flows (to test a representative path 535 between PEs). 537 EVPN Service OAM MUST support connectivity verification on test flows 538 and MAY support connectivity verification on user flows. 540 For multicast connectivity verification, EVPN Network OAM MUST 541 support reporting on: 543 - the DF filtering status of specific port(s) or all the ports in a 544 given bridge-domain. 546 - the Split Horizon filtering status of specific port(s) or all the 547 ports in a given bridge-domain. 549 3.1.2.2 Fault Isolation 551 EVPN OAM MUST support an on-demand fault localization function. This 552 involves the capability to narrow down the locality of a fault to a 553 particular port, link or node. The characteristic of forward/reverse 554 path asymmetry, in MPLS/IP, makes fault isolation a direction- 555 sensitive operation. That is, given two PEs A and B, localization of 556 continuity failures between them requires running fault isolation 557 procedures from PE A to PE B as well as from PE B to PE A. 559 EVPN Service OAM mechanisms only have visibility to the PEs but not 560 the MPLS/IP P nodes. As such, they can be used to deduce whether the 561 fault is in the customer's own network, the local CE-PE segment or 562 remote CE-PE segment(s). EVPN Network and Transport OAM mechanisms 563 can be used for fault isolation between the PEs and P nodes. 565 3.2 Performance Management 567 Performance Management functions can be performed both proactively 568 and on-demand. Proactive management involves a recurring function, 569 where the performance management probes are run continuously without 570 a trigger. We cover both proactive and on-demand functions in this 571 section. 573 3.2.1 Packet Loss 575 EVPN Network OAM SHOULD provide mechanisms for measuring packet loss 576 for a given service. 578 Given that EVPN provides inherent support for multipoint-to- 579 multipoint connectivity, then packet loss cannot be accurately 580 measured by means of counting user data packets. This is because user 581 packets can be delivered to more PEs or more ports than are necessary 582 (e.g. due to broadcast, un-pruned multicast or unknown unicast 583 flooding). As such, a statistical means of approximating packet loss 584 rate is required. This can be achieved by sending "synthetic" OAM 585 packets that are counted only by those ports (MEPs) that are required 586 to receive them. This provides a statistical approximation of the 587 number of data frames lost, even with multipoint-to-multipoint 588 connectivity. 590 3.2.2 Packet Delay 592 EVPN Service OAM SHOULD support measurement of one-way and two-way 593 packet delay and delay variation (jitter) across the EVPN network. 594 Measurement of one-way delay requires clock synchronization between 595 the probe source and target devices. Mechanisms for clock 596 synchronization are outside the scope of this document. Note that 597 Service OAM performance management mechanisms defined in [Y.1731] can 598 be used. 600 EVPN Network OAM MAY support measurement of one-way and two-way 601 packet delay and delay variation (jitter) across the EVPN network. 603 4. Security Considerations 605 EVPN OAM must provide mechanisms for: 607 - Preventing denial of service attacks caused by exploitation of the 608 OAM message channel. 610 - Optionally authenticate communicating endpoints (MEPs and MIPs). 612 - Preventing OAM packets from leaking outside of the EVPN network or 613 outside their corresponding Maintenance Domain. This can be done by 614 having MEPs implement a filtering function based on the Maintenance 615 Level associated with received OAM packets. 617 5. Acknowledgements 619 The authors would like to thank the following for their review of 620 this work and valuable comments: 622 Gregory Mirsky, Alexander Vainshtein, Xiao Min 624 6. IANA Considerations 626 This document requires no IANA actions. 628 Normative References 630 [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 631 792, DOI 10.17487/RFC0792, September 1981, 632 . 634 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 635 Requirement Levels", BCP 14, RFC 2119, DOI 636 10.17487/RFC2119, March 1997, . 639 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 640 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 641 . 643 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 644 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 645 10.17487/RFC5881, June 2010, . 648 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 649 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 650 June 2010, . 652 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 653 "Bidirectional Forwarding Detection (BFD) for MPLS Label 654 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 655 June 2010, .< 657 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., 658 and S. Mansfield, "Guidelines for the Use of the "OAM" 659 Acronym in the IETF", BCP 161, RFC 6291, DOI 660 10.17487/RFC6291, June 2011, . 663 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 664 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures 665 in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 666 6425, DOI 10.17487/RFC6425, November 2011, 667 . 669 [RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed., 670 "Proactive Connectivity Verification, Continuity Check, and 671 Remote Defect Indication for the MPLS Transport Profile", 672 RFC 6428, DOI 10.17487/RFC6428, November 2011, 673 . 675 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 676 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 677 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 678 2015, . 680 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 681 Henderickx, "Provider Backbone Bridging Combined with 682 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 683 September 2015, . 685 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 686 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 687 Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 688 10.17487/RFC8029, March 2017, . 691 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 692 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 693 2017, 695 Informative References 697 [802.1Q] "IEEE Standard for Local and metropolitan area networks - 698 Media Access Control (MAC) Bridges and Virtual Bridge Local 699 Area Networks", 2014. 701 [Y.1731] "ITU-T Recommendation Y.1731 (02/08) - OAM functions and 702 mechanisms for Ethernet based networks", February 2008. 704 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 705 Network Interconnect Devices", RFC 2544, DOI 706 10.17487/RFC2544, March 1999, . 709 [RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual 710 Circuit Connectivity Verification (VCCV): A Control Channel 711 for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 712 2007, . 714 [RFC6136] Sajassi, A., Ed., and D. Mohan, Ed., "Layer 2 Virtual 715 Private Network (L2VPN) Operations, Administration, and 716 Maintenance (OAM) Requirements and Framework", RFC 6136, 717 DOI 10.17487/RFC6136, March 2011, . 720 Authors' Addresses 722 Samer Salam 723 Cisco 725 Email: ssalam@cisco.com 727 Ali Sajassi 728 Cisco 729 170 West Tasman Drive 730 San Jose, CA 95134, USA 732 Email: sajassi@cisco.com 734 Sam Aldrin 735 Google, Inc. 736 1600 Amphitheatre Parkway 737 Mountain View, CA USA 739 Email: aldrin.ietf@gmail.com 741 John E. Drake 742 Juniper Networks 743 1194 N. Mathilda Ave. 744 Sunnyvale, CA 94089, USA 746 Email: jdrake@juniper.net 748 Donald E. Eastlake, 3rd 749 Futurewei Technologies 750 2386 Panoramic Circle 751 Apopka, FL 32703 USA 753 Tel: +1-508-333-2270 754 Email: d3e3e3@gmail.com