idnits 2.17.1 draft-burdet-bess-evpn-fast-reroute-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 10. The solution MUST not rely on pushing an additional label onto the label stack. -- The document date (October 25, 2021) is 914 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) == Outdated reference: A later version (-08) exists of draft-ietf-bess-evpn-fast-df-recovery-02 == Outdated reference: A later version (-08) exists of draft-ietf-bess-rfc7432bis-01 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group LA. Burdet, Ed. 3 Internet-Draft P. Brissette 4 Intended status: Standards Track Cisco 5 Expires: April 28, 2022 T. Miyasaka 6 KDDI Corporation 7 October 25, 2021 9 EVPN Fast Reroute 10 draft-burdet-bess-evpn-fast-reroute-00 12 Abstract 14 This document summarises EVPN convergence mechanisms and specifies 15 procedures for EVPN networks to achieve sub-second and 16 scale-independant convergence. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 28, 2022. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 5.1. Pre-selection of Backup Path . . . . . . . . . . . . . . 6 58 5.2. Failure Detection and Traffic Restoration . . . . . . . . 6 59 5.2.1. Simultaneous Failures in ES . . . . . . . . . . . . . 7 60 5.2.2. Successive and Cascading Failures in ES . . . . . . . 8 61 6. Redirect Labels: Forwarding Attributes . . . . . . . . . . . 8 62 6.1. Bypassing DF-Election Attribute . . . . . . . . . . . . . 9 63 6.2. Terminal Disposition Attribute . . . . . . . . . . . . . 9 64 6.3. Broadcast, Unknown Unicast and Multicast . . . . . . . . 10 65 7. Controlled Recovery Sequence . . . . . . . . . . . . . . . . 10 66 8. Transport Underlay . . . . . . . . . . . . . . . . . . . . . 11 67 9. BGP Extensions . . . . . . . . . . . . . . . . . . . . . . . 11 68 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 72 12.2. Informative References . . . . . . . . . . . . . . . . . 12 73 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13 74 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 EVPN convergence and failure recovery methods from different types of 80 network failures is described in [RFC7432] Section 17. Similarly for 81 EVPN-VPWS, [RFC8214] briefly evokes an egress link protection 82 mechanism at the end of Section 5. 84 The fundamentals of EVPN convergence rely on a mass-withdraw 85 technique of the Ethernet A-D per ES route to unresolve all the 86 associated forwarding paths ([RFC7432] Section 9.2.2 'Route 87 Resolution'). The mass-withdraw grouping approach results in 88 suitable EVPN convergence at lower scale, but is not sufficent to 89 meet stricter sub-second requirements. Other control-plane 90 enhancements such as route-prioritisation 91 ([I-D.ietf-bess-rfc7432bis]) help further but still provide no 92 guarantees. 94 EVPN convergence using only control-plane approaches is constrained 95 by BGP route propagation delays, routes processing times in software 96 and hardware programming. These are additionally often performed 97 sequentially and linearly given the potential large scale of EVPN 98 routes present in control plane. 100 This document presents a mechanism for fast reroute to minimise 101 packet loss in the case of a link failure using EVPN redirect labels 102 (ERLs) with special forwarding attributes. Multiple-failures where 103 loops may occur are addressed, as are cascading failures. A 104 mechanism for distributing redirect labels (ERLs) alongside EVPN 105 service labels (ESLs) is shown. 107 The main objective is to achieve sub-second convergence in EVPN 108 networks without relying on control plane actions. The procedures in 109 this document apply equally to EVPN services (EVPN [RFC7432], EVPN- 110 VPWS [RFC8214] and EVPN-IRB [RFC9135]), and all Ethernet-Segment 111 load-balancing modes. 113 2. Specification of Requirements 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 3. Terminology 121 Some of the terminology in this document is borrowed from [RFC8679] 122 for consistency across fast reroute frameworks. 124 CE: Customer Edge device, e.g., a host, router, or switch. 126 PE: Provider Edge device. 128 Ethernet Segment (ES): When a customer site (device or network) is 129 connected to one or more PEs via a set of Ethernet links, then 130 that set of links is referred to as an 'Ethernet segment'. 132 Ethernet Segment Identifier (ESI): A unique non-zero identifier that 133 identifies an Ethernet segment is called an 'Ethernet Segment 134 Identifier'. 136 Egress link: Specific Ethernet link connecting a given PE-CE, which 137 forms part of an Ethernet Segment. 139 Single-Active Redundancy Mode: When only a single PE, among all the 140 PEs attached to an Ethernet segment, is allowed to forward traffic 141 to/from that Ethernet segment for a given VLAN, then the Ethernet 142 segment is defined to be operating in Single-Active redundancy 143 mode. 145 All-Active Redundancy Mode: When all PEs attached to an Ethernet 146 segment are allowed to forward known unicast traffic to/from that 147 Ethernet segment for a given VLAN, then the Ethernet segment is 148 defined to be operating in All-Active redundancy mode. 150 DF-Election: Designated Forwarder election, as in [RFC7432] and 151 [RFC8584]. 153 DF: Designated Forwarder. 155 Backup-DF (BDF): Backup-Designated Forwarder. 157 Non-DF (NDF): Non-Designated Forwarder. 159 AC: Attachment Circuit. 161 ERL: Special-use EVPN redirect label, described in this document. 163 ESL: EVPN service label, as in [RFC7432], [RFC8214] and [RFC9135]. 165 4. Requirements 167 1. EVPN multihoming is often described as 2 peering PEs. The 168 solution MUST be generic enough to apply multiple peering PE and 169 no artificial limit imposed on the number of peering PEs. 171 2. The solution MUST apply to all EVPN load-balancing modes. 173 3. The solution MUST be robust enough to tolerate failures of the 174 same ES at multiple PEs. Simultaneous as well as cascading 175 failures on the same ES must be addressed. 177 4. The solution MUST support EVPN [RFC7432], EVPN-VPWS [RFC8214] 178 and EVPN-IRB [RFC9135] services. 180 5. The solution MUST meet stringent sub-second and often 50 181 millisecond requirements for traffic loss of EVPN services. 183 6. The solution MUST allow redirected-traffic to bypass port 184 blocking states resulting from DF-Election (BDF or NDF). 186 7. The solution MUST be scale-independant and agnostic of EVPN 187 route types, scale or choice of underlay. 189 8. The solution MUST address egress link (PE-CE link) failures. 191 9. The solution MUST be loop-free, and once-redirected traffic MUST 192 never be repeatedly redirected. 194 10. The solution MUST not rely on pushing an additional label onto 195 the label stack. 197 11. The solution SHOULD address Broadcast, unknown unicast and 198 multicast (BUM) traffic. 200 5. Solution 202 Sub-second convergence in EVPN networks is achieved using a combined 203 approach to minimising traffic loss: 205 o Local failure detection and restoration of traffic flows in 206 minimal time using a pre-computed redirect path ; 208 o Restoration of optimal traffic paths, and reconvergence of EVPN 209 control plane with EVPN mass withdraw. 211 The solution presented in this document addresses the local failure 212 detection and restoration, without impeding on or impacting existing 213 EVPN control plane convergence mechanisms. 215 Consider the following EVPN topology where PE1 and PE2 are 216 multihoming PEs on a shared ES, ESI1. EVPN (known unicast) or 217 EVPN-VPWS traffic from CE1 to CE2 is sent to PE1 and PE2 using EVPN 218 service labels ESL1 and/or ESL2 (depending on load-balancing mode of 219 the ESI1 interfaces). 221 +------+ 222 | PE1 | 223 | | 224 +-------+ | ESL1---BDF--X 225 | |--------| | \ 226 | | | ERL1--------> \ 227 +-----+ | | +------+ \ 228 | | |IP/MPLS| \ 229 CE1 ---| PE3 |----|Core | ESI1 === CE2 230 | | |Network| / 231 +-----+ | | +------+ / 232 | | | ERL2--------> / 233 | |--------| | / 234 +-------+ | ESL2---DF---- 235 | | 236 | PE2 | 237 +------+ 239 EVPN Multihoming with service and redirect labels 241 Figure 1 243 Alongside the service labels ESL1 and ESL2, two redirect labels ERL1 244 and ERL2 are allocated with special forwarding attributes, as 245 detailed in Section 6. Fast-reroute and use of the ERLs is shown in 246 Section 5.2 248 5.1. Pre-selection of Backup Path 250 EVPN DF-Election lends itself well to the selection of a pre-computed 251 path amongst any given number of peering PEs by providing a 252 DF-Elected and BDF-Elected node at the granularity 253 ([RFC8584] and [I-D.ietf-bess-rfc7432bis]). 255 In All-active mode, all PEs in the Ethernet Segment are actively 256 forwarding known unicast traffic to the CE. In Single-active mode, 257 only a single PE in the Ethernet Segment is actively forwarding known 258 unicast traffic to the CE: the DF-Elected PE. The BDF-Elected PE is 259 next to be elected in the redundancy group and is already known. 261 For consistency across PEs and load-balancing modes, the backup path 262 selected should be in order of {DF, BDF, NDF1, NDF2, ...}. The DF- 263 Elected PE selects the next-best BDF-Elected as backup and all BDF- 264 and NDF-Elected nodes select the best DF-Elected for the protection 265 of their egress links. 267 o PE1 (DF) -> ERL(PE2), 269 o PE2 (BDF) -> ERL(PE1), 271 o PE..n (NDF) -> ERL(PE1), 273 The number of peering PEs is not limited by existing DF-Election 274 algorithms. A solution based on DF-Election supports subsequent 275 redirection upon multiple cascading failures, once a new DF-Election 276 has occurred. Pre-selection of a backup path is supported by all 277 current DF-Election algorithms, and more generally by all algorithms 278 supporting BDF-Election, as recommended in 279 ([I-D.ietf-bess-rfc7432bis]). 281 5.2. Failure Detection and Traffic Restoration 282 +------+ 283 | PE1 | 284 | | 285 +-------+ | ESL1----BDF-X 286 | |--------| | \ 287 | | | ERL1 * * * * * 288 +-----+ | | +----*-+ * 289 | | |IP/MPLS| * * 290 CE1 ---| PE3 |----|Core | * ESI1 *** CE2 291 | | |Network| * / 292 +-----+ | | +------+ * / 293 | | | ERL2----*---> / 294 | |--------| | * / 295 +-------+ | ESL2-----XX-- 296 | | 297 | PE2 | 298 +------+ 300 EVPN Multihoming failure scenario 302 Figure 2 304 The procedures for forwarding known unicast packets received from a 305 remote PE on the local redirect label largely follow [RFC7432] 306 Section 13.2.2. 308 Consider the EVPN multihoming topology in Figure 1, and a traffic 309 flow from CE1 to CE2 which is currently using EVPN service label ESL2 310 and forwarded through the core arriving at PE2. When the local AC 311 representing the pair is protected using the fast-reroute 312 solution, the pre-computed backup path's redirect label (i.e. ERL1 313 from BDF-Elected PE1) is installed against the AC. 315 Under normal conditions, PE2 disposition using ESL2 will result in 316 forwarding the packet to the CE by selecting the local AC associated 317 with the EVPN service label (EVPN-VPWS) or MAC address lookup (EVPN). 318 When this local AC is in failed state, the fast-reroute solution at 319 PE2 will begin rerouting packets using the BDF-Elected peer's nexthop 320 and ERL1. ERL1 is chosen for redirection and not ESL1 for the 321 redirected traffic to prevent loops and overcome DF-Election timing 322 as described in Sections 6.2 and 6.1 respectively. 324 5.2.1. Simultaneous Failures in ES 326 In EVPN multihoming where the CE connects to peering PEs through link 327 aggregation (LAG), a single LAG failure at the CE may manifest as 328 multiple ES failures at all peering PEs simultaneously. 330 As all peering PEs would enable simultaneously the fast-reroute 331 mechanism, redirection would be permanent causing a traffic storm or 332 until TTL expires. 334 Once-redirected traffic may not be redirected again, according to the 335 terminal nature of ERLs described in Section 6.2 337 5.2.2. Successive and Cascading Failures in ES 339 Trying to support cascading failures by redirecting once-redirected 340 traffic is substantially equivalent to simultaneous failures above. 342 Once-redirected traffic may not be redirected again, according to the 343 terminal nature of ERLs described in Section 6.2 and loss is to be 344 expected until EVPN control plane reconverges for double-failure 345 scenarios. 347 In a scenario with 3 peering PEs (PE1-DF, PE2-BDF, PE3-NDF) where PE1 348 fails, followed by a PE2 failure before control-plane reconvergence, 349 there is no reroute of traffic towards PE3 because the reroute-label 350 is terminal. 352 In such rapid-succession failures, it is expected that control plane 353 must first correct for the initial failure and DF-Elect PE2 as new-DF 354 and PE3 as the new-BDF. PE2 to PE3 redirection would then begin, 355 unless control-plane is rapid enough to correct directly, and elect 356 PE3 new-DF. 358 6. Redirect Labels: Forwarding Attributes 360 The EVPN redirect labels MUST be downstream assigned, and it is 361 directly associated with the AC being egress protected. 362 The special forwarding characteristics and use of an EVPN redirect 363 label (ERL) described below, are a matter of local significance only 364 to the advertising PE (which is also the disposition PE). 366 Special-attributes to the ERLs do not affect any other PEs or transit 367 P nodes. There are no extra labels appended to the label stack in 368 the IP/MPLS network and the ERL appears to label-switching transit 369 nodes as would any other EVPN service label. 371 o Traffic redirection and use of reroute labels may create routing 372 loops upon multiple failures. Such loops are detrimental to the 373 network and may cause congestion between protected PEs. 375 o Local restoration and redirection is meant to occur much faster 376 than control-plane operations, meaning redirected packets may 377 arrive at the BDF PE long before a DF-Election operation unblocks 378 the egress link. 380 Two special forwarding characteristics of EVPN redirect labels are 381 described below to mitigate these issues. 383 6.1. Bypassing DF-Election Attribute 385 Local detection and restoration at PE2 will begin rapidly redirecting 386 traffic onto the backup path. 387 Redirected packets will arrive at the Backup-DF port much faster than 388 control plane DF-Election at the Backup-DF peer is capable of 389 unblocking its local egress link for the shared ES (ESI1). All 390 redirected traffic would drop at Backup-DF and no net reduction in 391 traffic loss achieved. 393 Traffic restoration remains dependant upon ES route or Ethernet A-D 394 per ES routes withdrawal for a DF-Election operation and for PE1 to 395 assume the traffic forwarding role. This is especially important in 396 single-active load-balancing mode where known unicast traffic is 397 blocked. 399 To mitigate this, the redirect labels allocated must carry a special 400 attribute in the local forwarding and decapsulation chain: 401 for traffic received on the ERL when the AC is up, an override to the 402 DF-Election is applied and traffic from the ERL will bypass the local 403 Backup-DF blocking state. Once EVPN control plane reconverges, 404 traffic from the ERL will cease and the optimal forwarding path based 405 on ESLs will resume. 407 The EVPN redirect label MUST carry a context locally, such that from 408 disposition to egress redirected packets are allowed to bypass the 409 BDF blocking state that would otherwise drop. Similarly, this may 410 open the gate to the traffic in the reverse direction. 412 6.2. Terminal Disposition Attribute 414 The reroute scheme is susceptible to loops and persistant redirects 415 between peering PEs which have setup FRR redirection. Consider the 416 scenario where both CE-facing interfaces fail simultaneously, fast 417 reroute will be activated at both PE1 and PE2 effectively bouncing a 418 redirected packet between the two PEs indefinitely (or until the TTL 419 expires) causing a traffic storm. 421 To prevent this, a distinction is made between 'regular' EVPN service 422 labels for disposition (i.e. known unicast EVI label or EVPN-VPWS 423 label) and reroute labels with terminal disposition. 425 At the redirecting PE2, we consider the case of ESL2 vs. ERL2 , where 426 both are locally allocated and provided in EVPN routes (downstream 427 allocation) to BGP peers: 429 1. EVPN Service label, ESL2: 431 * Regular MAC-lookup or traffic forwarding occurs towards the 432 access AC. 434 * If the AC is up, traffic will exit the interface, subject to 435 local blocking state on the AC from DF-Election. 437 * If the AC is down and fast-reroute procedures are enabled, 438 traffic may be re-encapsulated using BDF peer's redirect label 439 ERL1 (if received). 441 2. EVPN Reroute label, ERL2: 443 * Regular MAC-lookup or traffic forwarding occurs towards the 444 access AC. 446 * If the AC is up, traffic will apply an override to DF-Election 447 and bypass the local blocking state on the AC. 449 * If the AC is down, traffic is dropped. No reroute must occur 450 of once-rerouted traffic. Redirecting towards peer's redirect 451 label ERL1 is explicitly prevented. 453 The ERL acts like a local cross-connect by providing a direct channel 454 from disposition to the AC. ERLs are terminal-disposition and 455 prevents once-redirected packets from being redirected again. 456 With this forwarding attribute on ERLs, known only locally to the 457 downstream-allocating PE, redirection is achieved without growing the 458 label stack with another special purpose label. 460 6.3. Broadcast, Unknown Unicast and Multicast 462 BUM traffic is treated using EVPN defaults. There is no further 463 extension to exiting procedure as of now, this work is left for 464 future study. 466 7. Controlled Recovery Sequence 468 Fast reroute mechanisms such as the one described in this document 469 generally provide a way to preserve traffic flows at failure time. 470 Use of fast reroute in EVPN, however, permits setting up a controlled 471 recovery sequence to shorten the period of loss between an interface 472 coming up and the EVPN DF-Election procedures and default timers for 473 peer discovery. 475 The benefit of a controlled recovery sequence is amplified when used 476 in conjunction with [I-D.ietf-bess-evpn-fast-df-recovery] 477 (synchronised DF-Election)> 479 8. Transport Underlay 481 The solution is agnostic to transport underlays, for instance similar 482 behaviour is carried forward for VXLAN and SRv6 484 9. BGP Extensions 486 There are no new BGP extensions required to advertise the redirect 487 label(s) used for EVPN egress link protection. 488 The ESI Label Extended Community defined in [RFC7432] Section 7.5 may 489 be advertised along with Ethernet A-D routes: 491 o When advertised with an Ethernet A-D per ES route, it enables 492 split-horizon procedures for multihomed sites as described in 493 [RFC7432] Section 8.3 ; 495 o When advertised with an Ethernet A-D per EVI route, it enables 496 link protection and fast-reroute procedures for multihomed sites 497 as described in this document. The label value represents the 498 per- EVPN redirect label (ERL). The Flags field SHOULD 499 NOT be set and MUST be ignored. 501 Remote PEs SHALL NOT use the ERLs as a substitution for ESLs in route 502 resolution, and is especially not to be confused with the aliasing 503 and backup path ESL as described and used in [RFC7432] Section 8.4. 505 10. Security Considerations 507 The mechanisms in this document use the EVPN control plane as defined 508 in [RFC7432] and [RFC8214], and the security considerations described 509 therein are equally applicable. Reroute labels redistributed in EVPN 510 control plane are meant for consumption by the peering PE in a same 511 ES. It is, however, visible in the EVPN control plane to remote 512 peers. Care shall be taken when installing reroute labels, since 513 their use may result in bypassing DF-Election procedures and lead to 514 duplicate traffic at CEs if incorrectly installed. 516 11. IANA Considerations 518 This document makes no specific requests to IANA. 520 12. References 522 12.1. Normative References 524 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 525 Requirement Levels", BCP 14, RFC 2119, 526 DOI 10.17487/RFC2119, March 1997, 527 . 529 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 530 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 531 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 532 2015, . 534 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 535 Rabadan, "Virtual Private Wire Service Support in Ethernet 536 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 537 . 539 [RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake, 540 J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet 541 VPN Designated Forwarder Election Extensibility", 542 RFC 8584, DOI 10.17487/RFC8584, April 2019, 543 . 545 12.2. Informative References 547 [I-D.ietf-bess-evpn-fast-df-recovery] 548 Brissette, P., Sajassi, A., Burdet, L., Drake, J., and J. 549 Rabadan, "Fast Recovery for EVPN DF Election", draft-ietf- 550 bess-evpn-fast-df-recovery-02 (work in progress), July 551 2021. 553 [I-D.ietf-bess-rfc7432bis] 554 Sajassi, A., Burdet, L., Drake, J., and J. Rabadan, "BGP 555 MPLS-Based Ethernet VPN", draft-ietf-bess-rfc7432bis-01 556 (work in progress), July 2021. 558 [RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H., 559 Michel, C., and H. Chen, "MPLS Egress Protection 560 Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019, 561 . 563 [RFC9135] Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. 564 Rabadan, "Integrated Routing and Bridging in Ethernet VPN 565 (EVPN)", RFC 9135, DOI 10.17487/RFC9135, October 2021, 566 . 568 Appendix A. Acknowledgments 570 Appendix B. Contributors 572 In addition to the authors listed on the front page, the following 573 co-authors have also contributed to this document: 575 Authors' Addresses 577 Luc Andre Burdet (editor) 578 Cisco 580 Email: lburdet@cisco.com 582 Patrice Brissette 583 Cisco 585 Email: pbrisset@cisco.com 587 Takuya 588 KDDI Corporation 590 Email: ta-miyasaka@kddi.com