idnits 2.17.1 draft-ietf-bess-evpn-bfd-01.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2020) is 1279 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 (~~), 2 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: April 25, 2021 October 26, 2020 11 Fault Management for EVPN networks 12 draft-ietf-bess-evpn-bfd-01 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 Internet-Draft Fault Management for EVPN 48 Table of Contents 50 1. Introduction............................................3 51 1.1 Terminology............................................3 53 2. Scope of this Document..................................5 54 3. Motivation for Running BFD at the EVPN Network Layer....6 55 4. Fault Detection for Unicast Traffic.....................7 57 5. Fault Detection for BUM Traffic.........................8 58 5.1 Ingress Replication....................................8 59 5.2 P2MP Tunnels (Label Switched Multicast)................8 61 6. BFD Packet Encapsulation................................9 62 6.1 MPLS Encapsulation.....................................9 63 6.1.1 MPLS Unicast.........................................9 64 6.1.2 MPLS Ingress Replication............................10 65 6.1.3 MPLS LSM (Label Switched Multicast, P2MP)...........11 66 6.2 VXLAN Encapsulation...................................11 67 6.2.1 VXLAN Unicast.......................................11 68 6.2.2 VXLAN Ingress Replication...........................13 69 6.2.3 VXLAN LSM (Label Switched Multicast, P2MP)..........13 71 7. BGP Distribution of BFD Discriminators.................14 72 8. Scalability Considerations.............................15 74 9. IANA Considerations....................................16 75 9.1 Pseudowire Associated Channel Type....................16 76 9.2 MAC Address...........................................16 78 10. Security Considerations...............................17 80 Acknowledgements..........................................17 82 Normative References......................................18 83 Informative References....................................20 85 Authors' Addresses........................................21 87 Internet-Draft Fault Management for EVPN 89 1. Introduction 91 [ietf-bess-evpn-oam-req-frmwk] outlines the OAM requirements of 92 Ethernet VPN networks (EVPN [RFC7432]). This document specifies 93 mechanisms for proactive fault detection at the network (overlay) 94 layer of EVPN. The mechanisms proposed in the draft use the widely 95 adopted Bidirectional Forwarding Detection (BFD [RFC5880]) protocol. 97 EVPN fault detection mechanisms need to consider unicast traffic 98 separately from Broadcast, Unknown Unicast, and Multicast (BUM) 99 traffic since they map to different Forwarding Equivalency Classes 100 (FECs) in EVPN. Hence this document proposes different fault 101 detection mechanisms to suit each type. For unicast traffic and BUM 102 traffic via MP2P tunnels, using BFD [RFC5880], and for BUM traffic 103 via a P2MP tunnel, using BFD Multipoint Active Tails [RFC8563] 104 [mirsky-mpls-p2mp-bfd]. 106 Packet loss and packet delay measurement are out of scope for this 107 document. 109 1.1 Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in BCP 114 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 The following acronyms are used in this document. 119 BFD - Bidirectional Forwarding Detection [RFC5880] 121 BUM - Broadcast, Unknown Unicast, and Multicast 123 CC - Continuity Check 125 CV - Connectivity Verification 127 EVI - EVPN Instance 129 EVPN - Ethernet VPN [RFC7432] 131 FEC - Forwarding Equivalency Class 133 GAL - Generic Associated Channel Label [RFC5586] 135 LSM - Label Switched Multicast (P2MP) 137 Internet-Draft Fault Management for EVPN 139 LSP - Label Switched Path 141 MP2P - Multi-Point to Point 143 OAM - Operations, Administration, and Maintenance 145 P2MP - Point to Multi-Point (LSM) 147 PE - Provider Edge 149 VXLAN - Virtual eXtesible Local Area Network (VXLAN) [RFC7348] 151 Internet-Draft Fault Management for EVPN 153 2. Scope of this Document 155 This document specifies BFD based mechanisms for proactive fault 156 detection for EVPN both as specified in [RFC7432] and also for EVPN 157 using VXLAN encapsulation [ietf-vxlan-bfd]. It covers the following: 159 o Unicast traffic. 161 o BUM traffic using Multi-point-to-Point (MP2P) tunnels (ingress 162 replication). 164 o BUM traffic using Point-to-Multipoint (P2MP) tunnels (Label 165 Switched Multicast (LSM)). 167 o MPLS and VXLAN encapsulation. 169 This document does not discuss BFD mechanisms for: 171 o EVPN variants like PBB-EVPN [RFC7623]. It is intended to 172 address this in future versions. 174 o Integrated Routing and Bridging (IRB) solution based on EVPN 175 [ietf-bess-evpn-inter-subnet-forwarding]. It is intended to 176 address this in future versions. 178 o EVPN using other encapsulations such as NVGRE or MPLS over GRE 179 [RFC8365]. 181 o BUM traffic using MP2MP tunnels. 183 This document specifies procedures for BFD asynchronous mode. BFD 184 demand mode is outside the scope of this specification except as it 185 is used in [RFC8563]. The use of the Echo function is outside the 186 scope of this specification. 188 Internet-Draft Fault Management for EVPN 190 3. Motivation for Running BFD at the EVPN Network Layer 192 The choice of running BFD at the network layer of the OAM model for 193 EVPN [ietf-bess-evpn-oam-req-frmwk] was made after considering the 194 following: 196 o In addition to detecting link failures in the EVPN network, BFD 197 sessions at the network layer can be used to monitor the 198 successful setup of MP2P and P2MP EVPN tunnels transporting 199 Unicast and BUM traffic such as label programming. The scope of 200 reachability detection covers the ingress and the egress EVPN PE 201 nodes and the network connecting them. 203 o Monitoring a representative set of path(s) or a particular path 204 among multiple paths available between two EVPN PE nodes could be 205 done by exercising entropy mechanisms such as entropy labels, when 206 they are used, or VXLAN source ports. However, paths that cannot 207 be realized by entropy variations cannot be monitored. The fault 208 monitoring requirements outlined by [ietf-bess-evpn-oam-req-frmwk] 209 are addressed by the mechanisms proposed by this draft. 211 BFD testing between EVPN PE nodes does not guarantee that the EVPN 212 service is functioning. (This can be monitored at the service level, 213 that is CE to CE.) For example, an egress EVPN-PE could understand 214 EVPN labeling received but could switch data to an incorrect 215 interface. However, BFD testing in the EVPN Network Layer does 216 provide additional confidence that data transported using those 217 tunnels will reach the expected egress node. When BFD testing in the 218 EVPN overlay fails, that can be used as an indication of a Loss-of- 219 Connectivity defect in the EVPN underlay that would cause EVPN 220 service failure. 222 Internet-Draft Fault Management for EVPN 224 4. Fault Detection for Unicast Traffic 226 The mechanisms specified in BFD for MPLS LSPs [RFC5884] [RFC7726] are 227 applied to test the handling of unicast EVPN traffic. The 228 discriminators required for de-multiplexing the BFD sessions are 229 advertised through BGP as specified in Section 7. This is needed for 230 MPLS since the label stack does not contain enough information to 231 disambiguate the sender of the packet. 233 The usage of MPLS entropy labels or various VXLAN source ports takes 234 care of the requirement to monitor various paths of the multi-path 235 server layer network [RFC6790]. Each unique realizable path between 236 the participating PE routers MAY be monitored separately when such 237 entropy is used. At least one path of multi-path connectivity 238 between two PE routers MUST be tracked with BFD, but in that case the 239 granularity of fault-detection will be coarser. To support unicast 240 OAM, each PE node MUST allocate a BFD discriminator to be used for 241 BFD messages to that PE and MUST advertise this discriminator with 242 BGP as specified in Section 7. Once the BFD session for the EVPN 243 label is UP, the ends of the BFD session MUST NOT change the local 244 discriminator values of the BFD Control packets they generate, unless 245 they first bring down the session as specified in [RFC5884]. 247 Internet-Draft Fault Management for EVPN 249 5. Fault Detection for BUM Traffic 251 Section 5.1 below discusses fault detection for MP2P tunnels using 252 ingress replication and Section 5.2 discusses fault detection for 253 P2MP tunnels. 255 5.1 Ingress Replication 257 Ingress replication uses separate MP2P tunnels for transporting BUM 258 traffic from the ingress PE (head) to a set of one or more egress PEs 259 (tails). The fault detection mechanism specified by this document 260 takes advantage of the fact that the head makes a unique copy for 261 each tail. 263 Another key aspect to be considered in EVPN is the advertisement of 264 the inclusive multicast route. The BUM traffic flows from a head 265 node to a particular tail only after the head receives the inclusive 266 multicast route. This contains the BUM EVPN label (downstream 267 allocated) corresponding to the MP2P tunnel for MPLS encapsulation 268 and contains the IP address of the PE originating the inclusive 269 multicast route for use in VXLAN encapsulation. 271 There MAY exist multiple BFD sessions between a head PE and an 272 individual tail due to (1) the usage of MPLS entropy labels [RFC6790] 273 or VXLAN source ports for an inclusive multicast FEC and (2) due to 274 multiple MP2P tunnels indicated by different tail labels or IP 275 addresses for MPLS or VXLAN. The BFD discriminator to be used is 276 distributed by BGP as specified in Section 7. Once the BFD session 277 for the EVPN label is UP, the BFD systems terminating the BFD session 278 MUST NOT change the local discriminator values of the BFD Control 279 packets they generate, unless they first bring down the session as 280 specified in [RFC5884]. 282 5.2 P2MP Tunnels (Label Switched Multicast) 284 Fault detection for BUM traffic distributed using a P2MP tunnel uses 285 BFD Multipoint Active Tails in one of the three scenarios providing 286 head notification. Sections 5.2.2 and 5.2.3 of [RFC8563] describe two 287 of these scenarios (Head Notification and Tail Solicitation with 288 Multipoint Polling, Head Notification with Composite Polling). 289 [mirsky-mpls-p2mp-bfd] describes the third (Head Notification without 290 Polling). 292 For MPLS encapsulation of the head to tails BFD, Label Switched 293 Multicast is used. For VXLAN encapsulation, BFD is delivered to the 294 tails through underlay multicast using an outer multicast IP address. 296 Internet-Draft Fault Management for EVPN 298 6. BFD Packet Encapsulation 300 The sections below describe the MPLS and VXLAN encapsulations of BFD 301 for EVPN OAM use. 303 6.1 MPLS Encapsulation 305 This section describes use of the Generic Associated Channel Label 306 (GAL) for BFD encapsulation in MPLS based EVPN OAM. 308 6.1.1 MPLS Unicast 310 As shown in Figure 1, the packet initially contains the following 311 labels: LSP label (transport), the optional entropy label, the EVPN 312 Unicast label, and then the Generic Associated Channel label with the 313 G-ACh type set to TBD1. The G-ACh payload of the packet MUST contain 314 the destination L2 header (in overlay space) followed by the IP 315 header that encapsulates the BFD packet. The MAC address of the 316 inner packet is used to validate the in the receiving 317 node. 319 - The destination MAC MUST be the dedicated MAC TBD-A (see Section 320 9) or the MAC address of the destination PE. 321 - The destination IP address MUST be 127.0.0.1/32 for IPv4 322 [RFC1812] or ::1/128 for IPv6 [RFC4291]. 323 - The destination IP port MUST be 3784 [RFC5881]. 324 - The source IP port MUST be in the range 49152 through 65535. 325 - The discriminator values for BFD are obtained through BGP as 326 specified in Section 7 or are exchanged out-of-band or through 327 some other means outside the scope of this document. 329 Internet-Draft Fault Management for EVPN 331 <---------- 4 bytes ----------> 332 +-------------------------------+ ----- 333 | LSP Label | | 334 +-------------------------------+ | 335 : entropy label indicator : | 336 + (optional) + MPLS Label Stack 337 : entropy label : | 338 +-------------------------------+ | 339 | EVPN Unicast label | 340 +-------------------------------+ | 341 | Generic Assoc. Channel Label | | 342 +-------------------------------+ ----- 343 | ACH word, Type TBD1 no TLVs | 344 +-------------------------------+ --- ------- 345 | Destination MAC Address | | | 346 + +---------------+ | | 347 | TBD-A | | | | 348 +---------------+ + L2 Header | 349 | Source MAC Address | | | 350 +---------------+---------------+ | | 351 | VLAN Ethertype| VLAN-ID | | | 352 +---------------+---------------+ | | 353 |IP4/6 Ethertype| | | 354 +---------------+---------------+ --- | 355 / / G-ACh Payload 356 /... IP4/6 Header .../ | 357 / / | 358 +-------------------------------+ | 359 | | | 360 + UDP Header + | 361 | | | 362 +-------------------------------+ | 363 | | | 364 + BFD Control Packet + | 365 / / | 366 /... .../ --------------- 368 Figure 1. MPLS Unicast Enacapsulation 370 6.1.2 MPLS Ingress Replication 372 The packet initially contains the following labels: LSP label 373 (transport), the optional entropy label, the BUM label, and the split 374 horizon label [RFC7432] (where applicable). The G-ACh type is set to 375 TBD1. The G-ACh payload of the packet is as described in Section 376 6.1.1. 378 Internet-Draft Fault Management for EVPN 380 6.1.3 MPLS LSM (Label Switched Multicast, P2MP) 382 The encapsulation is the same as in Section 6.1.2 for ingress 383 replication except that the transport label identifies the P2MP 384 tunnel, in effect the set of tail PEs, rather than identifying a 385 single destination PE at the end of an MP2P tunnel. 387 6.2 VXLAN Encapsulation 389 This section describes the use of the VXLAN [RFC7348] for BFD 390 encapsulation in VXLAN based EVPN OAM. This specification conforms to 391 [ietf-bfd-vxlan]. 393 6.2.1 VXLAN Unicast 395 Figure 2 below shows the unicast VXLAN encapsulation. The outer and 396 inner IP headers have a unicast source IP address of the BFD message 397 source and a destination IP address of the BFD message destination 399 The destination UDP port MUST be 3784 [RFC5881]. The source port MUST 400 be in the range 49152 through 65535. If the BFD source has multiple 401 IP addresses, entropy MAY be further obtained by using any of those 402 addresses assuming the source is prepared for responses directed to 403 the IP address used. 405 The Your BFD discriminator is the value distributed for this unicast 406 OAM purpose by the destination using BGP as specified in Section 7 or 407 is exchanged out-of-band or through some other means outside the 408 scope of this document. 410 Internet-Draft Fault Management for EVPN 412 <---------- 4 bytes ----------> 413 +-------------------------------+ --- 414 | Destination MAC Address | | 415 + +---------------+ | 416 | | | | 417 +---------------+ + L2 Header 418 | Source MAC Address | | 419 +-------------------------------+ | 420 | VLAN Tag | | 421 +---------------+---------------+ | 422 |IP4/6 Ethertype| | 423 +---------------+---------------+ --- 424 / / 425 /... IP4/6 Header .../ 426 / / 427 +-------------------------------+ 428 | | 429 + UDP Header + 430 | | 431 +-------------------------------+ 432 | | 433 + VXLAN Header + 434 | | 435 +-------------------------------+ --- 436 | Destination MAC Address | | 437 + +---------------+ | 438 | | | | 439 +---------------+ + L2 Header 440 | Source MAC Address | | 441 +---------------+---------------+ | 442 | IP4 Ethertype | | 443 +---------------+---------------+ --- 444 / / 445 /... IP4 Header .../ 446 / / 447 +-------------------------------+ 448 | | 449 + UDP Header + 450 | | 451 +---------------+---------------+ 452 | | 453 + BFD Control Packet + 454 | | 455 /... .../ 457 Figure 2. VXLAN Unicast Encapsulation 459 Internet-Draft Fault Management for EVPN 461 6.2.2 VXLAN Ingress Replication 463 The BFD packet construction is as given in Section 6.2.1 except as 464 follows: 465 (1) The destination IP address used by the BFD message source is that 466 advertised by the destination PE in its Inclusive Multicast EVPN 467 route for the MP2P tunnel in question; and 468 (2) The Your BFD discriminator used is the one advertised by the BFD 469 destination using BGP as specified in Section 7 for the MP2P 470 tunnel in question or is exchanged out-of-band or through some 471 other means outside the scope of this document. 473 6.2.3 VXLAN LSM (Label Switched Multicast, P2MP) 475 The VXLAN encapsulation for the head-to-tails BFD packets uses the 476 multicast destination IP corresponding to the VXLAN VNI. 478 The destination port MUST be 3784. For entropy purposes, the source 479 port can vary but MUST be in the range 49152 through 65535 [RFC5881]. 480 If the head PE has multiple IP addresses, entropy MAY be further 481 obtained by using any of those addresses. 483 The Your BFD discriminator is the value distributed for this 484 multicast OAM purpose by the BFD message using BGP as specified in 485 Section 7 or is exchanged out-of-band or through some other means 486 outside the scope of this document. 488 Internet-Draft Fault Management for EVPN 490 7. BGP Distribution of BFD Discriminators 492 BGP is used to distribute BFD discriminators for use in EVPN OAM as 493 follows using the BGP-BFD Attribute as specified in 494 [ietf-bess-mvpn-fast-failover]. This attribute is included with 495 appropriate EVPN routes as follows: 497 Unicast: MAC/IP Advertisement Route [RFC7432]. 499 MP2P Tunnel: Inclusive Multicast Ethernet Tag Route [RFC7432]. 501 P2MP: TBD 503 [Need more text on BFD sessions reacting to the new advertisement 504 and withdrawal of the BGP-BFD Attribute.] 506 Internet-Draft Fault Management for EVPN 508 8. Scalability Considerations 510 The mechanisms proposed by this draft could affect the packet load on 511 the network and its elements especially when supporting 512 configurations involving a large number of EVIs. The option of 513 slowing down or speeding up BFD timer values can be used by an 514 administrator or a network management entity to maintain the overhead 515 incurred due to fault monitoring at an acceptable level. 517 Internet-Draft Fault Management for EVPN 519 9. IANA Considerations 521 The following IANA Actions are requested. 523 9.1 Pseudowire Associated Channel Type 525 IANA is requested to assign a channel type from the "Pseudowire 526 Associated Channel Types" registry in [RFC4385] as follows. 528 Value Description Reference 529 ----- ------------ ------------ 530 TBD1 BFD-EVPN OAM [this document] 532 9.2 MAC Address 534 IANA is requested to assign a multicast MAC address under the IANA 535 OUI [0x01005E900004 suggested] as follows: 537 Address Usage Reference 538 ------- -------- --------------- 539 TBD-A EVPN OAM [this document] 541 Internet-Draft Fault Management for EVPN 543 10. Security Considerations 545 Security considerations discussed in [RFC5880], [RFC5883], and 546 [RFC8029] apply. 548 MPLS security considerations [RFC5920] apply to BFD Control packets 549 encapsulated in a MPLS label stack. When BPD Control packets are 550 routed, the authentication considerations discussed in [RFC5883] 551 should be followed. 553 VXLAN BFD security considerations in [ietf-vxlan-bfd] apply to BFD 554 packets encapsulate in VXLAN. 556 Acknowledgements 558 The authors wish to thank the following for their comments and 559 suggestions: 561 Mach Chen 563 Internet-Draft Fault Management for EVPN 565 Normative References 567 [ietf-bess-evpn-inter-subnet-forwarding] Sajassi, A., Salam, S., 568 Thoria, S., Rekhter, Y., Drake, J., Yong, L., and L. 569 Dunbar, "Integrated Routing and Bridging in EVPN", 570 draft-ietf-bess-evpn-inter-subnet-forwarding-08, work in 571 progress, March 2019. 573 [ietf-bess-mvpn-fast-failover] Morin, T., Kebler, R., Mirsky, G., 574 "Multicast VPN fast upstream failover", 575 draft-ietf-bess-mvpn-fast-failover-05 (work in progress), 576 February 2019. 578 [ietf-bfd-vxlan] Pallagatti, S., Paragiri, S., Govindan, V., 579 Mudigonda, M., G. Mirsky, "BFD for VXLAN", 580 draft-ietf-bfd-vxlan (work in progress), October 2020. 582 [mirsky-mpls-p2mp-bfd] G. Mirsky, S. Mishra, "BFD for Multipoint 583 Networks over Point-to-Multi-Point MPLS LSP", draft-mirsky- 584 mpls-p2mp-bfd (work in progress), October 2020. 586 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 587 RFC 1812, DOI 10.17487/RFC1812, June 1995, 588 . 590 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 591 Requirement Levels", BCP 14, RFC 2119, DOI 592 10.17487/RFC2119, March 1997, . 595 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 596 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 597 2006, . 599 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 600 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 601 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 602 February 2006, . 604 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 605 "MPLS Generic Associated Channel", RFC 5586, DOI 606 10.17487/RFC5586, June 2009, . 609 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 610 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 611 . 613 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 614 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 616 Internet-Draft Fault Management for EVPN 618 10.17487/RFC5881, June 2010, . 621 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 622 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 623 June 2010, . 625 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 626 "Bidirectional Forwarding Detection (BFD) for MPLS Label 627 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 628 June 2010, . 630 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. 631 Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 632 6790, DOI 10.17487/RFC6790, November 2012, . 635 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 636 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 637 eXtensible Local Area Network (VXLAN): A Framework for 638 Overlaying Virtualized Layer 2 Networks over Layer 3 639 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 640 . 642 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 643 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 644 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 645 2015, . 647 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 648 Henderickx, "Provider Backbone Bridging Combined with 649 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 650 September 2015, . 652 [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. 653 Aldrin, "Clarifying Procedures for Establishing BFD 654 Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, 655 DOI 10.17487/RFC7726, January 2016, . 658 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 659 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 660 Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 661 10.17487/RFC8029, March 2017, . 664 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 665 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 666 2017, . 668 Internet-Draft Fault Management for EVPN 670 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 671 Uttaro, J., and W. Henderickx, "A Network Virtualization 672 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 673 10.17487/RFC8365, March 2018, . 676 [RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 677 Ed., "Bidirectional Forwarding Detection (BFD) Multipoint 678 Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019, 679 . 681 Informative References 683 [ietf-bess-evpn-oam-req-frmwk] Salam, S., Sajassi, A., Aldrin, S., J. 684 Drake, and D. Eastlake, "EVPN Operations, Administration 685 and Maintenance Requirements and Framework", 686 draft-ietf-bess-evpn-oam-req-frmwk-00, work in progress, 687 February 2019. 689 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 690 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 691 . 693 Internet-Draft Fault Management for EVPN 695 Authors' Addresses 697 Vengada Prasad Govindan 698 Cisco Systems 700 Email: venggovi@cisco.com 702 Mudigonda Mallik 703 Cisco Systems 705 Email: mmudigon@cisco.com 707 Ali Sajassi 708 Cisco Systems 709 170 West Tasman Drive 710 San Jose, CA 95134, USA 712 Email: sajassi@cisco.com 714 Gregory Mirsky 715 ZTE Corp. 717 Email: gregimirsky@gmail.com 719 Donald Eastlake, 3rd 720 Futurewei Technologies 721 2386 Panoramic Circle 722 Apopka, FL 32703 USA 724 Phone: +1-508-333-2270 725 Email: d3e3e3@gmail.com 727 Internet-Draft Fault Management for EVPN 729 Copyright, Disclaimer, and Additional IPR Provisions 731 Copyright (c) 2020 IETF Trust and the persons identified as the 732 document authors. All rights reserved. 734 This document is subject to BCP 78 and the IETF Trust's Legal 735 Provisions Relating to IETF Documents 736 (http://trustee.ietf.org/license-info) in effect on the date of 737 publication of this document. Please review these documents 738 carefully, as they describe your rights and restrictions with respect 739 to this document. Code Components extracted from this document must 740 include Simplified BSD License text as described in Section 4.e of 741 the Trust Legal Provisions and are provided without warranty as 742 described in the Simplified BSD License.