idnits 2.17.1 draft-ietf-bess-evpn-oam-req-frmwk-07.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 27, 2021) is 1098 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 26, 2021 March 27, 2021 12 EVPN Operations, Administration and Maintenance 13 Requirements and Framework 14 draft-ietf-bess-evpn-oam-req-frmwk-07 16 Abstract 18 This document specifies the requirements and reference framework for 19 Ethernet VPN (EVPN) Operations, Administration and Maintenance (OAM). 20 The requirements cover the OAM aspects of EVPN and PBB-EVPN (Provider 21 Backbone Bridge EVPN). The framework defines the layered OAM model 22 encompassing the EVPN service layer, network layer, underlying Packet 23 Switched Network (PSN) transport layer, and link layer but focuses on 24 the service and network layers. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 43 Shadow Directories can be accessed at http://www.ietf.org/shadow.html 45 Copyright and License Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction............................................4 63 1.1 Relationship to Other OAM Work.........................4 64 1.2 Specification of Requirements..........................5 65 1.3 Terminology............................................5 67 2. EVPN OAM Framework......................................7 68 2.1 OAM Layering...........................................7 69 2.2 EVPN Service OAM.......................................8 70 2.3 EVPN Network OAM.......................................9 71 2.4 Transport OAM for EVPN................................10 72 2.5 Link OAM..............................................11 73 2.6 OAM Inter-working.....................................11 75 3. EVPN OAM Requirements..................................12 76 3.1 Fault Management Requirements.........................12 77 3.1.1 Proactive Fault Management Functions................12 78 3.1.1.1 Fault Detection (Continuity Check)................12 79 3.1.1.2 Defect Indication.................................13 80 3.1.1.2.1 Forward Defect Indication.......................13 81 3.1.1.2.2 Reverse Defect Indication (RDI).................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 and Jitter.............................16 89 4. Security Considerations................................17 90 5. IANA Considerations....................................17 91 6. Acknowledgements.......................................17 93 Normative References......................................18 94 Informative References....................................19 96 1. Introduction 98 This document specifies the requirements and defines a reference 99 framework for Ethernet VPN (EVPN) Operations, Administration and 100 Maintenance (OAM, [RFC6291]). In this context, we use the term EVPN 101 OAM to loosely refer to the OAM functions required for and/or 102 applicable to [RFC7432] and [RFC7623]. 104 EVPN is an Layer 2 VPN (L2VPN) solution for multipoint Ethernet 105 services, with advanced multi-homing capabilities, using BGP for 106 distributing customer/client MAC address reachability information 107 over the core MPLS/IP network. 109 PBB-EVPN combines Provider Backbone Bridging (PBB) [802.1Q] with EVPN 110 in order to reduce the number of BGP MAC advertisement routes, 111 provide client MAC address mobility using C-MAC aggregation and B-MAC 112 sub-netting, confine the scope of C-MAC learning to only active 113 flows, offer per site policies, and avoid C-MAC address flushing on 114 topology changes. 116 This document focuses on the fault management and performance 117 management aspects of EVPN OAM. It defines the layered OAM model 118 encompassing the EVPN service layer, network layer, underlying Packet 119 Switched Network (PSN) transport layer, and link layer but focuses on 120 the service and network layers. 122 1.1 Relationship to Other OAM Work 124 This document leverages concepts and draws upon elements defined 125 and/or used in the following documents: 127 [RFC6136] specifies the requirements and a reference model for OAM as 128 it relates to L2VPN services, pseudowires and associated Packet 129 Switched Network (PSN) tunnels. This document focuses on VPLS and 130 VPWS solutions and services. 132 [RFC8029] defines mechanisms for detecting data plane failures in 133 MPLS LSPs, including procedures to check the correct operation of the 134 data plane, as well as mechanisms to verify the data plane against 135 the control plane. 137 [802.1Q] specifies the Ethernet Connectivity Fault Management (CFM) 138 protocol, which defines the concepts of Maintenance Domains, 139 Maintenance Associations, Maintenance End Points, and Maintenance 140 Intermediate Points. 142 [Y.1731] extends Connectivity Fault Management in the following 143 areas: it defines fault notification and alarm suppression functions 144 for Ethernet. It also specifies mechanisms for Ethernet performance 145 management, including loss, delay, jitter, and throughput 146 measurement. 148 1.2 Specification of Requirements 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in BCP 153 14 [RFC2119] [RFC8174] when, and only when, they appear in all 154 capitals, as shown here. 156 1.3 Terminology 158 This document uses the following terminology much of which is defined 159 in [RFC6136]: 161 CE Customer Edge device, e.g., a host, router, or switch. 163 DF Designated Forwarder 165 Down MEP A MEP that originates traffic away from and terminates 166 traffic towards the device in whose port it is logically 167 located. 169 EVI An EVPN instance spanning the Provider Edge (PE) devices 170 participating in that EVPN. 172 L2VPN Layer 2 VPN. 174 MA Maintenance Association is a set of MEPs belonging to the same 175 Maintenance Domain, established to verify the integrity of a 176 single service instance. 178 MEP Maintenance End Point is responsible for origination and 179 termination of OAM frames for a given MA. A MEP is logically 180 located in a device's port. 182 MIP Maintenance Intermediate Point is located between peer MEPs and 183 can process and respond to certain OAM frames but does not 184 initiate them. A MIP is logically located in a device's port. 186 MD Maintenance Domain, an OAM Domain that represents a region over 187 which OAM frames can operate unobstructed. 189 MP2P Multipoint to Point. 191 P Provider (non-edge) device. 193 P2MP Point to Multipoint. 195 PBB Provider Backbone Bridge. 197 PE Provider Edge device. 199 Up MEP A MEP that originates traffic towards and terminates traffic 200 from the device in whose port it is logically located. 202 VPN Virtual Private Network 204 2. EVPN OAM Framework 206 2.1 OAM Layering 208 Multiple layers come into play for implementing an L2VPN service 209 using the EVPN family of solutions as listed below. The focus of this 210 document is the Service and Network layers. 212 - The Service Layer runs end to end between the sites or Ethernet 213 Segments that are being interconnected by the EVPN solution. 215 - The Network Layer extends between the EVPN PE (Provider Edge) nodes 216 and is mostly transparent to the core P (Provider) nodes (except 217 where Flow Entropy comes into play). It leverages MPLS for service 218 (i.e., EVI) multiplexing and Split-Horizon functions. 220 - The Transport Layer is dictated by the networking technology of the 221 PSN. It may be either based on MPLS LSPs or IP. 223 - The Link Layer is dependent upon the physical technology used. 224 Ethernet is a popular choice for this layer, but other alternatives 225 are deployed (e.g., POS, DWDM etc.). 227 This layering extends to the set of OAM protocols that are involved 228 in the ongoing maintenance and diagnostics of EVPN networks. Figure 1 229 below depicts the OAM layering, and shows which devices have 230 visibility into what OAM layer(s). 232 +---+ +---+ 233 +--+ | | +---+ +---+ +---+ | | +--+ 234 |CE|----|PE1|----| P |----| P |----| P |----|PE2|----|CE| 235 +--+ | | +---+ +---+ +---+ | | +--+ 236 +---+ +---+ 238 o--------o---------- Service OAM ------------o--------o 240 o----------- Network OAM -----------o 242 o--------o--------o--------o--------o Transport OAM 244 o----o o----o o----o o----o o----o o----o Link OAM 246 Figure 1: OAM Layering 248 Service OAM and Network OAM mechanisms only have visibility to the PE 249 (Provider Edge) nodes but not the P nodes (Provider network interior 250 nodes). As such, they can be used to deduce whether the fault is in 251 the customer's own network, the local CE-PE segment, the PE-PE 252 segment or the remote CE-PE segment(s). EVPN Transport OAM mechanisms 253 can be used for fault isolation between the PEs and P nodes. 255 Figure 2 below shows an example network where native Ethernet domains 256 are interconnected via EVPN using MPLS and gives the OAM mechanisms 257 applicable at each layer. The details of the layers are described in 258 the sections below. 260 +---+ +---+ 261 +--+ | | +---+ +---+ +---+ | | +--+ 262 |CE|----|PE1|----| P |----| P |----| P |----|PE2|----|CE| 263 +--+ | | +---+ +---+ +---+ | | +--+ 264 +---+ +---+ 266 o--------o---------- Service CFM ------------o--------o 268 o-------- EVPN Network OAM ---------o 270 o--------o--------o--------o--------o MPLS OAM 272 o----o o----o o----o o----o o----o o----o 802.3 OAM 274 Figure 2: EVPN OAM Example 276 2.2 EVPN Service OAM 278 The EVPN Service OAM protocol depends on what service layer 279 technology is being interconnected by the EVPN solution. In case of 280 [RFC7432] and [RFC7623], the service layer is Ethernet; hence, the 281 corresponding service OAM protocol is Ethernet Connectivity Fault 282 Management (CFM) [802.1Q]. 284 EVPN service OAM is visible to the CEs and EVPN PEs, but not to the 285 core (P) nodes. This is because the PEs operate at the Ethernet MAC 286 layer in [RFC7432] [RFC7623] whereas the P nodes do not. 288 The EVPN PE MUST support MIP functions in the applicable service OAM 289 protocol, for example Ethernet CFM. The EVPN PE SHOULD support MEP 290 functions in the applicable service OAM protocol. This includes both 291 Up and Down MEP functions. 293 As shown in Figure 3, the MIP and MEP functions being referred to are 294 logically located within the device's port operating at the customer 295 level. (There could be MEPs/MIPs within PE ports facing the provider 296 network but they would not be relevant to EVPN Service OAM as the 297 traffic passing through them will be encapsulated/tunneled so any 298 customer level OAM messages will just be treated as data.) Down MEP 299 functions are away from the device while up MEP functions are towards 300 the device (towards the PE forwarding mechanism in the case of a PE). 301 OAM messages between the PE Up MEPs shown are a type of EVPN Network 302 OAM while such messages between the CEs or from a PE to its local CE 303 or to the remote CE are Service OAM. 305 +-------+ +----------------+ +----------------+ +-------+ 306 |+-----+| |+--------------+| |+--------------+| |+-----+| 307 || CE || || PE1 || ... || PE2 || || CE || 308 |+--+--+| |+---+--------+-+| |+-+--------+---+| |+--+--+| 309 | | | | | | | | | | | | | | 310 |+--+--+| |+---+-----+ . | | . +-----+---+| |+--+--+| 311 || MEP || || | Up^ | . | ... | . |Up^ | || || MEP || 312 ||DownV|| ||MIP|MEP | . | | . |MEP |MIP|| ||downV|| 313 |+--+--+| || |DownV| . | | . |DownV| || |+--+--+| 314 | | | |+---+-----+ | | | | +-----+---+| | | | 315 +---|---+ +----|--------|--+ +--|--------|----+ +---|---+ 316 | | | | | | 317 +------------+ +--- ... ---+ +------------+ 319 Figure 3: CFM Details 321 The EVPN PE MUST learn the MAC address of locally attached CE MEPs by 322 snooping on CFM frames and advertising them to remote PEs as a MAC/IP 323 Advertisement route. 325 The EVPN PE SHOULD advertise any MEP/MIP local to the PE as a MAC/IP 326 Advertisement route. Since these are not subject to mobility, they 327 SHOULD be advertised with the static (sticky) bit set (see Section 328 15.2 of [RFC7432]). 330 2.3 EVPN Network OAM 332 EVPN Network OAM is visible to the PE nodes only. This OAM layer is 333 analogous to VCCV [RFC5085] in the case of VPLS/VPWS. It provides 334 mechanisms to check the correct operation of the data plane, as well 335 as a mechanism to verify the data plane against the control plane. 336 This includes the ability to perform fault detection and diagnostics 337 on: 339 - the MP2P tunnels used for the transport of unicast traffic between 340 PEs. EVPN allows for three different models of unicast label 341 assignment: label per EVI, label per and label 342 per MAC address. In all three models, the label is bound to an EVPN 343 Unicast FEC. EVPN Network OAM MUST provide mechanisms to check the 344 operation of the data plane and verify that operation against the 345 control plane view. 347 - the MP2P tunnels used for aliasing unicast traffic destined to a 348 multi-homed Ethernet Segment. The three label assignment models, 349 discussed above, apply here as well. In all three models, the label 350 is bound to an EVPN Aliasing FEC. EVPN Network OAM MUST provide 351 mechanisms to check the operation of the data plane and verify that 352 operation against the control plane view. 354 - the multicast tunnels (either MP2P or P2MP) used for the transport 355 of broadcast, unknown unicast and multicast traffic between PEs. In 356 the case of ingress replication, a label is allocated per EVI or 357 per and is bound to an EVPN Multicast FEC. In 358 the case of LSM (Label Switched Multicast), and more specifically 359 aggregate inclusive trees, again a label may be allocated per EVI 360 or per and is bound to the tunnel FEC. 362 - the correct operation of the ESI split-horizon filtering function. 363 In EVPN, a label is allocated per multi-homed Ethernet Segment for 364 the purpose of performing the access split-horizon enforcement. The 365 label is bound to an EVPN Ethernet Segment. 367 - the correct operation of the DF (Designated Forwarder) filtering 368 function. EVPN Network OAM MUST provide mechanisms to check the 369 operation of the data plane and verify that operation against the 370 control plane view for the DF filtering function. 372 EVPN Network OAM mechanisms MUST provide in-band monitoring 373 capabilities. As such, OAM messages MUST be encoded so that they 374 exhibit identical entropy characteristics to data traffic in order 375 that they share the same fate. 377 EVPN Network OAM SHOULD provide both proactive and on-demand 378 mechanisms of monitoring the data plane operation and data plane 379 conformance to the state of the control plane. 381 2.4 Transport OAM for EVPN 383 The transport OAM protocol depends on the nature of the underlying 384 transport technology in the PSN. MPLS OAM mechanisms [RFC8029] 385 [RFC6425] as well as ICMP [RFC792] are applicable, depending on 386 whether the PSN employs MPLS or IP transport, respectively. 387 Furthermore, BFD mechanisms per [RFC5880], [RFC5881], [RFC5883] and 388 [RFC5884] apply. Also, the BFD mechanisms pertaining to MPLS-TP LSPs 389 per [RFC6428] are applicable. 391 2.5 Link OAM 393 Link OAM depends on the data link technology being used between the 394 PE and P nodes. For example, if Ethernet links are employed, then 395 Ethernet Link OAM [802.3] Clause 57 may be used. 397 2.6 OAM Inter-working 399 When inter-working two networking domains, such as native Ethernet 400 and EVPN to provide an end-to-end emulated service, there is a need 401 to identify the failure domain and location, even when a PE supports 402 both the Service OAM mechanisms and the EVPN Network OAM mechanisms. 403 In addition, scalability constraints may not allow running proactive 404 monitoring, such as Ethernet Continuity Check Messages (CCMs), at a 405 PE to detect the failure of an EVI across the EVPN domain. Thus, the 406 mapping of alarms generated upon failure detection in one domain 407 (e.g., native Ethernet or EVPN network domain) to the other domain is 408 needed. There are also cases where a PE may not be able to process 409 Service OAM messages received from a remote PE over the PSN even when 410 such messages are defined, as in the Ethernet case, thereby 411 necessitating support for fault notification message mapping between 412 the EVPN Network domain and the Service domain. 414 OAM inter-working is not limited though to scenarios involving 415 disparate network domains. It is possible to perform OAM inter- 416 working across different layers in the same network domain. In 417 general, alarms generated within an OAM layer, as a result of 418 proactive fault detection mechanisms, may be injected into its client 419 layer OAM mechanisms. This allows the client layer OAM to trigger 420 event-driven (i.e., asynchronous) fault notifications. For example, 421 alarms generated by the Link OAM mechanisms may be injected into the 422 Transport OAM layer, and alarms generated by the Transport OAM 423 mechanism may be injected into the Network OAM mechanism, and so on. 425 EVPN OAM MUST support inter-working between the Network OAM and 426 Service OAM mechanisms. EVPN OAM MAY support inter-working among 427 other OAM layers. 429 3. EVPN OAM Requirements 431 This section discusses the EVPN OAM requirements pertaining to Fault 432 Management and Performance Management. 434 3.1 Fault Management Requirements 436 3.1.1 Proactive Fault Management Functions 438 The network operator configures proactive fault management functions 439 to run periodically without a time bound. Certain actions, for 440 example protection switchover or alarm indication signaling, can be 441 associated with specific events, such as entering or clearing fault 442 states. 444 3.1.1.1 Fault Detection (Continuity Check) 446 Proactive fault detection is performed by periodically monitoring the 447 reachability between service endpoints, i.e., MEPs in a given MA, 448 through the exchange of Continuity Check messages. The reachability 449 between any two arbitrary MEPs may be monitored for: 451 - in-band per-flow monitoring. This enables per flow monitoring 452 between MEPs. EVPN Network OAM MUST support fault detection with 453 per user flow granularity. EVPN Service OAM MAY support fault 454 detection with per user flow granularity. 456 - a representative path. This enables liveness check of the nodes 457 hosting the MEPs assuming that the loss of continuity to the MEP is 458 interpreted as a failure of the hosting node. This, however, does 459 not conclusively indicate liveness of the path(s) taken by user 460 data traffic. This enables node failure detection but not path 461 failure detection, through the use of a test flow. EVPN Network OAM 462 and Service OAM MUST support fault detection using test flows. 464 - all paths. For MPLS/IP networks with ECMP, monitoring of all 465 unicast paths between MEPs (on non-adjacent nodes) may not be 466 possible, since the per-hop ECMP hashing behavior may yield 467 situations where it is impossible for a MEP to pick flow entropy 468 characteristics that result in exercising the exhaustive set of 469 ECMP paths. Monitoring of all ECMP paths between MEPs (on non- 470 adjacent nodes) is not a requirement for EVPN OAM. 472 The fact that MPLS/IP networks do not enforce congruency between 473 unicast and multicast paths means that the proactive fault detection 474 mechanisms for EVPN networks MUST provide procedures to monitor the 475 unicast paths independently of the multicast paths. This applies to 476 EVPN Service OAM and Network OAM. 478 3.1.1.2 Defect Indication 480 EVPN Service OAM MUST support event-driven defect indication upon the 481 detection of a connectivity defect. Defect indications can be 482 categorized into two types: forward and reverse defect indications. 484 3.1.1.2.1 Forward Defect Indication 486 This is used to signal a failure that is detected by a lower layer 487 OAM mechanism. A server MEP (i.e., an actual or virtual MEP) 488 transmits a Forward Defect Indication in a direction that is away 489 from the direction of the failure (refer to Figure 4 below). 491 Failure 492 | 493 +-----+ +-----+ V +-----+ +-----+ 494 | A |------| B |--XXX--| C |------| D | 495 +-----+ +-----+ +-----+ +-----+ 497 <===========| |============> 498 Forward Forward 499 Defect Defect 500 Indication Indication 502 Figure 4: Forward Defect Indication 504 Forward defect indication may be used for alarm suppression and/or 505 for purpose of inter-working with other layer OAM protocols. Alarm 506 suppression is useful when a transport/network level fault translates 507 to multiple service or flow level faults. In such a scenario, it is 508 enough to alert a network management station (NMS) of the single 509 transport/network level fault in lieu of flooding that NMS with a 510 multitude of Service or Flow granularity alarms. EVPN PEs SHOULD 511 support Forward Defect Indication in the Service OAM mechanisms. 513 3.1.1.2.2 Reverse Defect Indication (RDI) 515 RDI is used to signal that the advertising MEP has detected a loss of 516 continuity (LoC) defect. RDI is transmitted in the direction of the 517 failure (refer to Figure 5). 519 Failure 520 | 521 +-----+ +-----+ V +-----+ +-----+ 522 | A |------| B |--XXX--| C |------| D | 523 +-----+ +-----+ +-----+ +-----+ 525 |===========> <============| 526 Reverse Reverse 527 Defect Defect 528 Indication Indication 530 Figure 5: Reverse Defect Indication 532 RDI allows single-sided management, where the network operator can 533 examine the state of a single MEP and deduce the overall health of a 534 monitored service. EVPN PEs SHOULD support Reverse Defect Indication 535 in the Service OAM mechanisms. This includes both the ability to 536 signal LoC defect to a remote MEP, as well as the ability to 537 recognize RDI from a remote MEP. Note that, in a multipoint MA, RDI 538 is not a useful indicator of unidirectional fault. This is because 539 RDI carries no indication of the affected MEP(s) with which the 540 sender had detected a LoC defect. 542 3.1.2 On-Demand Fault Management Functions 544 On-demand fault management functions are initiated manually by the 545 network operator and continue for a time bound period. These 546 functions enable the operator to run diagnostics to investigate a 547 defect condition. 549 3.1.2.1 Connectivity Verification 551 EVPN Network OAM MUST support on-demand connectivity verification 552 mechanisms for unicast and multicast destinations. The connectivity 553 verification mechanisms SHOULD provide a means for specifying and 554 carrying in the messages: 556 - variable length payload/padding to test MTU related connectivity 557 problems. 559 - test frame formats as defined in Appendix C of [RFC2544] to detect 560 potential packet corruption. 562 EVPN Network OAM MUST support connectivity verification at per flow 563 granularity. This includes both user flows (to test a specific path 564 between PEs) as well as test flows (to test a representative path 565 between PEs). 567 EVPN Service OAM MUST support connectivity verification on test flows 568 and MAY support connectivity verification on user flows. 570 For multicast connectivity verification, EVPN Network OAM MUST 571 support reporting on: 573 - the DF filtering status of specific port(s) or all the ports in a 574 given bridge-domain. 576 - the Split Horizon filtering status of specific port(s) or all the 577 ports in a given bridge-domain. 579 3.1.2.2 Fault Isolation 581 EVPN OAM MUST support an on-demand fault localization function. This 582 involves the capability to narrow down the locality of a fault to a 583 particular port, link or node. The characteristic of forward/reverse 584 path asymmetry, in MPLS/IP, makes fault isolation a direction- 585 sensitive operation. That is, given two PEs A and B, localization of 586 continuity failures between them requires running fault isolation 587 procedures from PE A to PE B as well as from PE B to PE A. 589 EVPN Service OAM mechanisms only have visibility to the PEs but not 590 the MPLS/IP P nodes. As such, they can be used to deduce whether the 591 fault is in the customer's own network, the local CE-PE segment or 592 remote CE-PE segment(s). EVPN Network and Transport OAM mechanisms 593 can be used for fault isolation between the PEs and P nodes. 595 3.2 Performance Management 597 Performance Management functions can be performed both proactively 598 and on-demand. Proactive management involves a recurring function, 599 where the performance management probes are run continuously without 600 a trigger. We cover both proactive and on-demand functions in this 601 section. 603 3.2.1 Packet Loss 605 EVPN Network OAM SHOULD provide mechanisms for measuring packet loss 606 for a given service [RFC7680] [RFC6673]. 608 Given that EVPN provides inherent support for multipoint-to- 609 multipoint connectivity, then packet loss cannot be accurately 610 measured by means of counting user data packets. This is because user 611 packets can be delivered to more PEs or more ports than are necessary 612 (e.g., due to broadcast, un-pruned multicast or unknown unicast 613 flooding). As such, a statistical means of approximating packet loss 614 rate is required. This can be achieved by sending "synthetic" OAM 615 packets that are counted only by those ports (MEPs) that are required 616 to receive them. This provides a statistical approximation of the 617 number of data frames lost, even with multipoint-to-multipoint 618 connectivity. 620 3.2.2 Packet Delay and Jitter 622 EVPN Service OAM SHOULD support measurement of one-way and two-way 623 packet delay and delay variation (jitter) across the EVPN network. 624 Measurement of one-way delay requires clock synchronization between 625 the probe source and target devices. Mechanisms for clock 626 synchronization are outside the scope of this document. Note that 627 Service OAM performance management mechanisms defined in [Y.1731] can 628 be used. See also [RFC7679], [RFC2681], and [RFC3393] 630 EVPN Network OAM MAY support measurement of one-way and two-way 631 packet delay and delay variation (jitter) across the EVPN network. 633 4. Security Considerations 635 EVPN OAM MUST prevent OAM packets from leaking outside of the EVPN 636 network or outside their corresponding Maintenance Domain. This can 637 be done for CFM, for example, by having MEPs implement a filtering 638 function based on the Maintenance Level associated with received OAM 639 packets. 641 EVPN OAM SHOULD provide mechanisms for implementation and optional 642 use to: 644 - Prevent denial of service attacks caused by exploitation of the OAM 645 message channel (for example by forging messages to exceed a 646 maintenance end point's capacity to maintain state). 648 - Authenticate communicating endpoints (for example MEPs and MIPs). 650 5. IANA Considerations 652 This document requires no IANA actions. 654 6. Acknowledgements 656 The authors would like to thank the following for their review of 657 this work and valuable comments: 659 David Black, Martin Duke, Xiao Min, Gregory Mirsky, Dave Schinazi, 660 Melinda Shore, Alexander Vainshtein, and Stig Venaas. 662 Normative References 664 [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 665 792, DOI 10.17487/RFC0792, September 1981, 666 . 668 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 669 Requirement Levels", BCP 14, RFC 2119, DOI 670 10.17487/RFC2119, March 1997, . 673 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 674 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 675 . 677 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 678 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 679 10.17487/RFC5881, June 2010, . 682 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 683 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 684 June 2010, . 686 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 687 "Bidirectional Forwarding Detection (BFD) for MPLS Label 688 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 689 June 2010, .< 691 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., 692 and S. Mansfield, "Guidelines for the Use of the "OAM" 693 Acronym in the IETF", BCP 161, RFC 6291, DOI 694 10.17487/RFC6291, June 2011, . 697 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 698 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures 699 in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 700 6425, DOI 10.17487/RFC6425, November 2011, 701 . 703 [RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed., 704 "Proactive Connectivity Verification, Continuity Check, and 705 Remote Defect Indication for the MPLS Transport Profile", 706 RFC 6428, DOI 10.17487/RFC6428, November 2011, 707 . 709 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 710 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 711 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 712 2015, . 714 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 715 Henderickx, "Provider Backbone Bridging Combined with 716 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 717 September 2015, . 719 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 720 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 721 Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 722 10.17487/RFC8029, March 2017, . 725 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 726 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 727 2017, 729 Informative References 731 [802.1Q] "IEEE Standard for Local and metropolitan area networks - 732 Media Access Control (MAC) Bridges and Virtual Bridge Local 733 Area Networks", 2014. 735 [Y.1731] "ITU-T Recommendation Y.1731 (02/08) - OAM functions and 736 mechanisms for Ethernet based networks", February 2008. 738 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 739 Network Interconnect Devices", RFC 2544, DOI 740 10.17487/RFC2544, March 1999, . 743 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 744 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 745 September 1999, . 747 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 748 Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 749 10.17487/RFC3393, November 2002, . 752 [RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual 753 Circuit Connectivity Verification (VCCV): A Control Channel 754 for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 755 2007, . 757 [RFC6136] Sajassi, A., Ed., and D. Mohan, Ed., "Layer 2 Virtual 758 Private Network (L2VPN) Operations, Administration, and 759 Maintenance (OAM) Requirements and Framework", RFC 6136, 760 DOI 10.17487/RFC6136, March 2011, . 763 [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, DOI 764 10.17487/RFC6673, August 2012, . 767 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 768 Ed., "A One-Way Delay Metric for IP Performance Metrics 769 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 770 2016, . 772 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 773 Ed., "A One-Way Loss Metric for IP Performance Metrics 774 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 775 2016, . 777 Authors' Addresses 779 Samer Salam 780 Cisco 782 Email: ssalam@cisco.com 784 Ali Sajassi 785 Cisco 786 170 West Tasman Drive 787 San Jose, CA 95134, USA 789 Email: sajassi@cisco.com 791 Sam Aldrin 792 Google, Inc. 793 1600 Amphitheatre Parkway 794 Mountain View, CA 94043 USA 796 Email: aldrin.ietf@gmail.com 798 John E. Drake 799 Juniper Networks 800 1194 N. Mathilda Ave. 801 Sunnyvale, CA 94089, USA 803 Email: jdrake@juniper.net 805 Donald E. Eastlake, 3rd 806 Futurewei Technologies 807 2386 Panoramic Circle 808 Apopka, FL 32703 USA 810 Tel: +1-508-333-2270 811 Email: d3e3e3@gmail.com