idnits 2.17.1 draft-gmsm-bess-evpn-bfd-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 (July 6, 2019) is 1728 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: January 5, 2020 July 6, 2019 11 Fault Management for EVPN networks 12 draft-gmsm-bess-evpn-bfd-03 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 Unicast..............................................9 64 6.1.2 Ingress Replication.................................10 65 6.1.3 LSM (Label Switched Multicast, P2MP)................11 66 6.2 VXLAN Encapsulation...................................11 67 6.2.1 Unicast.............................................11 68 6.2.2 Ingress Replication.................................13 69 6.2.3 LSM (Label Switched Multicast, P2MP)................13 71 7. BGP Distribution of BFD Discriminators.................14 72 8. Scalability Considerations.............................14 74 9. IANA Considerations....................................15 75 9.1 Pseudowire Associated Channel Type....................15 76 9.2 MAC Address...........................................15 78 10. Security Considerations...............................15 80 Acknowledgement...........................................15 82 Normative References......................................16 83 Informative References....................................18 85 Authors' Addresses........................................19 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 using BFD 102 [RFC5880] and for BUM traffic using BFD or [RFC8563] depending on 103 whether an MP2P or P2MP tunnel is being used. 105 Packet loss and packet delay measurement are out of scope for this 106 document. 108 1.1 Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 The following acronyms are used in this document. 118 BFD - Bidirectional Forwarding Detection [RFC5880] 120 BUM - Broadcast, Unknown Unicast, and Multicast 122 CC - Continuity Check 124 CV - Connectivity Verification 126 EVI - EVPN Instance 128 EVPN - Ethernet VPN [RFC7432] 130 FEC - Forwarding Equivalency Class 132 GAL - Generic Associated Channel Label [RFC5586] 134 LSM - Label Switched Multicast (P2MP) 136 LSP - Label Switched Path 138 Internet-Draft Fault Management for EVPN 140 MP2P - Multi-Point to Point 142 OAM - Operations Administration, and Maintenance 144 P2MP - Point to Multi-Point (LSM) 146 PE - Provider Edge 148 VXLAN - Virtual eXtesible Local Area Network (VXLAN) [RFC7348] 150 Internet-Draft Fault Management for EVPN 152 2. Scope of this Document 154 This document specifies BFD based mechanisms for proactive fault 155 detection for EVPN both as specified in [RFC7432] and also for EVPN 156 using VXLAN encapsulation [ietf-vxlan-bfd]. It covers the following: 158 o Unicast traffic. 160 o BUM traffic using Multi-point-to-Point (MP2P) tunnels (ingress 161 replication). 163 o BUM traffic using Point-to-Multipoint (P2MP) tunnels (Label 164 Switched Multicast (LSM)). 166 o MPLS and VXLAN encapsulation. 168 This document does not discuss BFD mechanisms for: 170 o EVPN variants like PBB-EVPN [RFC7623]. It is intended to 171 address this in future versions. 173 o Integrated Routing and Bridging (IRB) solution based on EVPN 174 [ietf-bess-evpn-inter-subnet-forwarding]. It is intended to 175 address this in future versions. 177 o EVPN using other encapsulations such as NVGRE or MPLS over GRE 178 [RFC8365]. 180 o BUM traffic using MP2MP tunnels. 182 This specification specifies procedures for BFD asynchronous mode. 183 BFD demand mode is outside the scope of this specification except as 184 it is used in [RFC8563]. The use of the Echo function is outside the 185 scope of this specification. 187 Internet-Draft Fault Management for EVPN 189 3. Motivation for Running BFD at the EVPN Network Layer 191 The choice of running BFD at the network layer of the OAM model for 192 EVPN [ietf-bess-evpn-oam-req-frmwk] was made after considering the 193 following: 195 o In addition to detecting link failures in the EVPN network, BFD 196 sessions at the network layer can be used to monitor the 197 successful setup of MP2P and P2MP EVPN tunnels transporting 198 Unicast and BUM traffic such as label programming. The scope of 199 reachability detection covers the ingress and the egress EVPN PE 200 nodes and the network connecting them. 202 o Monitoring a representative set of path(s) or a particular path 203 among the multiple paths available between two EVPN PE nodes could 204 be done by exercising entropy mechanisms such as entropy labels, 205 when they are used, or VXLAN source ports. However, paths that 206 cannot be realized by entropy variations cannot be monitored. 207 Fault monitoring requirements outlined by 208 [ietf-bess-evpn-oam-req-frmwk] are addressed by the mechanisms 209 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 active tail multipoint BFD [RFC8563] in one of the three scenarios 286 providing head notification (see Section 5.2 of [RFC8563]). 288 For MPLS encapsulation of the head to tails BFD, Label Switched 289 Multicast is used. For VXLAN encapsulation, BFD is delivered to the 290 tails through underlay multicast using an outer multicast IP address. 292 Internet-Draft Fault Management for EVPN 294 6. BFD Packet Encapsulation 296 The sections below describe the MPLS and VXLAN encapsulations of BFD 297 for EVPN OAM use. 299 6.1 MPLS Encapsulation 301 This section describes use of the Generic Associated Channel Label 302 (GAL) for BFD encapsulation in MPLS based EVPN OAM. 304 6.1.1 Unicast 306 The packet initially contains the following labels: LSP label 307 (transport), the optional entropy label, and the EVPN Unicast label. 308 The G-ACh type is set to TBD1. The G-ACh payload of the packet MUST 309 contain the destination L2 header (in overlay space) followed by the 310 IP header that encapsulates the BFD packet. The MAC address of the 311 inner packet is used to validate the in the receiving 312 node. 314 - The destination MAC MUST be the dedicated MAC TBD-A (see Section 315 9) or the MAC address of the destination PE. 316 - The destination IP address MUST be in the 127.0.0.0/8 range for 317 IPv4 or in the 0:0:0:0:0:FFFF:7F00:0/104 range for IPv6. 318 - The destination IP port MUST be 3784 [RFC5881]. 319 - The source IP port MUST be in the range 49152 through 65535. 320 - The discriminator values for BFD are obtained through BGP as 321 specified in Section 7 or are exchanged out-of-band or through 322 some other means outside the scope of this document. 324 Internet-Draft Fault Management for EVPN 326 <---------- 4 bytes ----------> 327 +-------------------------------+ ----- 328 | LSP Label | | 329 +-------------------------------+ | 330 : entropy label indicator : | 331 + (optional) + MPLS Label Stack 332 : entropy label : | 333 +-------------------------------+ | 334 | EVPN Unicast label | 335 +-------------------------------+ | 336 | Generic Assoc. Channel Label | | 337 +-------------------------------+ ----- 338 | ACH word, Type TBD1 no TLVs | 339 +-------------------------------+ --- ------- 340 | Destination MAC Address | | | 341 + +---------------+ | | 342 | TBD-A | | | | 343 +---------------+ + L2 Header | 344 | Source MAC Address | | | 345 +---------------+---------------+ | | 346 | VLAN Ethertype| VLAN-ID | | | 347 +---------------+---------------+ | | 348 |IP4/6 Ethertype| | | 349 +---------------+---------------+ --- | 350 / / G-ACh Payload 351 /... IP4/6 Header .../ | 352 / / | 353 +-------------------------------+ | 354 | | | 355 + UDP Header + | 356 | | | 357 +-------------------------------+ | 358 | | | 359 + BFD Control Packet + | 360 / / | 361 /... .../ --------------- 363 6.1.2 Ingress Replication 365 The packet initially contains the following labels: LSP label 366 (transport), the optional entropy label, the BUM label, and the split 367 horizon label [RFC7432] (where applicable). The G-ACh type is set to 368 TBD1. The G-ACh payload of the packet is as described in Section 369 6.1.1. 371 Internet-Draft Fault Management for EVPN 373 6.1.3 LSM (Label Switched Multicast, P2MP) 375 The encapsulation is the same as in Section 6.1.2 for ingress 376 replication except that the transport label identifies the P2MP 377 tunnel, in effect the set of tail PEs, rather than identifying a 378 single destination PE at the end of an MP2P tunnel. 380 6.2 VXLAN Encapsulation 382 This section describes the use of the VXLAN [RFC7348] for BFD 383 encapsulation in VXLAN based EVPN OAM. This specification conforms to 384 [ietf-bfd-vxlan]. 386 6.2.1 Unicast 388 The outer and inner IP headers have a unicast source IP address of 389 the BFD message source and a destination IP address of the BFD 390 message destination 392 The destination UDP port MUST be 3784 [RFC5881]. The source port MUST 393 be in the range 49152 through 65535. If the BFD source has multiple 394 IP addresses, entropy MAY be further obtained by using any of those 395 addresses assuming the source is prepared for responses directed to 396 the IP address used. 398 The Your BFD discriminator is the value distributed for this unicast 399 OAM purpose by the destination using BGP as specified in Section 7 or 400 is exchanged out-of-band or through some other means outside the 401 scope of this document. 403 Internet-Draft Fault Management for EVPN 405 <---------- 4 bytes ----------> 406 +-------------------------------+ --- 407 | Destination MAC Address | | 408 + +---------------+ | 409 | | | | 410 +---------------+ + L2 Header 411 | Source MAC Address | | 412 +-------------------------------+ | 413 | VLAN Tag | | 414 +---------------+---------------+ | 415 |IP4/6 Ethertype| | 416 +---------------+---------------+ --- 417 / / 418 /... IP4/6 Header .../ 419 / / 420 +-------------------------------+ 421 | | 422 + UDP Header + 423 | | 424 +-------------------------------+ 425 | | 426 + VXLAN Header + 427 | | 428 +-------------------------------+ --- 429 | Destination MAC Address | | 430 + +---------------+ | 431 | | | | 432 +---------------+ + L2 Header 433 | Source MAC Address | | 434 +---------------+---------------+ | 435 | IP4 Ethertype | | 436 +---------------+---------------+ --- 437 / / 438 /... IP4 Header .../ 439 / / 440 +-------------------------------+ 441 | | 442 + UDP Header + 443 | | 444 +---------------+---------------+ 445 | | 446 + BFD Control Packet + 447 | | 448 /... .../ 450 Internet-Draft Fault Management for EVPN 452 6.2.2 Ingress Replication 454 The BFD packet construction is as given in Section 6.2.1 except as 455 follows: 456 (1) The destination IP address used by the BFD message source is that 457 advertised by the destination PE in its Inclusive Multicast EVPN 458 route for the MP2P tunnel in question; and 459 (2) The Your BFD discriminator used is the one advertised by the BFD 460 destination using BGP as specified in Section 7 for the MP2P 461 tunnel in question or is exchanged out-of-band or through some 462 other means outside the scope of this document. 464 6.2.3 LSM (Label Switched Multicast, P2MP) 466 The VXLAN encapsulation for the head-to-tails BFD packets uses the 467 multicast destination IP corresponding to the VXLAN VNI. 469 The destination port MUST be 3784. For entropy purposes, the source 470 port can vary but MUST be in the range 49152 through 65535 [RFC5881]. 471 If the head PE has multiple IP addresses, entropy MAY be further 472 obtained by using any of those addresses. 474 The Your BFD discriminator is the value distributed for this unicast 475 OAM purpose by the BFD message using BGP as specified in Section 7 or 476 is exchanged out-of-band or through some other means outside the 477 scope of this document. 479 Internet-Draft Fault Management for EVPN 481 7. BGP Distribution of BFD Discriminators 483 BGP is used to distribute BFD discriminators for use in EVPN OAM as 484 follows using the BGP-BFD Attribute as specified in 485 [ietf-bess-mvpn-fast-failover]. This attribute is included with 486 appropriate EVPN routes as follows: 488 Unicast: MAC/IP Advertisement Route [RFC7432]. 490 MP2P Tunnel: Inclusive Multicast Ethernet Tag Route [RFC7432]. 492 P2MP: TBD 494 [Need more text on BFD sessions reacting to the new advertisement 495 and withdrawal of the BGP-BFD Attribute.] 497 8. Scalability Considerations 499 The mechanisms proposed by this draft could affect the packet load on 500 the network and its elements especially when supporting 501 configurations involving a large number of EVIs. The option of 502 slowing down or speeding up BFD timer values can be used by an 503 administrator or a network management entity to maintain the overhead 504 incurred due to fault monitoring at an acceptable level. 506 Internet-Draft Fault Management for EVPN 508 9. IANA Considerations 510 The following IANA Actions are requested. 512 9.1 Pseudowire Associated Channel Type 514 IANA is requested to assign a channel type from the "Pseudowire 515 Associated Channel Types" registry in [RFC4385] as follows. 517 Value Description Reference 518 ----- ------------ ------------ 519 TBD1 BFD-EVPN OAM [this document] 521 9.2 MAC Address 523 IANA is requested to assign a multicast MAC address under the IANA 524 OUI [0x01005E900004 suggested] as follows: 526 Address Usage Reference 527 ------- -------- --------------- 528 TBD-A EVPN OAM [this document] 530 10. Security Considerations 532 Security considerations discussed in [RFC5880], [RFC5883], and 533 [RFC8029] apply. 535 MPLS security considerations [RFC5920] apply to BFD Control packets 536 encapsulated in a MPLS label stack. When BPD Control packets are 537 routed, the authentication considerations discussed in [RFC5883] 538 should be followed. 540 VXLAN BFD security considerations in [ietf-vxlan-bfd] apply to BFD 541 packets encapsulate in VXLAN. 543 Acknowledgement 545 The authors wish to thank the following for their comments and 546 suggestions: 548 Mach Chen 550 Internet-Draft Fault Management for EVPN 552 Normative References 554 [ietf-bess-evpn-inter-subnet-forwarding] Sajassi, A., Salam, S., 555 Thoria, S., Rekhter, Y., Drake, J., Yong, L., and L. 556 Dunbar, "Integrated Routing and Bridging in EVPN", 557 draft-ietf-bess-evpn-inter-subnet-forwarding-08, work in 558 progress, March 2019. 560 [ietf-bess-mvpn-fast-failover] Morin, T., Kebler, R., Mirsky, G., 561 "Multicast VPN fast upstream failover", 562 draft-ietf-bess-mvpn-fast-failover-05 (work in progress), 563 February 2019. 565 [ietf-bfd-vxlan] Pallagatti, S., Paragiri, S., Govindan, V., 566 Mudigonda, M., G. Mirsky, "BFD for VXLAN", 567 draft-ietf-bfd-vxlan-07 (work in progress), May 2019. 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, DOI 571 10.17487/RFC2119, March 1997, . 574 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 575 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 576 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 577 February 2006, . 579 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 580 "MPLS Generic Associated Channel", RFC 5586, DOI 581 10.17487/RFC5586, June 2009, . 584 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 585 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 586 . 588 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 589 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 590 10.17487/RFC5881, June 2010, . 593 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 594 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 595 June 2010, . 597 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 598 "Bidirectional Forwarding Detection (BFD) for MPLS Label 599 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 600 June 2010, . 602 Internet-Draft Fault Management for EVPN 604 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. 605 Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 606 6790, DOI 10.17487/RFC6790, November 2012, . 609 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 610 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 611 eXtensible Local Area Network (VXLAN): A Framework for 612 Overlaying Virtualized Layer 2 Networks over Layer 3 613 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 614 . 616 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 617 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 618 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 619 2015, . 621 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 622 Henderickx, "Provider Backbone Bridging Combined with 623 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 624 September 2015, . 626 [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. 627 Aldrin, "Clarifying Procedures for Establishing BFD 628 Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, 629 DOI 10.17487/RFC7726, January 2016, . 632 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 633 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 634 Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 635 10.17487/RFC8029, March 2017, . 638 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 639 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 640 2017, . 642 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 643 Uttaro, J., and W. Henderickx, "A Network Virtualization 644 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 645 10.17487/RFC8365, March 2018, . 648 [RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 649 Ed., "Bidirectional Forwarding Detection (BFD) Multipoint 650 Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019, 651 . 653 Internet-Draft Fault Management for EVPN 655 Informative References 657 [ietf-bess-evpn-oam-req-frmwk] Salam, S., Sajassi, A., Aldrin, S., J. 658 Drake, and D. Eastlake, "EVPN Operations, Administration 659 and Maintenance Requirements and Framework", 660 draft-ietf-bess-evpn-oam-req-frmwk-00, work in progress, 661 February 2019. 663 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 664 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 665 . 667 Internet-Draft Fault Management for EVPN 669 Authors' Addresses 671 Vengada Prasad Govindan 672 Cisco Systems 674 Email: venggovi@cisco.com 676 Mudigonda Mallik 677 Cisco Systems 679 Email: mmudigon@cisco.com 681 Ali Sajassi 682 Cisco Systems 683 170 West Tasman Drive 684 San Jose, CA 95134, USA 686 Email: sajassi@cisco.com 688 Gregory Mirsky 689 ZTE Corp. 691 Email: gregimirsky@gmail.com 693 Donald Eastlake, 3rd 694 Huawei Technologies 695 1424 Pro Shop Court 696 Davenport, FL 33896 USA 698 Phone: +1-508-333-2270 699 Email: d3e3e3@gmail.com 701 Internet-Draft Fault Management for EVPN 703 Copyright, Disclaimer, and Additional IPR Provisions 705 Copyright (c) 2019 IETF Trust and the persons identified as the 706 document authors. All rights reserved. 708 This document is subject to BCP 78 and the IETF Trust's Legal 709 Provisions Relating to IETF Documents 710 (http://trustee.ietf.org/license-info) in effect on the date of 711 publication of this document. Please review these documents 712 carefully, as they describe your rights and restrictions with respect 713 to this document. Code Components extracted from this document must 714 include Simplified BSD License text as described in Section 4.e of 715 the Trust Legal Provisions and are provided without warranty as 716 described in the Simplified BSD License.