idnits 2.17.1 draft-ietf-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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 2, 2020) is 1243 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: May 1, 2021 November 2, 2020 11 Fault Management for EVPN networks 12 draft-ietf-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...............................10 62 6.1 MPLS Encapsulation....................................10 63 6.1.1 MPLS Unicast........................................10 64 6.1.2 MPLS Ingress Replication............................11 65 6.1.3 MPLS LSM (Label Switched Multicast, P2MP)...........12 66 6.2 VXLAN Encapsulation...................................12 67 6.2.1 VXLAN Unicast.......................................12 68 6.2.2 VXLAN Ingress Replication...........................14 69 6.2.3 VXLAN LSM (Label Switched Multicast, P2MP)..........14 71 7. Scalability Considerations.............................15 73 8. IANA Considerations....................................16 74 8.1 Pseudowire Associated Channel Type....................16 75 8.2 MAC Address...........................................16 77 9. Security Considerations................................17 79 Acknowledgements..........................................17 81 Normative References......................................18 82 Informative References....................................20 84 Authors' Addresses........................................21 86 Internet-Draft Fault Management for EVPN 88 1. Introduction 90 [ietf-bess-evpn-oam-req-frmwk] outlines the OAM requirements of 91 Ethernet VPN networks (EVPN [RFC7432]). This document specifies 92 mechanisms for proactive fault detection at the network (overlay) 93 layer of EVPN. The mechanisms proposed in the draft use the widely 94 adopted Bidirectional Forwarding Detection (BFD [RFC5880]) protocol. 96 EVPN fault detection mechanisms need to consider unicast traffic 97 separately from Broadcast, Unknown Unicast, and Multicast (BUM) 98 traffic since they map to different Forwarding Equivalency Classes 99 (FECs) in EVPN. Hence this document proposes different fault 100 detection mechanisms to suit each type. For unicast traffic and BUM 101 traffic via MP2P tunnels, using BFD [RFC5880], and for BUM traffic 102 via a P2MP tunnel, using BFD Multipoint Active Tails [RFC8563] 103 [mirsky-mpls-p2mp-bfd]. 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 Internet-Draft Fault Management for EVPN 138 LSP - Label Switched Path 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 document specifies procedures for BFD asynchronous mode. BFD 183 demand mode is outside the scope of this specification except as it 184 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 multiple paths available between two EVPN PE nodes could be 204 done by exercising entropy mechanisms such as entropy labels, when 205 they are used, or VXLAN source ports. However, paths that cannot 206 be realized by entropy variations cannot be monitored. The fault 207 monitoring requirements outlined by [ietf-bess-evpn-oam-req-frmwk] 208 are addressed by the mechanisms proposed by this draft. 210 BFD testing between EVPN PE nodes does not guarantee that the EVPN 211 service is functioning. (This can be monitored at the service level, 212 that is CE to CE.) For example, an egress EVPN-PE could understand 213 EVPN labeling received but could switch data to an incorrect 214 interface. However, BFD testing in the EVPN Network Layer does 215 provide additional confidence that data transported using those 216 tunnels will reach the expected egress node. When BFD testing in the 217 EVPN overlay fails, that can be used as an indication of a Loss-of- 218 Connectivity defect in the EVPN underlay that would cause EVPN 219 service failure. 221 Internet-Draft Fault Management for EVPN 223 4. Fault Detection for Unicast Traffic 225 The mechanisms specified in BFD for MPLS LSPs [RFC5884] [RFC7726] are 226 applied to test the handling of unicast EVPN traffic. The 227 discriminators required for de-multiplexing the BFD sessions are 228 advertised through BGP. This is needed for MPLS since the label stack 229 does not contain enough information to identify the sender of the 230 packet. 232 The usage of MPLS entropy labels or various VXLAN source ports takes 233 care of the requirement to monitor various paths of the multi-path 234 server layer network [RFC6790]. Each unique realizable path between 235 the participating PE routers MAY be monitored separately when such 236 entropy is used. At least one path of multi-path connectivity 237 between two PE routers MUST be tracked with BFD, but in that case the 238 granularity of fault-detection will be coarser. 240 To support unicast OAM to a PE node, that PE MUST allocate a BFD 241 discriminator to be used for BFD messages to it and MUST advertise 242 this discriminator with BGP using the BFD Discriminator Attribute 243 [ietf-bess-mvpn-fast-failover] in an EVPN MAC/IP Advertisement Route 244 [RFC7432]. If configured to do so, once a PE knows a unicast route 245 and discriminator for another PE, it endeavors to bring UP and 246 maintain a BFD session to that other PE. Once the BFD session is UP, 247 the ends of the BFD session MUST NOT change the local discriminator 248 values of the BFD Control packets they generate, unless they first 249 bring down the session as specified in [RFC5884]. The session is 250 brought down if no route or discriminator is available due to 251 withdrawal. 253 Internet-Draft Fault Management for EVPN 255 5. Fault Detection for BUM Traffic 257 Section 5.1 below discusses fault detection for MP2P tunnels using 258 ingress replication and Section 5.2 discusses fault detection for 259 P2MP tunnels. 261 5.1 Ingress Replication 263 Ingress replication uses separate MP2P tunnels for transporting BUM 264 traffic from the ingress PE (head) to a set of one or more egress PEs 265 (tails). The fault detection mechanism specified by this document 266 takes advantage of the fact that the head makes a unique copy for 267 each tail. 269 Another key aspect to be considered in EVPN is the advertisement of 270 the Inclusive Multicast Ethernet Tag Route [RFC7432]. The BUM 271 traffic flows from a head node to a particular tail only after the 272 head receives the inclusive multicast route. This contains the BUM 273 EVPN MPLS label (downstream allocated) corresponding to the MP2P 274 tunnel for MPLS encapsulation and contains the IP address of the PE 275 originating the inclusive multicast route for use in VXLAN 276 encapsulation. It also contains a BFD Discriminator Attribute [ietf- 277 bess-mvpn-fast-failover]. 279 There MAY exist multiple BFD sessions between a head PE and an 280 individual tail due to (1) the usage of MPLS entropy labels [RFC6790] 281 or VXLAN source ports for an inclusive multicast FEC and (2) due to 282 multiple MP2P tunnels indicated by different tail labels or IP 283 addresses for MPLS or VXLAN. If configured to do so, once a PE knows 284 an inclusive multicast route and discriminator for another PE it 285 endeavors to bring UP and maintain a BFD session to that other PE. 286 Once a BFD session for an MP2P path is UP, the ends of the BFD 287 session MUST NOT change the local discriminator values of the BFD 288 Control packets they generate, unless they first bring down the 289 session as specified in [RFC5884]. The session is brought down if no 290 route or discriminator is available due to withdrawal. 292 5.2 P2MP Tunnels (Label Switched Multicast) 294 Fault detection for BUM traffic distributed using a P2MP tunnel uses 295 BFD Multipoint Active Tails in one of the three methods providing 296 head notification. Sections 5.2.2 and 5.2.3 of [RFC8563] describe two 297 of these scenarios ("Head Notification and Tail Solicitation with 298 Multipoint Polling" and "Head Notification with Composite Polling"). 299 [mirsky-mpls-p2mp-bfd] describes the third ("Head Notification 300 without Polling"). All three of these modes assume the existence of 302 Internet-Draft Fault Management for EVPN 304 unicast paths from the tails to the head. In addition, Head 305 Notification with Composite Polling assumes a head to tail unicast 306 path. 308 The BUM traffic flows from a head node to the tails after the head 309 receives an inclusive multicast route [RFC7432]. This contains the 310 BUM EVPN MPLS label (upstream allocated) corresponding to the P2MP 311 tunnel for MPLS encapsulation. It also contains a BFD Discriminator 312 Attribute [ietf-bess-mvpn-fast-failover]. The BFD discriminator 313 advertised by a tail in the inclusive multicast route MUST be used in 314 any reverse unicast traffic so the head can determine which tail is 315 responding. If configured to do so, once a PE knows an inclusive 316 multicast route, it brings UP and maintains a BFD session to the 317 tails. The session is brought down if no such route is available due 318 to their withdrawal. 320 For MPLS encapsulation of the head to tails BFD, Label Switched 321 Multicast is used. For VXLAN encapsulation, BFD is delivered to the 322 tails through underlay multicast using an outer multicast IP address. 324 Internet-Draft Fault Management for EVPN 326 6. BFD Packet Encapsulation 328 The sections below describe the MPLS and VXLAN encapsulations of BFD 329 for EVPN OAM use. 331 6.1 MPLS Encapsulation 333 This section describes use of the Generic Associated Channel Label 334 (GAL) for BFD encapsulation in MPLS based EVPN OAM. 336 6.1.1 MPLS Unicast 338 As shown in Figure 1, the packet initially contains the following 339 labels: LSP label (transport), the optional entropy label, the EVPN 340 Unicast label, and then the Generic Associated Channel label with the 341 G-ACh type set to TBD1. The G-ACh payload of the packet MUST contain 342 the destination L2 header (in overlay space) followed by the IP 343 header that encapsulates the BFD packet. The MAC address of the 344 inner packet is used to validate the in the receiving 345 node. 347 - The destination MAC MUST be the dedicated MAC TBD-A (see Section 348 8) or the MAC address of the destination PE. 349 - The destination IP address MUST be 127.0.0.1/32 for IPv4 350 [RFC1812] or ::1/128 for IPv6 [RFC4291]. 351 - The destination IP port MUST be 3784 [RFC5881]. 352 - The source IP port MUST be in the range 49152 through 65535. 353 - The discriminator values for BFD are obtained through BGP as 354 discussed in Section 4 or are exchanged out-of-band or through 355 some other means outside the scope of this document. 357 Internet-Draft Fault Management for EVPN 359 <---------- 4 bytes ----------> 360 +-------------------------------+ ----- 361 | LSP Label | | 362 +-------------------------------+ | 363 : entropy label indicator : | 364 + (optional) + MPLS Label Stack 365 : entropy label : | 366 +-------------------------------+ | 367 | EVPN Unicast label | 368 +-------------------------------+ | 369 | Generic Assoc. Channel Label | | 370 +-------------------------------+ ----- 371 | ACH word, Type TBD1 no TLVs | 372 +-------------------------------+ --- ------- 373 | Destination MAC Address | | | 374 + +---------------+ | | 375 | TBD-A | | | | 376 +---------------+ + L2 Header | 377 | Source MAC Address | | | 378 +---------------+---------------+ | | 379 | VLAN Ethertype| VLAN-ID | | | 380 +---------------+---------------+ | | 381 |IP4/6 Ethertype| | | 382 +---------------+---------------+ --- | 383 / / G-ACh Payload 384 /... IP4/6 Header .../ | 385 / / | 386 +-------------------------------+ | 387 | | | 388 + UDP Header + | 389 | | | 390 +-------------------------------+ | 391 | | | 392 + BFD Control Packet + | 393 / / | 394 /... .../ --------------- 396 Figure 1. MPLS Unicast Encapsulation 398 6.1.2 MPLS Ingress Replication 400 The packet initially contains the following labels: LSP label 401 (transport), the optional entropy label, the BUM label, and the split 402 horizon label [RFC7432] (where applicable). The G-ACh type is set to 403 TBD1. The G-ACh payload of the packet is as described in Section 404 6.1.1. 406 Internet-Draft Fault Management for EVPN 408 6.1.3 MPLS LSM (Label Switched Multicast, P2MP) 410 The encapsulation is the same as in Section 6.1.2 for ingress 411 replication except that the transport label identifies the P2MP 412 tunnel, in effect the set of tail PEs, rather than identifying a 413 single destination PE at the end of an MP2P tunnel. 415 6.2 VXLAN Encapsulation 417 This section describes the use of the VXLAN [RFC7348] for BFD 418 encapsulation in VXLAN based EVPN OAM. This specification conforms to 419 [ietf-bfd-vxlan]. [Some or all of this section may be removed as 420 being redundant with [ietf-bfd-vxlan].] 422 6.2.1 VXLAN Unicast 424 Figure 2 below shows the unicast VXLAN encapsulation. The outer and 425 inner IP headers have a unicast source IP address of the BFD message 426 source and a destination IP address of the BFD message destination 428 The destination UDP port MUST be 3784 [RFC5881]. The source port MUST 429 be in the range 49152 through 65535. If the BFD source has multiple 430 IP addresses, entropy MAY be further obtained by using any of those 431 addresses assuming the source is prepared for responses directed to 432 the IP address used. 434 The Your BFD discriminator is the value distributed for this unicast 435 OAM purpose by the destination using BGP as discussed in Section 4 or 436 is exchanged out-of-band or through some other means outside the 437 scope of this document. 439 Internet-Draft Fault Management for EVPN 441 <---------- 4 bytes ----------> 442 +-------------------------------+ --- 443 | Destination MAC Address | | 444 + +---------------+ | 445 | | | | 446 +---------------+ + L2 Header 447 | Source MAC Address | | 448 +-------------------------------+ | 449 | VLAN Tag | | 450 +---------------+---------------+ | 451 |IP4/6 Ethertype| | 452 +---------------+---------------+ --- 453 / / 454 /... IP4/6 Header .../ 455 / / 456 +-------------------------------+ 457 | | 458 + UDP Header + 459 | | 460 +-------------------------------+ 461 | | 462 + VXLAN Header + 463 | | 464 +-------------------------------+ --- 465 | Destination MAC Address | | 466 + +---------------+ | 467 | | | | 468 +---------------+ + L2 Header 469 | Source MAC Address | | 470 +---------------+---------------+ | 471 | IP4 Ethertype | | 472 +---------------+---------------+ --- 473 / / 474 /... IP4 Header .../ 475 / / 476 +-------------------------------+ 477 | | 478 + UDP Header + 479 | | 480 +---------------+---------------+ 481 | | 482 + BFD Control Packet + 483 | | 484 /... .../ 486 Figure 2. VXLAN Unicast Encapsulation 488 Internet-Draft Fault Management for EVPN 490 6.2.2 VXLAN Ingress Replication 492 The BFD packet construction is as given in Section 6.2.1 except as 493 follows: 494 (1) The destination IP address used by the BFD message source is that 495 advertised by the destination PE in its Inclusive Multicast EVPN 496 route for the MP2P tunnel in question; and 497 (2) The Your BFD discriminator used is the one advertised by the BFD 498 destination using BGP as discussed in Section 5.1 for the MP2P 499 tunnel in question or is exchanged out-of-band or through some 500 other means outside the scope of this document. 502 6.2.3 VXLAN LSM (Label Switched Multicast, P2MP) 504 The VXLAN encapsulation for the head-to-tails BFD packets uses the 505 multicast destination IP corresponding to the VXLAN VNI. 507 The destination port MUST be 3784. For entropy purposes, the source 508 port can vary but MUST be in the range 49152 through 65535 [RFC5881]. 509 If the head PE has multiple IP addresses, entropy MAY be further 510 obtained by using any of those addresses. 512 The Your BFD discriminator is the value distributed for this 513 multicast OAM purpose by the BFD message using BGP as discussed in 514 Section 5.2 or is exchanged out-of-band or through some other means 515 outside the scope of this document. 517 Internet-Draft Fault Management for EVPN 519 7. Scalability Considerations 521 The mechanisms proposed by this draft could affect the packet load on 522 the network and its elements especially when supporting 523 configurations involving a large number of EVIs. The option of 524 slowing down or speeding up BFD timer values can be used by an 525 administrator or a network management entity to maintain the overhead 526 incurred due to fault monitoring at an acceptable level. 528 Internet-Draft Fault Management for EVPN 530 8. IANA Considerations 532 The following IANA Actions are requested. 534 8.1 Pseudowire Associated Channel Type 536 IANA is requested to assign a channel type from the "Pseudowire 537 Associated Channel Types" registry in [RFC4385] as follows. 539 Value Description Reference 540 ----- ------------ ------------ 541 TBD1 BFD-EVPN OAM [this document] 543 8.2 MAC Address 545 IANA is requested to assign a multicast MAC address under the IANA 546 OUI [0x01005E900004 suggested] as follows: 548 Address Usage Reference 549 ------- -------- --------------- 550 TBD-A EVPN OAM [this document] 552 Internet-Draft Fault Management for EVPN 554 9. Security Considerations 556 Security considerations discussed in [RFC5880], [RFC5883], and 557 [RFC8029] apply. 559 MPLS security considerations [RFC5920] apply to BFD Control packets 560 encapsulated in a MPLS label stack. When BPD Control packets are 561 routed, the authentication considerations discussed in [RFC5883] 562 should be followed. 564 VXLAN BFD security considerations in [ietf-vxlan-bfd] apply to BFD 565 packets encapsulate in VXLAN. 567 Acknowledgements 569 The authors wish to thank the following for their comments and 570 suggestions: 572 Mach Chen 574 Internet-Draft Fault Management for EVPN 576 Normative References 578 [ietf-bess-evpn-inter-subnet-forwarding] Sajassi, A., Salam, S., 579 Thoria, S., Rekhter, Y., Drake, J., Yong, L., and L. 580 Dunbar, "Integrated Routing and Bridging in EVPN", 581 draft-ietf-bess-evpn-inter-subnet-forwarding-08, work in 582 progress, March 2019. 584 [ietf-bess-mvpn-fast-failover] Morin, T., Kebler, R., Mirsky, G., 585 "Multicast VPN fast upstream failover", 586 draft-ietf-bess-mvpn-fast-failover-05 (work in progress), 587 February 2019. 589 [ietf-bfd-vxlan] Pallagatti, S., Paragiri, S., Govindan, V., 590 Mudigonda, M., G. Mirsky, "BFD for VXLAN", 591 draft-ietf-bfd-vxlan (work in progress), October 2020. 593 [mirsky-mpls-p2mp-bfd] G. Mirsky, S. Mishra, "BFD for Multipoint 594 Networks over Point-to-Multi-Point MPLS LSP", draft-mirsky- 595 mpls-p2mp-bfd (work in progress), October 2020. 597 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 598 RFC 1812, DOI 10.17487/RFC1812, June 1995, 599 . 601 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 602 Requirement Levels", BCP 14, RFC 2119, DOI 603 10.17487/RFC2119, March 1997, . 606 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 607 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 608 2006, . 610 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 611 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 612 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 613 February 2006, . 615 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 616 "MPLS Generic Associated Channel", RFC 5586, DOI 617 10.17487/RFC5586, June 2009, . 620 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 621 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 622 . 624 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 625 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 627 Internet-Draft Fault Management for EVPN 629 10.17487/RFC5881, June 2010, . 632 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 633 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 634 June 2010, . 636 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 637 "Bidirectional Forwarding Detection (BFD) for MPLS Label 638 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 639 June 2010, . 641 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. 642 Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 643 6790, DOI 10.17487/RFC6790, November 2012, . 646 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 647 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 648 eXtensible Local Area Network (VXLAN): A Framework for 649 Overlaying Virtualized Layer 2 Networks over Layer 3 650 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 651 . 653 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 654 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 655 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 656 2015, . 658 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 659 Henderickx, "Provider Backbone Bridging Combined with 660 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 661 September 2015, . 663 [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. 664 Aldrin, "Clarifying Procedures for Establishing BFD 665 Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, 666 DOI 10.17487/RFC7726, January 2016, . 669 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 670 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 671 Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 672 10.17487/RFC8029, March 2017, . 675 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 676 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 677 2017, . 679 Internet-Draft Fault Management for EVPN 681 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 682 Uttaro, J., and W. Henderickx, "A Network Virtualization 683 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 684 10.17487/RFC8365, March 2018, . 687 [RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 688 Ed., "Bidirectional Forwarding Detection (BFD) Multipoint 689 Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019, 690 . 692 Informative References 694 [ietf-bess-evpn-oam-req-frmwk] Salam, S., Sajassi, A., Aldrin, S., J. 695 Drake, and D. Eastlake, "EVPN Operations, Administration 696 and Maintenance Requirements and Framework", 697 draft-ietf-bess-evpn-oam-req-frmwk-00, work in progress, 698 February 2019. 700 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 701 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 702 . 704 Internet-Draft Fault Management for EVPN 706 Authors' Addresses 708 Vengada Prasad Govindan 709 Cisco Systems 711 Email: venggovi@cisco.com 713 Mudigonda Mallik 714 Cisco Systems 716 Email: mmudigon@cisco.com 718 Ali Sajassi 719 Cisco Systems 720 170 West Tasman Drive 721 San Jose, CA 95134, USA 723 Email: sajassi@cisco.com 725 Gregory Mirsky 726 ZTE Corp. 728 Email: gregimirsky@gmail.com 730 Donald Eastlake, 3rd 731 Futurewei Technologies 732 2386 Panoramic Circle 733 Apopka, FL 32703 USA 735 Phone: +1-508-333-2270 736 Email: d3e3e3@gmail.com 738 Internet-Draft Fault Management for EVPN 740 Copyright, Disclaimer, and Additional IPR Provisions 742 Copyright (c) 2020 IETF Trust and the persons identified as the 743 document authors. All rights reserved. 745 This document is subject to BCP 78 and the IETF Trust's Legal 746 Provisions Relating to IETF Documents 747 (http://trustee.ietf.org/license-info) in effect on the date of 748 publication of this document. Please review these documents 749 carefully, as they describe your rights and restrictions with respect 750 to this document. Code Components extracted from this document must 751 include Simplified BSD License text as described in Section 4.e of 752 the Trust Legal Provisions and are provided without warranty as 753 described in the Simplified BSD License.