idnits 2.17.00 (12 Aug 2021) /tmp/idnits21263/draft-ietf-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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2021) is 446 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: August 21, 2021 February 22, 2021 11 EVPN Network Layer Fault Management 12 draft-ietf-bess-evpn-bfd-03 14 Abstract 16 This document specifies proactive, in-band network layer OAM 17 mechanisms to detect loss of continuity and miss-connection faults 18 that affect unicast and multi-destination paths (used by Broadcast, 19 Unknown Unicast, and Multicast traffic) in an Ethernet VPN (EVPN) 20 network. The mechanisms specified in the draft are based on the 21 widely adopted 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 EVPN Network Layer Fault Management 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 Unicast MPLS Encapsulation..........................10 64 6.1.2 MPLS Ingress Replication (MP2P).....................11 65 6.1.3 MPLS LSM (Label Switched Multicast, P2MP)...........12 66 6.2 VXLAN Encapsulation...................................12 67 6.2.1 Unicast VXLAN Encapsulation.........................12 68 6.2.2 VXLAN Ingress Replication (MP2P)....................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 Addresses.........................................16 76 8.3 BFD Discriminator Attribute Type......................16 78 9. Security Considerations................................17 80 Acknowledgements..........................................17 82 Normative References......................................18 83 Informative References....................................20 85 Authors' Addresses........................................21 87 Internet-Draft EVPN Network Layer Fault Management 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 somewhat different fault 101 detection mechanisms depending on the type of traffic and the type of 102 tunnel used as follows: 103 o Using BFD [RFC5880] for unicast traffic and BUM traffic via 104 MP2P tunnels. 105 o Using BFD Multipoint Active Tails [RFC8563] [mirsky-mpls-p2mp- 106 bfd] for BUM traffic via a P2MP tunnel. 108 Packet loss and packet delay measurement are out of scope for this 109 document. 111 1.1 Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in BCP 116 14 [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 The following acronyms are used in this document. 121 BFD - Bidirectional Forwarding Detection [RFC5880] 123 BUM - Broadcast, Unknown Unicast, and Multicast 125 CC - Continuity Check 127 CV - Connectivity Verification 129 EVI - EVPN Instance 131 EVPN - Ethernet VPN [RFC7432] 133 FEC - Forwarding Equivalency Class 135 GAL - Generic Associated Channel Label [RFC5586] 137 Internet-Draft EVPN Network Layer Fault Management 139 LSM - Label Switched Multicast (P2MP) 141 LSP - Label Switched Path 143 MP2MP - Multi-Point-to-Multi-Point 145 MP2P - Multi-Point-to-Point 147 OAM - Operations, Administration, and Maintenance 149 P2MP - Point-to-Multi-Point (LSM) 151 P2P - Point to Point. 153 PE - Provider Edge 155 VXLAN - Virtual eXtensible Local Area Network (VXLAN) [RFC7348] 157 Internet-Draft EVPN Network Layer Fault Management 159 2. Scope of this Document 161 This document specifies BFD based mechanisms for proactive fault 162 detection for EVPN as specified in [RFC7432] and also for EVPN using 163 VXLAN encapsulation [RFC8365]. It covers the following: 165 o Unicast traffic using Point-to-Point (P2P) and Multi-Point-to- 166 Point (MP2P) tunnels. 168 o BUM traffic using Multi-Point-to-Point (MP2P) tunnels (ingress 169 replication). 171 o BUM traffic using Point-to-Multi-Point (P2MP) tunnels (Label 172 Switched Multicast (LSM)). 174 o MPLS and VXLAN encapsulation. 176 This document does not discuss BFD mechanisms for: 178 o EVPN variants like PBB-EVPN [RFC7623]. It is intended to 179 address this in future versions. 181 o Integrated Routing and Bridging (IRB) solution based on EVPN 182 [ietf-bess-evpn-inter-subnet-forwarding]. It is intended to 183 address this in future versions. 185 o EVPN using other encapsulations such as NVGRE or MPLS over GRE 186 [RFC8365]. 188 o BUM traffic using MP2MP tunnels. 190 This document specifies procedures for BFD asynchronous mode. BFD 191 demand mode is outside the scope of this specification except as it 192 is used in [RFC8563]. The use of the Echo function is outside the 193 scope of this specification. 195 Internet-Draft EVPN Network Layer Fault Management 197 3. Motivation for Running BFD at the EVPN Network Layer 199 The choice of running BFD at the network layer of the OAM model for 200 EVPN [ietf-bess-evpn-oam-req-frmwk] was made after considering the 201 following: 203 o In addition to detecting link failures in the EVPN network, BFD 204 sessions at the network layer can be used to monitor the 205 successful setup, such as label programming, of MP2P and P2MP EVPN 206 tunnels transporting Unicast and BUM traffic. The scope of 207 reachability detection covers the ingress and the egress EVPN PE 208 (Provider Edge) nodes and the network connecting them. 210 o Monitoring a representative set of path(s) or a particular path 211 among multiple paths available between two EVPN PE nodes could be 212 done by exercising entropy mechanisms such as entropy labels, when 213 they are used, or VXLAN source ports. However, paths that cannot 214 be realized by entropy variations cannot be monitored. The fault 215 monitoring requirements outlined by [ietf-bess-evpn-oam-req-frmwk] 216 are addressed by the mechanisms proposed by this draft. 218 BFD testing between EVPN PE nodes does not guarantee that the EVPN 219 service is functioning. (This can be monitored at the service level, 220 that is CE to CE.) For example, an egress EVPN-PE could understand 221 EVPN labeling received but could switch data to an incorrect 222 interface. However, BFD testing in the EVPN Network Layer does 223 provide additional confidence that data transported using those 224 tunnels will reach the expected egress node. When BFD testing in the 225 EVPN overlay fails, that can be used as an indication of a Loss-of- 226 Connectivity defect in the EVPN underlay that would cause EVPN 227 service failure. 229 Internet-Draft EVPN Network Layer Fault Management 231 4. Fault Detection for Unicast Traffic 233 The mechanisms specified in BFD for MPLS LSPs [RFC5884] [RFC7726] 234 are, except as otherwise provided herein, applied to test the 235 handling of unicast EVPN traffic. When discriminators are required 236 for de-multiplexing the BFD sessions, they can be advertised through 237 BGP using the BFD Discriminator Attribute [ietf-bess-mvpn-fast- 238 failover]. Discriminators are needed for MPLS since the label stack 239 does not contain enough information to identify the sender of the 240 packet. 242 The usage of MPLS entropy labels or various VXLAN source ports takes 243 care of the requirement to monitor various paths of the multi-path 244 server layer network [RFC6790]. Each unique realizable path between 245 the participating PE routers MAY be monitored separately when such 246 entropy is used. At least one path of multi-path connectivity 247 between two PE routers MUST be tracked with BFD, but in that case the 248 granularity of fault-detection will be coarser. 250 To support unicast fault management to a PE node, that PE MUST 251 allocate or be configured with a BFD discriminator to be used for the 252 BFD messages to it. By default, it advertises this discriminator with 253 BGP using the BFD Discriminator Attribute [ietf-bess-mvpn-fast- 254 failover] with BFD Mode TBD4 in an EVPN MAC/IP Advertisement Route 255 [RFC7432] and extracts its peer's discriminator from such an 256 attribute. however, these discriminators MAY be exchanged out-of-band 257 or through some other mechanism outside the scope of this document. 259 If configured to do so, once a PE knows a unicast route and 260 discriminator for another PE, it endeavors to bring UP and maintain a 261 BFD session to that other PE. Once the BFD session is UP, the ends of 262 the BFD session MUST NOT change the local discriminator values of the 263 BFD Control packets they generate, unless they first bring down the 264 session as specified in [RFC5884]. The BFD session is brought down 265 if a PE is no longer configured to maintain it or if a route and 266 discriminator are no longer available. 268 Internet-Draft EVPN Network Layer Fault Management 270 5. Fault Detection for BUM Traffic 272 Section 5.1 below discusses BUM traffic fault detection for MP2P 273 tunnels using ingress replication and Section 5.2 discusses such 274 fault detection for P2MP tunnels. 276 5.1 Ingress Replication 278 Ingress replication uses separate MP2P tunnels for transporting BUM 279 traffic from the ingress PE (head) to a set of one or more egress PEs 280 (tails). The fault detection mechanism specified by this document 281 takes advantage of the fact that the head makes a unique copy for 282 each tail. 284 Another key aspect to be considered in EVPN is the advertisement of 285 the Inclusive Multicast Ethernet Tag Route [RFC7432]. The BUM 286 traffic flows from a head node to a particular tail only after the 287 head receives such inclusive multicast route from the tail. This 288 route contains the BUM EVPN MPLS label (downstream allocated) 289 corresponding to the MP2P tunnel for MPLS encapsulation and contains 290 the IP address of the PE originating the inclusive multicast route 291 for use in VXLAN encapsulation. It also contains a BFD Discriminator 292 Attribute [ietf-bess-mvpn-fast-failover] with BFD Mode TDB4 giving 293 the BFD discriminator that will be used by the tail. This is the P2P 294 mode since a P2P BFD session is used in the MP2P case. 296 There MAY exist multiple BFD sessions between a head PE and an 297 individual tail due to (1) the usage of MPLS entropy labels [RFC6790] 298 or VXLAN source ports for an inclusive multicast FEC and (2) due to 299 multiple MP2P tunnels indicated by different tail labels or IP 300 addresses for MPLS or VXLAN. If configured to do so, once a PE knows 301 a multicast route and discriminator for another PE it endeavors to 302 bring UP and maintain a BFD session to that other PE. Once a BFD 303 session for a path is UP, the ends of the BFD session MUST NOT change 304 the local discriminator values of the BFD Control packets they 305 generate, unless they first bring down the session as specified in 306 [RFC5884]. The BFD session is brought down if a PE is no longer 307 configured to maintain it or if a route and discriminator are no 308 longer available. 310 5.2 P2MP Tunnels (Label Switched Multicast) 312 Fault detection for BUM traffic distributed using a P2MP tunnel uses 313 BFD Multipoint Active Tails in one of the three methods providing 314 head notification depending on configuration. Sections 5.2.2 and 315 5.2.3 of [RFC8563] describe two of these methods ("Head Notification 317 Internet-Draft EVPN Network Layer Fault Management 319 and Tail Solicitation with Multipoint Polling" and "Head Notification 320 with Composite Polling"). The third method ("Head Notification 321 without Polling") is touched on in Section 5.2.1 of [RFC8563] and 322 fully specified in [mirsky-mpls-p2mp-bfd]. All three of these modes 323 assume the existence of a unicast path from each tail to the head. In 324 addition, Head Notification with Composite Polling assumes a head to 325 tail unicast path. 327 The BUM traffic flows from a head node to the tails after the head 328 receives an Inclusive Multicast Tag Route [RFC7432]. This contains 329 the BUM EVPN MPLS label (upstream allocated) corresponding to the 330 P2MP tunnel for MPLS encapsulation. It also contains a BFD 331 Discriminator Attribute [ietf-bess-mvpn-fast-failover] with BFD Mode 332 1 and with a Source IP Address TLV giving the address associated with 333 the MultiPoint Head of the P2MP session. This BFD discriminator 334 advertised by a tail in the inclusive multicast route or otherwise 335 configured at or communicated to the head MUST be used in any reverse 336 unicast traffic so the head can determine which tail is responding. 337 If configured to do so, once a PE knows a P2MP multicast route and 338 needed discriminators, it brings UP and maintains a BFD active tails 339 session to the tails. The BFD session is brought down if a PE is no 340 longer configured to maintain it or if the multicast route and 341 discriminators are no longer available. 343 For MPLS encapsulation of the head to tails BFD, Label Switched 344 Multicast is used. For VXLAN encapsulation, BFD is delivered to the 345 tails through underlay multicast using an outer multicast IP address. 347 Internet-Draft EVPN Network Layer Fault Management 349 6. BFD Packet Encapsulation 351 The sections below discuss the MPLS and VXLAN encapsulations of BFD 352 for EVPN network layer fault management. 354 6.1 MPLS Encapsulation 356 This section describes use of the Generic Associated Channel Label 357 (GAL) for BFD encapsulation in MPLS based EVPN network layer fault 358 management. 360 6.1.1 Unicast MPLS Encapsulation 362 As shown in Figure 1, the packet initially contains the following 363 labels: LSP label (transport), the optional entropy label, the EVPN 364 Unicast label, and then the Generic Associated Channel label with the 365 G-ACh type set to TBD1. The G-ACh payload of the packet MUST contain 366 the destination L2 header (in overlay space) followed by the IP 367 header that encapsulates the BFD packet. The MAC address of the 368 inner packet is used to validate the in the receiving 369 node. 371 - The destination MAC MUST be the dedicated unicast MAC TBD3 (see 372 Section 8) or the MAC address of the destination PE. 373 - The destination IP address MUST be 127.0.0.1/32 for IPv4 374 [RFC1812] or ::1/128 for IPv6 [RFC4291]. 375 - The destination IP port MUST be 3784 [RFC5881]. 376 - The source IP port MUST be in the range 49152 through 65535. 377 - The discriminator values for BFD are obtained through BGP as 378 discussed in Section 4. 380 Internet-Draft EVPN Network Layer Fault Management 382 <---------- 4 bytes ----------> 383 +-------------------------------+ ----- 384 | LSP Label | | 385 +-------------------------------+ | 386 : entropy label indicator : | 387 + (optional) + MPLS Label Stack 388 : entropy label : | 389 +-------------------------------+ | 390 | EVPN Unicast label | 391 +-------------------------------+ | 392 | Generic Assoc. Channel Label | | 393 +-------------------------------+ ----- 394 | ACH word, Type TBD1 no TLVs | 395 +-------------------------------+ --- ------- 396 | Destination MAC Address | | | 397 + +---------------+ | | 398 | TBD2 | | | | 399 +---------------+ + L2 Header | 400 | Source MAC Address | | | 401 +---------------+---------------+ | | 402 | VLAN Ethertype| VLAN-ID | | | 403 +---------------+---------------+ | | 404 |IP4/6 Ethertype| | | 405 +---------------+---------------+ --- | 406 / / G-ACh Payload 407 /... IPv4/6 Header .../ | 408 / / | 409 +-------------------------------+ | 410 | | | 411 + UDP Header + | 412 | | | 413 +-------------------------------+ | 414 | | | 415 + BFD Control Packet + | 416 / / | 417 /... .../ --------------- 419 Figure 1. MPLS Unicast Encapsulation 421 6.1.2 MPLS Ingress Replication (MP2P) 423 The packet initially contains the following labels: LSP label 424 (transport), the optional entropy label, the BUM label, and the split 425 horizon label [RFC7432] (where applicable). The G-ACh type is set to 426 TBD1. The G-ACh payload of the packet is as described in Section 427 6.1.1 except that the destination MAC address is the dedicated 428 multicast MAC TBD2. 430 Internet-Draft EVPN Network Layer Fault Management 432 6.1.3 MPLS LSM (Label Switched Multicast, P2MP) 434 The encapsulation is the same as in Section 6.1.2 for ingress 435 replication except that the transport label identifies the P2MP 436 tunnel, in effect the set of tail PEs, rather than identifying a 437 single destination PE at the end of an MP2P tunnel. 439 6.2 VXLAN Encapsulation 441 This section describes the use of the VXLAN [RFC7348] [RFC8365] for 442 BFD encapsulation in VXLAN based EVPN fault management. 444 6.2.1 Unicast VXLAN Encapsulation 446 Figure 2 below shows the unicast VXLAN encapsulation. The outer and 447 inner IP headers have a unicast source IP address of the BFD message 448 source and a destination IP address of the BFD message destination 450 The destination UDP port MUST be 3784 [RFC5881]. The source port MUST 451 be in the range 49152 through 65535. If the BFD source has multiple 452 IP addresses, entropy MAY be further obtained by using any of those 453 addresses assuming the source is prepared for responses directed to 454 the IP address used. 456 Internet-Draft EVPN Network Layer Fault Management 458 <---------- 4 bytes ----------> 459 +-------------------------------+ --- 460 | Destination MAC Address | | 461 + +---------------+ | 462 | | | | 463 +---------------+ + L2 Header 464 | Source MAC Address | | 465 +-------------------------------+ | 466 | VLAN Ethertype| VLAN-ID | | 467 +---------------+---------------+ | 468 |IP4/6 Ethertype| | 469 +---------------+---------------+ --- 470 / / 471 /... IP4/6 Header .../ 472 / / 473 +-------------------------------+ 474 | | 475 + UDP Header + 476 | | 477 +-------------------------------+ 478 | | 479 + VXLAN Header + 480 | | 481 +-------------------------------+ --- 482 | Destination MAC Address | | 483 + +---------------+ | 484 | | | | 485 +---------------+ + L2 Header 486 | Source MAC Address | | 487 +---------------+---------------+ | 488 | IP4 Ethertype | | 489 +---------------+---------------+ --- 490 / / 491 /... IP4 Header .../ 492 / / 493 +-------------------------------+ 494 | | 495 + UDP Header + 496 | | 497 +---------------+---------------+ 498 | | 499 + BFD Control Packet + 500 | | 501 /... .../ 503 Figure 2. VXLAN Unicast Encapsulation 505 Internet-Draft EVPN Network Layer Fault Management 507 6.2.2 VXLAN Ingress Replication (MP2P) 509 The BFD packet construction is as given in Section 6.2.1 except as 510 follows: 512 (1) The destination IP address used by the BFD message source is that 513 advertised by the destination PE in its Inclusive Multicast EVPN 514 route for the MP2P tunnel in question; and 516 (2) The Your BFD discriminator used is the one advertised by the BFD 517 destination using BGP as discussed in Section 5.1 for the MP2P 518 tunnel. 520 6.2.3 VXLAN P2MP 522 The VXLAN encapsulation for the head-to-tails BFD packets uses the 523 multicast destination IP corresponding to the VXLAN VNI. 525 The destination port MUST be 3784. For entropy purposes, the source 526 port can vary but MUST be in the range 49152 through 65535 [RFC5881]. 527 If the head PE has multiple IP addresses, entropy MAY be further 528 obtained by using any of those addresses. 530 The Your BFD discriminator is the value distributed for this 531 multicast fault management purpose as discussed in Section 5.2. 533 Internet-Draft EVPN Network Layer Fault Management 535 7. Scalability Considerations 537 The mechanisms proposed by this draft could affect the packet load on 538 the network and its elements especially when supporting 539 configurations involving a large number of EVIs. The option of 540 slowing down or speeding up BFD timer values can be used by an 541 administrator or a network management entity to maintain the overhead 542 incurred due to fault monitoring at an acceptable level. 544 Internet-Draft EVPN Network Layer Fault Management 546 8. IANA Considerations 548 The following IANA Actions are requested. 550 8.1 Pseudowire Associated Channel Type 552 IANA is requested to assign a channel type from the "Pseudowire 553 Associated Channel Types" registry in [RFC4385] as follows. 555 Value Description Reference 556 ----- ------------ ------------ 557 TBD1 BFD-EVPN OAM [this document] 559 8.2 MAC Addresses 561 IANA is requested to assign parallel multicast and unicast MAC 562 addresses under the IANA OUI [0x01005E900101 and 0x00005E900101 563 suggested] as follows: 565 IANA Multicast 48-bit MAC Addresses 566 Address Usage Reference 567 ------- --------------------- --------------- 568 TBD2 EVPN Network Layer OAM [this document] 570 IANA Unicast 48-bit MAC Addresses 571 Address Usage Reference 572 ------- --------------------- --------------- 573 TBD3 EVPN Network Layer OAM [this document] 575 8.3 BFD Discriminator Attribute Type 577 IANA is requested to assign a value from the IETF Review range in the 578 BFD Mode sub-registry on the Border Gateway Protocol Parameters 579 Registry web page as follows: 581 Value Description Reference 582 ----- --------------- --------------- 583 TBD4 P2P BFD Session [this document] 585 Internet-Draft EVPN Network Layer Fault Management 587 9. Security Considerations 589 Security considerations discussed in [RFC5880], [RFC5883], and 590 [RFC8029] apply. 592 MPLS security considerations [RFC5920] apply to BFD Control packets 593 encapsulated in a MPLS label stack. When BPD Control packets are 594 routed, the authentication considerations discussed in [RFC5883] 595 should be followed. 597 VXLAN BFD security considerations in [RFC8971] apply to BFD packets 598 encapsulate in VXLAN. 600 Acknowledgements 602 The authors wish to thank the following for their comments and 603 suggestions: 605 Mach Chen 607 Internet-Draft EVPN Network Layer Fault Management 609 Normative References 611 [ietf-bess-mvpn-fast-failover] Morin, T., Kebler, R., Mirsky, G., 612 "Multicast VPN fast upstream failover", 613 draft-ietf-bess-mvpn-fast-failover (in RFC Editor's queue), 614 February 2019. 616 [mirsky-mpls-p2mp-bfd] G. Mirsky, S. Mishra, "BFD for Multipoint 617 Networks over Point-to-Multi-Point MPLS LSP", draft-mirsky- 618 mpls-p2mp-bfd (work in progress), November 2020. 620 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 621 RFC 1812, DOI 10.17487/RFC1812, June 1995, 622 . 624 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 625 Requirement Levels", BCP 14, RFC 2119, DOI 626 10.17487/RFC2119, March 1997, . 629 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 630 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 631 2006, . 633 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 634 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 635 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 636 February 2006, . 638 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 639 "MPLS Generic Associated Channel", RFC 5586, DOI 640 10.17487/RFC5586, June 2009, . 643 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 644 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 645 . 647 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 648 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 649 10.17487/RFC5881, June 2010, . 652 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 653 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 654 June 2010, . 656 Internet-Draft EVPN Network Layer Fault Management 658 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 659 "Bidirectional Forwarding Detection (BFD) for MPLS Label 660 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 661 June 2010, . 663 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. 664 Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 665 6790, DOI 10.17487/RFC6790, November 2012, . 668 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 669 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 670 eXtensible Local Area Network (VXLAN): A Framework for 671 Overlaying Virtualized Layer 2 Networks over Layer 3 672 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 673 . 675 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 676 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 677 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 678 2015, . 680 [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. 681 Aldrin, "Clarifying Procedures for Establishing BFD 682 Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, 683 DOI 10.17487/RFC7726, January 2016, . 686 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 687 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 688 Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 689 10.17487/RFC8029, March 2017, . 692 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 693 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 694 2017, . 696 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 697 Uttaro, J., and W. Henderickx, "A Network Virtualization 698 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 699 10.17487/RFC8365, March 2018, . 702 [RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 703 Ed., "Bidirectional Forwarding Detection (BFD) Multipoint 704 Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019, 705 . 707 Internet-Draft EVPN Network Layer Fault Management 709 Informative References 711 [ietf-bess-evpn-inter-subnet-forwarding] Sajassi, A., Salam, S., 712 Thoria, S., Rekhter, Y., Drake, J., Yong, L., and L. 713 Dunbar, "Integrated Routing and Bridging in EVPN", 714 draft-ietf-bess-evpn-inter-subnet-forwarding-13 (work in 715 progress), February 2021. 717 [ietf-bess-evpn-oam-req-frmwk] Salam, S., Sajassi, A., Aldrin, S., J. 718 Drake, and D. Eastlake, "EVPN Operations, Administration 719 and Maintenance Requirements and Framework", 720 draft-ietf-bess-evpn-oam-req-frmwk-04, work in progress, 721 July 2019. 723 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 724 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 725 . 727 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 728 Henderickx, "Provider Backbone Bridging Combined with 729 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 730 September 2015, . 732 [RFC8971] Pallagatti, S., Ed., Mirsky, G., Ed., Paragiri, S., 733 Govindan, V., and M. Mudigonda, "Bidirectional Forwarding 734 Detection (BFD) for Virtual eXtensible Local Area Network 735 (VXLAN)", RFC 8971, DOI 10.17487/RFC8971, December 2020, 736 . 738 Internet-Draft EVPN Network Layer Fault Management 740 Authors' Addresses 742 Vengada Prasad Govindan 743 Cisco Systems 745 Email: venggovi@cisco.com 747 Mudigonda Mallik 748 Cisco Systems 750 Email: mmudigon@cisco.com 752 Ali Sajassi 753 Cisco Systems 754 170 West Tasman Drive 755 San Jose, CA 95134, USA 757 Email: sajassi@cisco.com 759 Gregory Mirsky 760 ZTE Corp. 762 Email: gregimirsky@gmail.com 764 Donald Eastlake, 3rd 765 Futurewei Technologies 766 2386 Panoramic Circle 767 Apopka, FL 32703 USA 769 Phone: +1-508-333-2270 770 Email: d3e3e3@gmail.com 772 Internet-Draft EVPN Network Layer Fault Management 774 Copyright, Disclaimer, and Additional IPR Provisions 776 Copyright (c) 2021 IETF Trust and the persons identified as the 777 document authors. All rights reserved. 779 This document is subject to BCP 78 and the IETF Trust's Legal 780 Provisions Relating to IETF Documents 781 (http://trustee.ietf.org/license-info) in effect on the date of 782 publication of this document. Please review these documents 783 carefully, as they describe your rights and restrictions with respect 784 to this document. Code Components extracted from this document must 785 include Simplified BSD License text as described in Section 4.e of 786 the Trust Legal Provisions and are provided without warranty as 787 described in the Simplified BSD License.