idnits 2.17.1 draft-ietf-bess-evpn-bfd-00.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 30, 2020) is 1457 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 7348 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT V. Govindan 2 Intended status: Proposed Standard M. Mudigonda 3 A. Sajassi 4 Cisco Systems 5 G. Mirsky 6 ZTE 7 D. Eastlake 8 Futurewei Technologies 9 Expires: October 29, 2020 April 30, 2020 11 Fault Management for EVPN networks 12 draft-ietf-bess-evpn-bfd-00 14 Abstract 16 This document specifies proactive, in-band network OAM mechanisms to 17 detect loss of continuity and miss-connection faults that affect 18 unicast and multi-destination paths (used by Broadcast, Unknown 19 Unicast and Multicast traffic) in an Ethernet VPN (EVPN) network. 20 The mechanisms specified in the draft are based on the widely adopted 21 Bidirectional Forwarding Detection (BFD) protocol. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Distribution of this document is unlimited. Comments should be sent 29 to the authors or the BESS working group mailing list: bess@ietf.org. 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 44 http://www.ietf.org/shadow.html. 46 Table of Contents 48 1. Introduction............................................3 49 1.1 Terminology............................................3 51 2. Scope of this Document..................................5 52 3. Motivation for Running BFD at the EVPN Network Layer....6 53 4. Fault Detection for Unicast Traffic.....................7 55 5. Fault Detection for BUM Traffic.........................8 56 5.1 Ingress Replication....................................8 57 5.2 P2MP Tunnels (Label Switched Multicast)................8 59 6. BFD Packet Encapsulation................................9 60 6.1 MPLS Encapsulation.....................................9 61 6.1.1 Unicast..............................................9 62 6.1.2 Ingress Replication.................................10 63 6.1.3 LSM (Label Switched Multicast, P2MP)................11 64 6.2 VXLAN Encapsulation...................................11 65 6.2.1 Unicast.............................................11 66 6.2.2 Ingress Replication.................................13 67 6.2.3 LSM (Label Switched Multicast, P2MP)................13 69 7. BGP Distribution of BFD Discriminators.................14 70 8. Scalability Considerations.............................14 72 9. IANA Considerations....................................15 73 9.1 Pseudowire Associated Channel Type....................15 74 9.2 MAC Address...........................................15 76 10. Security Considerations...............................15 78 Acknowledgement...........................................15 80 Normative References......................................16 81 Informative References....................................18 83 Authors' Addresses........................................19 85 Internet-Draft Fault Management for EVPN 87 1. Introduction 89 [ietf-bess-evpn-oam-req-frmwk] outlines the OAM requirements of 90 Ethernet VPN networks (EVPN [RFC7432]). This document specifies 91 mechanisms for proactive fault detection at the network (overlay) 92 layer of EVPN. The mechanisms proposed in the draft use the widely 93 adopted Bidirectional Forwarding Detection (BFD [RFC5880]) protocol. 95 EVPN fault detection mechanisms need to consider unicast traffic 96 separately from Broadcast, Unknown Unicast, and Multicast (BUM) 97 traffic since they map to different Forwarding Equivalency Classes 98 (FECs) in EVPN. Hence this document proposes different fault 99 detection mechanisms to suit each type, for unicast traffic using BFD 100 [RFC5880] and for BUM traffic using BFD or [RFC8563] depending on 101 whether an MP2P or P2MP tunnel is being used. 103 Packet loss and packet delay measurement are out of scope for this 104 document. 106 1.1 Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 The following acronyms are used in this document. 116 BFD - Bidirectional Forwarding Detection [RFC5880] 118 BUM - Broadcast, Unknown Unicast, and Multicast 120 CC - Continuity Check 122 CV - Connectivity Verification 124 EVI - EVPN Instance 126 EVPN - Ethernet VPN [RFC7432] 128 FEC - Forwarding Equivalency Class 130 GAL - Generic Associated Channel Label [RFC5586] 132 LSM - Label Switched Multicast (P2MP) 134 LSP - Label Switched Path 136 Internet-Draft Fault Management for EVPN 138 MP2P - Multi-Point to Point 140 OAM - Operations Administration, and Maintenance 142 P2MP - Point to Multi-Point (LSM) 144 PE - Provider Edge 146 VXLAN - Virtual eXtesible Local Area Network (VXLAN) [RFC7348] 148 Internet-Draft Fault Management for EVPN 150 2. Scope of this Document 152 This document specifies BFD based mechanisms for proactive fault 153 detection for EVPN both as specified in [RFC7432] and also for EVPN 154 using VXLAN encapsulation [ietf-vxlan-bfd]. It covers the following: 156 o Unicast traffic. 158 o BUM traffic using Multi-point-to-Point (MP2P) tunnels (ingress 159 replication). 161 o BUM traffic using Point-to-Multipoint (P2MP) tunnels (Label 162 Switched Multicast (LSM)). 164 o MPLS and VXLAN encapsulation. 166 This document does not discuss BFD mechanisms for: 168 o EVPN variants like PBB-EVPN [RFC7623]. It is intended to 169 address this in future versions. 171 o Integrated Routing and Bridging (IRB) solution based on EVPN 172 [ietf-bess-evpn-inter-subnet-forwarding]. It is intended to 173 address this in future versions. 175 o EVPN using other encapsulations such as NVGRE or MPLS over GRE 176 [RFC8365]. 178 o BUM traffic using MP2MP tunnels. 180 This specification specifies procedures for BFD asynchronous mode. 181 BFD demand mode is outside the scope of this specification except as 182 it is used in [RFC8563]. The use of the Echo function is outside the 183 scope of this specification. 185 Internet-Draft Fault Management for EVPN 187 3. Motivation for Running BFD at the EVPN Network Layer 189 The choice of running BFD at the network layer of the OAM model for 190 EVPN [ietf-bess-evpn-oam-req-frmwk] was made after considering the 191 following: 193 o In addition to detecting link failures in the EVPN network, BFD 194 sessions at the network layer can be used to monitor the 195 successful setup of MP2P and P2MP EVPN tunnels transporting 196 Unicast and BUM traffic such as label programming. The scope of 197 reachability detection covers the ingress and the egress EVPN PE 198 nodes and the network connecting them. 200 o Monitoring a representative set of path(s) or a particular path 201 among the multiple paths available between two EVPN PE nodes could 202 be done by exercising entropy mechanisms such as entropy labels, 203 when they are used, or VXLAN source ports. However, paths that 204 cannot be realized by entropy variations cannot be monitored. 205 Fault monitoring requirements outlined by 206 [ietf-bess-evpn-oam-req-frmwk] are addressed by the mechanisms 207 proposed by this draft. 209 BFD testing between EVPN PE nodes does not guarantee that the EVPN 210 service is functioning. (This can be monitored at the service level, 211 that is CE to CE.) For example, an egress EVPN-PE could understand 212 EVPN labeling received but could switch data to an incorrect 213 interface. However, BFD testing in the EVPN Network Layer does 214 provide additional confidence that data transported using those 215 tunnels will reach the expected egress node. When BFD testing in the 216 EVPN overlay fails, that can be used as an indication of a Loss-of- 217 Connectivity defect in the EVPN underlay that would cause EVPN 218 service failure. 220 Internet-Draft Fault Management for EVPN 222 4. Fault Detection for Unicast Traffic 224 The mechanisms specified in BFD for MPLS LSPs [RFC5884] [RFC7726] are 225 applied to test the handling of unicast EVPN traffic. The 226 discriminators required for de-multiplexing the BFD sessions are 227 advertised through BGP as specified in Section 7. This is needed for 228 MPLS since the label stack does not contain enough information to 229 disambiguate the sender of the packet. 231 The usage of MPLS entropy labels or various VXLAN source ports takes 232 care of the requirement to monitor various paths of the multi-path 233 server layer network [RFC6790]. Each unique realizable path between 234 the participating PE routers MAY be monitored separately when such 235 entropy is used. At least one path of multi-path connectivity 236 between two PE routers MUST be tracked with BFD, but in that case the 237 granularity of fault-detection will be coarser. To support unicast 238 OAM, each PE node MUST allocate a BFD discriminator to be used for 239 BFD messages to that PE and MUST advertise this discriminator with 240 BGP as specified in Section 7. Once the BFD session for the EVPN 241 label is UP, the ends of the BFD session MUST NOT change the local 242 discriminator values of the BFD Control packets they generate, unless 243 they first bring down the session as specified in [RFC5884]. 245 Internet-Draft Fault Management for EVPN 247 5. Fault Detection for BUM Traffic 249 Section 5.1 below discusses fault detection for MP2P tunnels using 250 ingress replication and Section 5.2 discusses fault detection for 251 P2MP tunnels. 253 5.1 Ingress Replication 255 Ingress replication uses separate MP2P tunnels for transporting BUM 256 traffic from the ingress PE (head) to a set of one or more egress PEs 257 (tails). The fault detection mechanism specified by this document 258 takes advantage of the fact that the head makes a unique copy for 259 each tail. 261 Another key aspect to be considered in EVPN is the advertisement of 262 the inclusive multicast route. The BUM traffic flows from a head 263 node to a particular tail only after the head receives the inclusive 264 multicast route. This contains the BUM EVPN label (downstream 265 allocated) corresponding to the MP2P tunnel for MPLS encapsulation 266 and contains the IP address of the PE originating the inclusive 267 multicast route for use in VXLAN encapsulation. 269 There MAY exist multiple BFD sessions between a head PE and an 270 individual tail due to (1) the usage of MPLS entropy labels [RFC6790] 271 or VXLAN source ports for an inclusive multicast FEC and (2) due to 272 multiple MP2P tunnels indicated by different tail labels or IP 273 addresses for MPLS or VXLAN. The BFD discriminator to be used is 274 distributed by BGP as specified in Section 7. Once the BFD session 275 for the EVPN label is UP, the BFD systems terminating the BFD session 276 MUST NOT change the local discriminator values of the BFD Control 277 packets they generate, unless they first bring down the session as 278 specified in [RFC5884]. 280 5.2 P2MP Tunnels (Label Switched Multicast) 282 Fault detection for BUM traffic distributed using a P2MP tunnel uses 283 active tail multipoint BFD [RFC8563] in one of the three scenarios 284 providing head notification (see Section 5.2 of [RFC8563]). 286 For MPLS encapsulation of the head to tails BFD, Label Switched 287 Multicast is used. For VXLAN encapsulation, BFD is delivered to the 288 tails through underlay multicast using an outer multicast IP address. 290 Internet-Draft Fault Management for EVPN 292 6. BFD Packet Encapsulation 294 The sections below describe the MPLS and VXLAN encapsulations of BFD 295 for EVPN OAM use. 297 6.1 MPLS Encapsulation 299 This section describes use of the Generic Associated Channel Label 300 (GAL) for BFD encapsulation in MPLS based EVPN OAM. 302 6.1.1 Unicast 304 The packet initially contains the following labels: LSP label 305 (transport), the optional entropy label, and the EVPN Unicast label. 306 The G-ACh type is set to TBD1. The G-ACh payload of the packet MUST 307 contain the destination L2 header (in overlay space) followed by the 308 IP header that encapsulates the BFD packet. The MAC address of the 309 inner packet is used to validate the in the receiving 310 node. 312 - The destination MAC MUST be the dedicated MAC TBD-A (see Section 313 9) or the MAC address of the destination PE. 314 - The destination IP address MUST be in the 127.0.0.0/8 range for 315 IPv4 or in the 0:0:0:0:0:FFFF:7F00:0/104 range for IPv6. 316 - The destination IP port MUST be 3784 [RFC5881]. 317 - The source IP port MUST be in the range 49152 through 65535. 318 - The discriminator values for BFD are obtained through BGP as 319 specified in Section 7 or are exchanged out-of-band or through 320 some other means outside the scope of this document. 322 Internet-Draft Fault Management for EVPN 324 <---------- 4 bytes ----------> 325 +-------------------------------+ ----- 326 | LSP Label | | 327 +-------------------------------+ | 328 : entropy label indicator : | 329 + (optional) + MPLS Label Stack 330 : entropy label : | 331 +-------------------------------+ | 332 | EVPN Unicast label | 333 +-------------------------------+ | 334 | Generic Assoc. Channel Label | | 335 +-------------------------------+ ----- 336 | ACH word, Type TBD1 no TLVs | 337 +-------------------------------+ --- ------- 338 | Destination MAC Address | | | 339 + +---------------+ | | 340 | TBD-A | | | | 341 +---------------+ + L2 Header | 342 | Source MAC Address | | | 343 +---------------+---------------+ | | 344 | VLAN Ethertype| VLAN-ID | | | 345 +---------------+---------------+ | | 346 |IP4/6 Ethertype| | | 347 +---------------+---------------+ --- | 348 / / G-ACh Payload 349 /... IP4/6 Header .../ | 350 / / | 351 +-------------------------------+ | 352 | | | 353 + UDP Header + | 354 | | | 355 +-------------------------------+ | 356 | | | 357 + BFD Control Packet + | 358 / / | 359 /... .../ --------------- 361 6.1.2 Ingress Replication 363 The packet initially contains the following labels: LSP label 364 (transport), the optional entropy label, the BUM label, and the split 365 horizon label [RFC7432] (where applicable). The G-ACh type is set to 366 TBD1. The G-ACh payload of the packet is as described in Section 367 6.1.1. 369 Internet-Draft Fault Management for EVPN 371 6.1.3 LSM (Label Switched Multicast, P2MP) 373 The encapsulation is the same as in Section 6.1.2 for ingress 374 replication except that the transport label identifies the P2MP 375 tunnel, in effect the set of tail PEs, rather than identifying a 376 single destination PE at the end of an MP2P tunnel. 378 6.2 VXLAN Encapsulation 380 This section describes the use of the VXLAN [RFC7348] for BFD 381 encapsulation in VXLAN based EVPN OAM. This specification conforms to 382 [ietf-bfd-vxlan]. 384 6.2.1 Unicast 386 The outer and inner IP headers have a unicast source IP address of 387 the BFD message source and a destination IP address of the BFD 388 message destination 390 The destination UDP port MUST be 3784 [RFC5881]. The source port MUST 391 be in the range 49152 through 65535. If the BFD source has multiple 392 IP addresses, entropy MAY be further obtained by using any of those 393 addresses assuming the source is prepared for responses directed to 394 the IP address used. 396 The Your BFD discriminator is the value distributed for this unicast 397 OAM purpose by the destination using BGP as specified in Section 7 or 398 is exchanged out-of-band or through some other means outside the 399 scope of this document. 401 Internet-Draft Fault Management for EVPN 403 <---------- 4 bytes ----------> 404 +-------------------------------+ --- 405 | Destination MAC Address | | 406 + +---------------+ | 407 | | | | 408 +---------------+ + L2 Header 409 | Source MAC Address | | 410 +-------------------------------+ | 411 | VLAN Tag | | 412 +---------------+---------------+ | 413 |IP4/6 Ethertype| | 414 +---------------+---------------+ --- 415 / / 416 /... IP4/6 Header .../ 417 / / 418 +-------------------------------+ 419 | | 420 + UDP Header + 421 | | 422 +-------------------------------+ 423 | | 424 + VXLAN Header + 425 | | 426 +-------------------------------+ --- 427 | Destination MAC Address | | 428 + +---------------+ | 429 | | | | 430 +---------------+ + L2 Header 431 | Source MAC Address | | 432 +---------------+---------------+ | 433 | IP4 Ethertype | | 434 +---------------+---------------+ --- 435 / / 436 /... IP4 Header .../ 437 / / 438 +-------------------------------+ 439 | | 440 + UDP Header + 441 | | 442 +---------------+---------------+ 443 | | 444 + BFD Control Packet + 445 | | 446 /... .../ 448 Internet-Draft Fault Management for EVPN 450 6.2.2 Ingress Replication 452 The BFD packet construction is as given in Section 6.2.1 except as 453 follows: 454 (1) The destination IP address used by the BFD message source is that 455 advertised by the destination PE in its Inclusive Multicast EVPN 456 route for the MP2P tunnel in question; and 457 (2) The Your BFD discriminator used is the one advertised by the BFD 458 destination using BGP as specified in Section 7 for the MP2P 459 tunnel in question or is exchanged out-of-band or through some 460 other means outside the scope of this document. 462 6.2.3 LSM (Label Switched Multicast, P2MP) 464 The VXLAN encapsulation for the head-to-tails BFD packets uses the 465 multicast destination IP corresponding to the VXLAN VNI. 467 The destination port MUST be 3784. For entropy purposes, the source 468 port can vary but MUST be in the range 49152 through 65535 [RFC5881]. 469 If the head PE has multiple IP addresses, entropy MAY be further 470 obtained by using any of those addresses. 472 The Your BFD discriminator is the value distributed for this unicast 473 OAM purpose by the BFD message using BGP as specified in Section 7 or 474 is exchanged out-of-band or through some other means outside the 475 scope of this document. 477 Internet-Draft Fault Management for EVPN 479 7. BGP Distribution of BFD Discriminators 481 BGP is used to distribute BFD discriminators for use in EVPN OAM as 482 follows using the BGP-BFD Attribute as specified in 483 [ietf-bess-mvpn-fast-failover]. This attribute is included with 484 appropriate EVPN routes as follows: 486 Unicast: MAC/IP Advertisement Route [RFC7432]. 488 MP2P Tunnel: Inclusive Multicast Ethernet Tag Route [RFC7432]. 490 P2MP: TBD 492 [Need more text on BFD sessions reacting to the new advertisement 493 and withdrawal of the BGP-BFD Attribute.] 495 8. Scalability Considerations 497 The mechanisms proposed by this draft could affect the packet load on 498 the network and its elements especially when supporting 499 configurations involving a large number of EVIs. The option of 500 slowing down or speeding up BFD timer values can be used by an 501 administrator or a network management entity to maintain the overhead 502 incurred due to fault monitoring at an acceptable level. 504 Internet-Draft Fault Management for EVPN 506 9. IANA Considerations 508 The following IANA Actions are requested. 510 9.1 Pseudowire Associated Channel Type 512 IANA is requested to assign a channel type from the "Pseudowire 513 Associated Channel Types" registry in [RFC4385] as follows. 515 Value Description Reference 516 ----- ------------ ------------ 517 TBD1 BFD-EVPN OAM [this document] 519 9.2 MAC Address 521 IANA is requested to assign a multicast MAC address under the IANA 522 OUI [0x01005E900004 suggested] as follows: 524 Address Usage Reference 525 ------- -------- --------------- 526 TBD-A EVPN OAM [this document] 528 10. Security Considerations 530 Security considerations discussed in [RFC5880], [RFC5883], and 531 [RFC8029] apply. 533 MPLS security considerations [RFC5920] apply to BFD Control packets 534 encapsulated in a MPLS label stack. When BPD Control packets are 535 routed, the authentication considerations discussed in [RFC5883] 536 should be followed. 538 VXLAN BFD security considerations in [ietf-vxlan-bfd] apply to BFD 539 packets encapsulate in VXLAN. 541 Acknowledgement 543 The authors wish to thank the following for their comments and 544 suggestions: 546 Mach Chen 548 Internet-Draft Fault Management for EVPN 550 Normative References 552 [ietf-bess-evpn-inter-subnet-forwarding] Sajassi, A., Salam, S., 553 Thoria, S., Rekhter, Y., Drake, J., Yong, L., and L. 554 Dunbar, "Integrated Routing and Bridging in EVPN", 555 draft-ietf-bess-evpn-inter-subnet-forwarding-08, work in 556 progress, March 2019. 558 [ietf-bess-mvpn-fast-failover] Morin, T., Kebler, R., Mirsky, G., 559 "Multicast VPN fast upstream failover", 560 draft-ietf-bess-mvpn-fast-failover-05 (work in progress), 561 February 2019. 563 [ietf-bfd-vxlan] Pallagatti, S., Paragiri, S., Govindan, V., 564 Mudigonda, M., G. Mirsky, "BFD for VXLAN", 565 draft-ietf-bfd-vxlan-07 (work in progress), May 2019. 567 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 568 Requirement Levels", BCP 14, RFC 2119, DOI 569 10.17487/RFC2119, March 1997, . 572 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 573 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 574 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 575 February 2006, . 577 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 578 "MPLS Generic Associated Channel", RFC 5586, DOI 579 10.17487/RFC5586, June 2009, . 582 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 583 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 584 . 586 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 587 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 588 10.17487/RFC5881, June 2010, . 591 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 592 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 593 June 2010, . 595 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 596 "Bidirectional Forwarding Detection (BFD) for MPLS Label 597 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 598 June 2010, . 600 Internet-Draft Fault Management for EVPN 602 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. 603 Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 604 6790, DOI 10.17487/RFC6790, November 2012, . 607 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 608 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 609 eXtensible Local Area Network (VXLAN): A Framework for 610 Overlaying Virtualized Layer 2 Networks over Layer 3 611 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 612 . 614 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 615 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 616 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 617 2015, . 619 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 620 Henderickx, "Provider Backbone Bridging Combined with 621 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 622 September 2015, . 624 [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. 625 Aldrin, "Clarifying Procedures for Establishing BFD 626 Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, 627 DOI 10.17487/RFC7726, January 2016, . 630 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 631 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 632 Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 633 10.17487/RFC8029, March 2017, . 636 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 637 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 638 2017, . 640 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 641 Uttaro, J., and W. Henderickx, "A Network Virtualization 642 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 643 10.17487/RFC8365, March 2018, . 646 [RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 647 Ed., "Bidirectional Forwarding Detection (BFD) Multipoint 648 Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019, 649 . 651 Internet-Draft Fault Management for EVPN 653 Informative References 655 [ietf-bess-evpn-oam-req-frmwk] Salam, S., Sajassi, A., Aldrin, S., J. 656 Drake, and D. Eastlake, "EVPN Operations, Administration 657 and Maintenance Requirements and Framework", 658 draft-ietf-bess-evpn-oam-req-frmwk-00, work in progress, 659 February 2019. 661 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 662 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 663 . 665 Internet-Draft Fault Management for EVPN 667 Authors' Addresses 669 Vengada Prasad Govindan 670 Cisco Systems 672 Email: venggovi@cisco.com 674 Mudigonda Mallik 675 Cisco Systems 677 Email: mmudigon@cisco.com 679 Ali Sajassi 680 Cisco Systems 681 170 West Tasman Drive 682 San Jose, CA 95134, USA 684 Email: sajassi@cisco.com 686 Gregory Mirsky 687 ZTE Corp. 689 Email: gregimirsky@gmail.com 691 Donald Eastlake, 3rd 692 Futurewei Technologies 693 2386 Panoramic Circle 694 Apopka, FL 32703 USA 696 Phone: +1-508-333-2270 697 Email: d3e3e3@gmail.com 699 Internet-Draft Fault Management for EVPN 701 Copyright, Disclaimer, and Additional IPR Provisions 703 Copyright (c) 2020 IETF Trust and the persons identified as the 704 document authors. All rights reserved. 706 This document is subject to BCP 78 and the IETF Trust's Legal 707 Provisions Relating to IETF Documents 708 (http://trustee.ietf.org/license-info) in effect on the date of 709 publication of this document. Please review these documents 710 carefully, as they describe your rights and restrictions with respect 711 to this document. Code Components extracted from this document must 712 include Simplified BSD License text as described in Section 4.e of 713 the Trust Legal Provisions and are provided without warranty as 714 described in the Simplified BSD License.