idnits 2.17.1 draft-gmsm-bess-evpn-bfd-02.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 (February 21, 2019) is 1890 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 Huawei Technologies 9 Expires: August 20, 2019 February 21, 2019 11 Fault Management for EVPN networks 12 draft-gmsm-bess-evpn-bfd-02 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 [salam-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 [ietf-bfd-multipoint- 103 active-tail] depending on whether an MP2P or P2MP tunnel is being 104 used. 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]. This will be addressed 172 in future versions. 174 o Integrated Routing and Bridging (IRB) solution based on EVPN 175 [ietf-bess-evpn-inter-subnet-forwarding]. This will be 176 addressed in future versions. 178 o EVPN using other encapsulations such as NVGRE and MPLS over GRE 179 [RFC8365]. 181 o BUM traffic using MP2MP tunnels. 183 This specification specifies procedures for BFD asynchronous mode. 184 BFD demand mode is outside the scope of this specification except as 185 it is used in [ietf-bfd-multipoint-active-tail]. The use of the Echo 186 function is outside the 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 [salam-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 the multiple paths available between two EVPN PE nodes could 205 be done by exercising entropy mechanisms such as entropy labels, 206 when they are used, or VXLAN source ports. However, paths that 207 cannot be realized by entropy variations cannot be monitored. 208 Fault monitoring requirements outlined by 209 [salam-bess-evpn-oam-req-frmwk] are addressed by the mechanisms 210 proposed by this draft. 212 BFD testing between EVPN PE nodes does not guarantee that the EVPN 213 service is functioning. (This can be monitored at the service level, 214 that is CE to CE.) For example, an egress EVPN-PE could understand 215 EVPN labeling received but could switch data to an incorrect 216 interface. However, BFD testing in the EVPN Network Layer does 217 provide additional confidence that data transported using those 218 tunnels will reach the expected egress node. When BFD testing in the 219 EVPN overlay fails, that can be used as an indication of a Loss-of- 220 Connectivity defect in the EVPN underlay that would cause EVPN 221 service failure. 223 Internet-Draft Fault Management for EVPN 225 4. Fault Detection for Unicast Traffic 227 The mechanisms specified in BFD for MPLS LSPs [RFC5884] [RFC7726] are 228 applied to test the handling of unicast EVPN traffic. The 229 discriminators required for de-multiplexing the BFD sessions are 230 advertised through BGP as specified in Section 7. This is needed for 231 MPLS since the label stack does not contain enough information to 232 disambiguate the sender of the packet. 234 The usage of MPLS entropy labels or various VXLAN source ports takes 235 care of the requirement to monitor various paths of the multi-path 236 server layer network [RFC6790]. Each unique realizable path between 237 the participating PE routers MAY be monitored separately when such 238 entropy is used. At least one path of multi-path connectivity 239 between two PE routers MUST be tracked with BFD, but in that case the 240 granularity of fault-detection will be coarser. To support unicast 241 OAM, each PE node MUST allocate a BFD discriminator to be used for 242 BFD messages to that PE and MUST advertise this discriminator with 243 BGP as specified in Section 7. Once the BFD session for the EVPN 244 label is UP, the ends of the BFD session MUST NOT change the local 245 discriminator values of the BFD Control packets they generate, unless 246 they first bring down the session as specified in [RFC5884]. 248 Internet-Draft Fault Management for EVPN 250 5. Fault Detection for BUM Traffic 252 Section 5.1 below discusses fault detection for MP2P tunnels using 253 ingress replication and Section 5.2 discusses fault detection for 254 P2MP tunnels. 256 5.1 Ingress Replication 258 Ingress replication uses separate MP2P tunnels for transporting BUM 259 traffic from the ingress PE (head) to a set of one or more egress PEs 260 (tails). The fault detection mechanism specified by this document 261 takes advantage of the fact that the head makes a unique copy for 262 each tail. 264 Another key aspect to be considered in EVPN is the advertisement of 265 the inclusive multicast route. The BUM traffic flows from a head 266 node to a particular tail only after the head receives the inclusive 267 multicast route. This contains the BUM EVPN label (downstream 268 allocated) corresponding to the MP2P tunnel for MPLS encapsulation 269 and contains the IP address of the PE originating the inclusive 270 multicast route for use in VXLAN encapsulation. 272 There MAY exist multiple BFD sessions between a head PE and an 273 individual tail due to (1) the usage of MPLS entropy labels [RFC6790] 274 or VXLAN source ports for an inclusive multicast FEC and (2) due to 275 multiple MP2P tunnels indicated by different tail labels or IP 276 addresses for MPLS or VXLAN. The BFD discriminator to be used is 277 distributed by BGP as specified in Section 7. Once the BFD session 278 for the EVPN label is UP, the BFD systems terminating the BFD session 279 MUST NOT change the local discriminator values of the BFD Control 280 packets they generate, unless they first bring down the session as 281 specified in [RFC5884]. 283 5.2 P2MP Tunnels (Label Switched Multicast) 285 Fault detection for BUM traffic distributed using a P2MP tunnel uses 286 active tail multipoint BFD [ietf-bfd-multipoint-active-tail] in one 287 of the three scenarios providing head notification (see Section 5.2 288 of [ietf-bfd-multipoint-active-tail]). 290 For MPLS encapsulation of the head to tails BFD, Label Switched 291 Multicast is used. For VXLAN encapsulation, BFD is delivered to the 292 tails through underlay multicast using an outer multicast IP address. 294 Internet-Draft Fault Management for EVPN 296 6. BFD Packet Encapsulation 298 The sections below describe the MPLS and VXLAN encapsulations of BFD 299 for EVPN OAM use. 301 6.1 MPLS Encapsulation 303 This section describes use of the Generic Associated Channel Label 304 (GAL) for BFD encapsulation in MPLS based EVPN OAM. 306 6.1.1 Unicast 308 The packet initially contains the following labels: LSP label 309 (transport), the optional entropy label and the EVPN Unicast label. 310 The G-ACh type is set to TBD1. The G-ACh payload of the packet MUST 311 contain the destination L2 header (in overlay space) followed by the 312 IP header that encapsulates the BFD packet. The MAC address of the 313 inner packet is used to validate the in the receiving 314 node. 316 - The destination MAC MUST be the dedicated MAC TBD-A (see Section 317 9) or the MAC address of the destination PE. 318 - The destination IP address MUST be in the 127.0.0.0/8 range for 319 IPv4 or in the 0:0:0:0:0:FFFF:7F00:0/104 range for IPv6. 320 - The destination IP port MUST be 3784 [RFC5881]. 321 - The source IP port MUST be in the range 49152 through 65535. 322 - The discriminator values for BFD are obtained through BGP as 323 specified in Section 7 or are exchanged out-of-band or through 324 some other means outside the scope of this document. 326 Internet-Draft Fault Management for EVPN 328 <---------- 4 bytes ----------> 329 +-------------------------------+ ----- 330 | LSP Label | | 331 +-------------------------------+ | 332 : entropy label indicator : | 333 + (optional) + MPLS Label Stack 334 : entropy label : | 335 +-------------------------------+ | 336 | EVPN Unicast label | 337 +-------------------------------+ | 338 | Generic Assoc. Channel Label | | 339 +-------------------------------+ ----- 340 | ACH word, Type TBD1 no TLVs | 341 +-------------------------------+ --- ------- 342 | Destination MAC Address | | | 343 + +---------------+ | | 344 | TBD-A | | | | 345 +---------------+ + L2 Header | 346 | Source MAC Address | | | 347 +---------------+---------------+ | | 348 | VLAN Ethertype| VLAN-ID | | | 349 +---------------+---------------+ | | 350 |IP4/6 Ethertype| | | 351 +---------------+---------------+ --- | 352 / / G-ACh Payload 353 /... IP4/6 Header .../ | 354 / / | 355 +-------------------------------+ | 356 | | | 357 + UDP Header + | 358 | | | 359 +-------------------------------+ | 360 | | | 361 + BFD Control Packet + | 362 / / | 363 /... .../ --------------- 365 6.1.2 Ingress Replication 367 The packet initially contains the following labels: LSP label 368 (transport), the optional entropy label, the BUM label, and the split 369 horizon label [RFC7432] (where applicable). The G-ACh type is set to 370 TBD1. The G-ACh payload of the packet is as described in Section 371 6.1.2. 373 Internet-Draft Fault Management for EVPN 375 6.1.3 LSM (Label Switched Multicast, P2MP) 377 The encapsulation is the same as in Section 6.1.2 for ingress 378 replication except that the transport label identifies the P2MP 379 tunnel, in effect the set of tail PEs, rather than identifying a 380 single destination PE at the end of an MP2P tunnel. 382 6.2 VXLAN Encapsulation 384 This section describes the use of the VXLAN [RFC7348] for BFD 385 encapsulation in VXLAN based EVPN OAM. This specification conforms to 386 [ietf-bfd-vxlan]. 388 6.2.1 Unicast 390 The outer and inner IP headers have a unicast source IP address of 391 the BFD message source and the destination IP address the BFD message 392 destination 394 The destination UDP port MUST be 3784 [RFC5881]. The source port MUST 395 be in the range 49152 through 65535. If the BFD source has multiple 396 IP addresses, entropy MAY be further obtained by using any of those 397 addresses assuming the source is prepared for responses directed to 398 the IP address used. 400 The Your BFD discriminator is the value distributed for this unicast 401 OAM purpose by the destination using BGP as specified in Section 7 or 402 is exchanged out-of-band or through some other means outside the 403 scope of this document. 405 Internet-Draft Fault Management for EVPN 407 <---------- 4 bytes ----------> 408 +-------------------------------+ --- 409 | Destination MAC Address | | 410 + +---------------+ | 411 | | | | 412 +---------------+ + L2 Header 413 | Source MAC Address | | 414 +-------------------------------+ | 415 | VLAN Tag | | 416 +---------------+---------------+ | 417 | IP4 Ethertype | | 418 +---------------+---------------+ --- 419 / / 420 /... IP4 Header .../ 421 / / 422 +-------------------------------+ 423 | | 424 + UDP Header + 425 | | 426 +-------------------------------+ 427 | | 428 + VXLAN Header + 429 | | 430 +-------------------------------+ --- 431 | Destination MAC Address | | 432 + +---------------+ | 433 | | | | 434 +---------------+ + L2 Header 435 | Source MAC Address | | 436 +---------------+---------------+ | 437 | IP4 Ethertype | | 438 +---------------+---------------+ --- 439 / / 440 /... IP4 Header .../ 441 / / 442 +-------------------------------+ 443 | | 444 + UDP Header + 445 | | 446 +---------------+---------------+ 447 | | 448 + BFD Control Packet + 449 | | 450 /... .../ 452 Internet-Draft Fault Management for EVPN 454 6.2.2 Ingress Replication 456 The BFD packet construction is as given in Section 6.2.1 except as 457 follows: 458 (1) The destination IP address used by the BFD message source is that 459 advertised by the destination PE in its Inclusive Multicast EVPN 460 route for the MP2P tunnel in question; and 461 (2) The Your BFD discriminator used is the one advertised by the BFD 462 destination using BGP as specified in Section 7 for the MP2P 463 tunnel in question or is exchanged out-of-band or through some 464 other means outside the scope of this document. 466 6.2.3 LSM (Label Switched Multicast, P2MP) 468 The VXLAN encapsulation for the head-to-tails BFD packets uses the 469 multicast destination IP corresponding to the VXLAN VNI. 471 The destination port MUST be 3784. For entropy purposes, the source 472 port can vary but MUST be in the range 49152 through 65535 [RFC5881]. 473 If the head PE has multiple IP addresses, entropy MAY be further 474 obtained by using any of those addresses. 476 The Your BFD discriminator is the value distributed for this unicast 477 OAM purpose by the BFD message using BGP as specified in Section 7 or 478 is exchanged out-of-band or through some other means outside the 479 scope of this document. 481 Internet-Draft Fault Management for EVPN 483 7. BGP Distribution of BFD Discriminators 485 BGP is used to distribute BFD discriminators for use in EVPN OAM as 486 follows using the BGP-BFD Attribute as specified in 487 [ietf-bess-mvpn-fast-failover]. This attribute is included with 488 appropriate EVPN routes as follows: 490 Unicast: MAC/IP Advertisement Route [RFC7432]. 492 MP2P Tunnel: Inclusive Multicast Ethernet Tag Route [RFC7432]. 494 P2MP: TBD 496 [Need more text on BFD session reacting to the new advertisement and 497 withdrawal of the BGP-BFD Attribute.] 499 8. Scalability Considerations 501 The mechanisms proposed by this draft could affect the packet load on 502 the network and its elements especially when supporting 503 configurations involving a large number of EVIs. The option of 504 slowing down or speeding up BFD timer values can be used by an 505 administrator or a network management entity to maintain the overhead 506 incurred due to fault monitoring at an acceptable level. 508 Internet-Draft Fault Management for EVPN 510 9. IANA Considerations 512 The following IANA Actions are requested. 514 9.1 Pseudowire Associated Channel Type 516 IANA is requested to assign a channel type from the "Pseudowire 517 Associated Channel Types" registry in [RFC4385] as follows. 519 Value Description Reference 520 ----- ------------ ------------ 521 TBD1 BFD-EVPN OAM [this document] 523 9.2 MAC Address 525 IANA is requested to assign a multicast MAC address under the IANA 526 OUI [0x01005E900004 suggested] as follows: 528 Address Usage Reference 529 ------- -------- --------------- 530 TBD-A EVPN OAM [this document] 532 10. Security Considerations 534 Security considerations discussed in [RFC5880], [RFC5883], and 535 [RFC8029] apply. 537 MPLS security considerations [RFC5920] apply to BFD Control packets 538 encapsulated in a MPLS label stack. When BPD Control packets are 539 routed, the authentication considerations discussed in [RFC5883] 540 should be followed. 542 VXLAN BFD security considerations in [ietf-vxlan-bfd] apply to BFD 543 packets encapsulate in VXLAN. 545 Acknowledgement 547 The authors wish to thank the following for their comments and 548 suggestions: 550 Mach Chen 552 Internet-Draft Fault Management for EVPN 554 Normative References 556 [ietf-bess-evpn-inter-subnet-forwarding] Sajassi, A., Salam, S., 557 Thoria, S., Rekhter, Y., Drake, J., Yong, L., and L. 558 Dunbar, "Integrated Routing and Bridging in EVPN", draft- 559 ietf-bess-evpn-inter-subnet-forwarding-05 (work in 560 progress), October 2015. 562 [ietf-bfd-multipoint-active-tail] Katz, D., Ward, D., and J. 563 Networks, "BFD Multipoint Active Tails.", draft-ietf-bfd- 564 multipoint-active-tail-09 (work in progress), May 2016. 566 [ietf-bfd-vxlan] Pallagatti, S., Paragiri, S., Govindan, V., 567 Mudigonda, M., G. Mirsky, "BFD for VXLAN", draft-ietf-bfd- 568 vxlan-03 (work in progress), October 2018. 570 [ietf-bess-mvpn-fast-failover] Morin, T., Kebler, R., Mirsky, G., 571 "Multicast VPN fast upstream failover", draft-ietf-bess- 572 mvpn-fast-failover (work in progress), November 2018. 574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", BCP 14, RFC 2119, DOI 576 10.17487/RFC2119, March 1997, . 579 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 580 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 581 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 582 February 2006, . 584 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 585 "MPLS Generic Associated Channel", RFC 5586, DOI 586 10.17487/RFC5586, June 2009, . 589 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 590 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 591 . 593 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 594 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 595 10.17487/RFC5881, June 2010, . 598 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 599 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 600 June 2010, . 602 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 603 "Bidirectional Forwarding Detection (BFD) for MPLS Label 605 Internet-Draft Fault Management for EVPN 607 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 608 June 2010, . 610 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. 611 Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 612 6790, DOI 10.17487/RFC6790, November 2012, . 615 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 616 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 617 eXtensible Local Area Network (VXLAN): A Framework for 618 Overlaying Virtualized Layer 2 Networks over Layer 3 619 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 620 . 622 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 623 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 624 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 625 2015, . 627 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 628 Henderickx, "Provider Backbone Bridging Combined with 629 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 630 September 2015, . 632 [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. 633 Aldrin, "Clarifying Procedures for Establishing BFD 634 Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, 635 DOI 10.17487/RFC7726, January 2016, . 638 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 639 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 640 Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 641 10.17487/RFC8029, March 2017, . 644 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 645 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 646 2017, . 648 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 649 Uttaro, J., and W. Henderickx, "A Network Virtualization 650 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 651 10.17487/RFC8365, March 2018, . 654 Internet-Draft Fault Management for EVPN 656 Informative References 658 [salam-bess-evpn-oam-req-frmwk] Salam, S., Sajassi, A., Aldrin, S., 659 and J. Drake, "EVPN Operations, Administration and 660 Maintenance Requirements and Framework", draft-salam-bess- 661 evpn-oam-req-frmwk-00 (work in progress), May 2018. 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.