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