idnits 2.17.1 draft-wang-bess-evpn-egress-protection-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8679], [I-D.hu-bess-srv6-vpn-bypass-sid], [I-D.eastlake-bess-evpn-vxlan-bypass-vtep], [I-D.ietf-rtgwg-srv6-egress-protection]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 402: '...T2M SID of IMET route R5 SHOULD not be...' RFC 2119 keyword, line 514: '... tunnel, that PE MUST not send it to a...' 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 'SHOULD not' in this paragraph: Note that the End.DT2M SID of IMET route R5 SHOULD not be mirrored on PE2. The reason will be described in [Section 5.1.1]. == 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: When a PE of an egress protection group receives packets from an EELP bypass tunnel, that PE MUST not send it to another PE in the same egress protection group over any of the bypass tunnels. But when a PE receives a VXLAN/SRv6 encapsulated data packet from an ordinary underlay destination IP address, that PE can bypass that packet following a bypass tunnel. -- The document date (14 June 2020) is 1384 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC7348' is mentioned on line 185, but not defined == Unused Reference: 'I-D.ietf-bess-evpn-inter-subnet-forwarding' is defined on line 713, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bess-evpn-prefix-advertisement' is defined on line 721, but no explicit reference was found in the text == Unused Reference: 'RFC7432' is defined on line 729, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-bess-evpn-inter-subnet-forwarding-08 == Outdated reference: A later version (-13) exists of draft-eastlake-bess-evpn-vxlan-bypass-vtep-05 == Outdated reference: A later version (-16) exists of draft-ietf-rtgwg-srv6-egress-protection-00 Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS WG Y. Wang 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track 14 June 2020 5 Expires: 16 December 2020 7 EVPN Egress Protection 8 draft-wang-bess-evpn-egress-protection-01 10 Abstract 12 A fast reroute framework for egress node protection is specified by 13 [RFC8679] . But it cannot be applied to EVPN directly. This document 14 specifies a mechanism to apply Egress Node Protection to EVPN nodes 15 and apply Egress Link Protection to EVPN EAD/EVI routes. 17 In Section 6, this draft is compared with three other drafts. These 18 drafts are: 20 * VTEP Group - [I-D.eastlake-bess-evpn-vxlan-bypass-vtep]. 22 * DT2UL DX2L - [I-D.hu-bess-srv6-vpn-bypass-sid]. 24 * Mirror SID - [I-D.ietf-rtgwg-srv6-egress-protection]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on 16 December 2020. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology and Acronyms . . . . . . . . . . . . . . . . 3 61 2. Detailed Problem and Solution Requirement . . . . . . . . . . 5 62 2.1. Scenarios and Basic Settings . . . . . . . . . . . . . . 5 63 2.1.1. Common Problems for VXLAN and SRv6 . . . . . . . . . 7 64 2.2. VXLAN-Specific Requirements . . . . . . . . . . . . . . . 7 65 2.3. SRv6-Specific Requirements . . . . . . . . . . . . . . . 7 66 3. Encoding the Originating Router's IP Address . . . . . . . . 7 67 4. Control Plane Processing . . . . . . . . . . . . . . . . . . 8 68 4.1. Common Procedures . . . . . . . . . . . . . . . . . . . . 8 69 4.2. VXLAN-Specific Procedures . . . . . . . . . . . . . . . . 9 70 4.3. SRv6-Specific Procedures . . . . . . . . . . . . . . . . 9 71 5. Protection Procedures . . . . . . . . . . . . . . . . . . . . 10 72 5.1. EVPN Egress Node Protection (EENP) . . . . . . . . . . . 10 73 5.1.1. BUM Forwarding Protection . . . . . . . . . . . . . . 10 74 5.1.1.1. Bypass-BUM Filter . . . . . . . . . . . . . . . . 10 75 5.1.1.2. NDF-Bias Rules for Bypass-BUM filter . . . . . . 11 76 5.1.2. Unicast Forwarding Protection . . . . . . . . . . . . 11 77 5.2. Egress ESI Link Protection (EELP) . . . . . . . . . . . . 11 78 5.2.1. Source Squelching Rules . . . . . . . . . . . . . . . 12 79 5.2.2. SRv6-specific EELP Rules . . . . . . . . . . . . . . 12 80 6. Comparison with Other Drafts . . . . . . . . . . . . . . . . 12 81 6.1. Questions . . . . . . . . . . . . . . . . . . . . . . . . 12 82 6.2. Summary Comparisons . . . . . . . . . . . . . . . . . . . 14 83 6.3. Detailed Comparisons with VTEP Group . . . . . . . . . . 14 84 6.4. Detailed Comparisons with DT2UL and DX2L . . . . . . . . 14 85 6.5. Detailed Comparisons with Mirror SID . . . . . . . . . . 15 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 91 10.2. Informative References . . . . . . . . . . . . . . . . . 17 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 94 1. Introduction 96 A principal feature of EVPN is the ability to support multi-homing 97 from a customer equipment (CE) to multiple PE with Ethernet segment 98 (ES) links. This draft specifies a VXLAN/SRv6 gateway mechanism to 99 simplify PE processing in the multi-homed case and enhance EVPN 100 convergency on egress failures. 102 1.1. Terminology and Acronyms 104 This document uses the following acronyms and terms: 106 All-Active Redundancy Mode - When a device is multihomed to a group 107 of two or more PEs and when all PEs in such redundancy group can 108 forward traffic to/from the multihomed device or network for a given 109 VLAN. 111 Backup egress router - Given an egress-protected tunnel and its 112 egress router, this is another router that has connectivity with all 113 or a subset of the destinations of the egress-protected services 114 carried by the egress-protected tunnel. 116 BUM - Broadcast, Unknown unicast, and Multicast. 118 CE - Customer Edge equipment. 120 DCI - Data Center Interconnect. 122 EELP bypass tunnel - Egress ESI Link Protection bypass tunnel - A 123 tunnel used to reroute service packets upon an egress ESI link 124 failure. 126 Egress failure - An egress node failure or an egress link failure. 128 Egress link failure - A failure of the egress link (e.g., PE-CE link, 129 attachment circuit) of a service. 131 Egress loopback - the loopback interface on the Egress router, whose 132 IP address is the destination of the Egress-protected tunnel. 134 Egress node failure - A failure of an egress router. 136 Egress router - A router at the egress endpoint of a tunnel. It 137 hosts service instances for all the services carried by the tunnel 138 and has connectivity with the destinations of the services. 140 Egress-protected tunnel - A tunnel whose egress router is protected 141 by a mechanism according to this framework. The egress router is 142 hence called a protected egress router. 144 Egress-protected EVI - An EVPN MAC-VRF or IP-VRF that is carried by 145 an egress-protected tunnel and hence protected by a mechanism 146 according to this framework. 148 Egress-protecting tunnel - A VXLAN tunnel whose destination IP 149 address is the same value as the Egress-protected tunnel. The 150 Egress-protecting tunnel is constructed on the Protector not on the 151 Egress router. The egress router of the egress-protecting tunnel is 152 the protector. Note that from the view of the ingress router the 153 egress-protecting tunnel and the egress-protected tunnel is the same 154 tunnel. 156 ESI - Ethernet Segment Identifier - A unique non-reserved identifier 157 that identifies an Ethernet segment. 159 NVE - Network Virtualization Edge. 161 OPE - Originating PE - the original Router of an EVPN route. 163 PE - Provider Edge equipment. Note that VTEP/NVE are also called as 164 PE in this draft. 166 PLR - A router at the point of local repair. In egress node 167 protection, it is the penultimate hop router on an egress-protected 168 tunnel. In egress link protection, it is the egress router of the 169 egress- protected tunnel. 171 Protector - A role acted by a router as an alternate of a protected 172 egress router, to handle service packets in the event of an egress 173 failure. A protector is physically independent of the egress router. 175 Protector loopback - the loopback interface on the Protector, whose 176 IP address is the destination of the Egress-protected tunnel. 178 Single-Active Redundancy Mode - When a device or a network is 179 multihomed to a group of two or more PEs and when only a single PE in 180 such a redundancy group can forward traffic to/from the multihomed 181 device or network for a given VLAN. 183 VTEP - VXLAN Tunnel End Point. 185 VXLAN - Virtual eXtensible Local Area Network [RFC7348]. 187 GRT - Global Routing Table. 189 EVPN SID - SRv6 SID for EVPN Instances, e.g. End.DT2M SID, End.DT2U 190 SID, End.DX2 SID, End.DX2V SID. 192 DF - Designated Forwarder. 194 NDF - non-DF, non Designated-Forwarder. 196 NDF-Bias - An exception for filtering bypassed BUM packets. It says 197 that when an outgoing AC is a NDF on its ES, the bypass-BUM filter 198 rules will not be applied for that AC. 200 2. Detailed Problem and Solution Requirement 202 2.1. Scenarios and Basic Settings 204 In the scenario illustrated in Figure 1, where an CE1 is dual-homed 205 to PE1 and PE2 to access the VXLAN/SRv6 network, which enhances 206 network access reliability. When one PE fails, services can be 207 rapidly switched to the other PE, minimizing the impact on services. 209 As shown in Figure 1, the EVPN instance EVI1 has three PEs, PE1, PE2 210 and PE3. The PE address of PE1 is IP1 and the PE address of PE2 is 211 IP2, the PE address of PE3 is IP3, they are three different IP 212 addresses. The BGP update-source of PE1 is IP_N1, of PE2 is IP_N2, 213 and of PE3 is IP_N3. 215 LOC1 is the prefix from which IP1 is allocated, LOC2 is the prefix 216 from which IP2 is allocated, LOC3 is the prefix from which IP3 is 217 allocated. 219 Note that IP_N1 must not be allocated in prefix LOC1, IP_N2 must not 220 be allocated in prefix LOC2. But IP_N3 may be the same as IP3. 222 +---------+ 223 | PE3 | 224 | (IP_N3) | 225 +----+----+ 226 | 227 +----+----+ 228 | PLR | 229 +---------+ 230 / \ 231 / \ 232 / \ 233 +----------+ +-----------+ 234 PE1 | LOC1_E | | LOC2_E | PE2 235 (IP_N1) | |--------------| | (IP_N2) 236 | LOC2_P | EELP bypass | LOC1_P | 237 +--+----+--+ +--+-----+--+ 238 | | ES2 | | 239 | +--------+ +--------+ | 240 ES1 | | | | ES3 241 | | | | 242 CE1 CE2 CE3 244 Figure 1: Egress Protection Scenario 246 Both PE1 and PE2 will advertise an IGP route for the prefix LOC1. 247 The prefix LOC1 on PE1 is called LOC1_E, The prefix LOC1 on PE2 is 248 called LOC1_P. Then we make the metric of LOC1_P lower than LOC1_E. 249 Then we do the same for LOC2. 251 As a result, the PLR node will install an egress-FRR entry for LOC1 252 and LOC2. The primary egress for LOC1 is PE1, the backup egress for 253 LOC1 is PE2. So when PE3 send a EVPN data packet to an IP address of 254 LOC1, the PLR node will use PE1 as the primary path, and use PE2 as 255 the backup path. 257 The different settings between VXLAN EVPN scenario and SRv6 EVPN 258 scenario are described in the following list: 260 * In VXLAN EVPN scenario: LOC1_E is a loopback interface on PE1, 261 LOC1_P is a loopback interface on PE2. Both of the two loopback 262 interfaces are configured with the sam IP address IP1. LOC1 is 263 the /32 or /128 prefix for IP1. So we also use LOC1 to stand for 264 IP1 in VXLAN context in the remainder of this draft. The loopback 265 interface for LOC1_E is IP1's egress loopback interface. The 266 loopback interface for LOC1_P is IP1's protector loopback 267 interface. Then we do the same for IP2. 269 * In SRv6 EVPN scenario: IP1 is the node SID of PE1, LOC1_E is the 270 SRv6 locator for IP1. IP2 is the node SID of PE2, LOC2_E is the 271 SRv6 locator for IP2. LOC1_P is the mirror of LOC1_E in PE2's 272 GRT. LOC2_P is the mirror of LOC2_E in PE1's GRT. 274 2.1.1. Common Problems for VXLAN and SRv6 276 When PE2 receives an EVPN route R0 whose nexthop matches the prefix 277 LOC1, PE2 may discard the route R0 because its nexthop is considered 278 to be PE2's own address. Even though PE2 don't disccard R0, PE2 279 cannot use its nexthop to send an EVPN data packet to PE1. 281 Because that a destination IP within prefix LOC1 (in forms of LOC1_P) 282 will be considered to be sent to PE2 itself. So we should use IP_N1 283 and IP_N2 to establish the bypass path between PE1 and PE2 instead of 284 LOC1 and LOC2. 286 2.2. VXLAN-Specific Requirements 288 When PE2 receives the EVPN routes from PE3, only the VXLAN tunnel 289 will be installed according to [RFC8365]. The VXLAN 290 tunnel will not be installed. So when PE1 fails, 291 although the packets to PE1 are fast-rerouted to PE2 by PLR, PE2 may 292 discard these packets because of the absent of the corresponding 293 VXLAN tunnel entity for their SIP and DIP. 295 2.3. SRv6-Specific Requirements 297 The PLR will not be expected to support any Segment Routing 298 extensions at all, it is just asummed to be an ordinary IPv6 router. 300 When PE2 receives an EVPN data packet whose bottommost SID is an EVPN 301 SID from LOC1. Although the EVPN SID can match the prefix LOC1_P on 302 PE2, the EVPN data packet will be dropped because of the absence of 303 SRv6 function indications. 305 3. Encoding the Originating Router's IP Address 307 This sections describe the extensions specified to meeting the 308 requirements given in Section 2 and enhance VXLAN EVPN convergency. 310 This document reuse the OPE TLV defined in 311 [I-D.heitz-bess-evpn-option-b] section 3. The OPE TLV carries the 312 BGP update-source on corresponding PE. The PEs with egress 313 protection procedures described in this document will add the OPE TLV 314 in the EVPN routes that they are about to advertise. 316 Note that the ESI label or leaf Label is not used in VXLAN packet, so 317 the usage for OPE TLV here won't conflict with the usage in 318 [I-D.heitz-bess-evpn-option-b]. 320 4. Control Plane Processing 322 4.1. Common Procedures 324 We will discuss the common procedures for VXLAN EVPN and SRv6 EVPN 325 first. Then we will discuss the procedures specific to VXLAN EVPN or 326 SRv6 EVPN in the following sections. 328 Using the topology in Figure 1, the common procedures are described 329 in the following list: 331 C1: PE3 sends a MAC/IP route R1 and an IMET route R2 to PE1 and PE2. 332 The nexthop of these routes is IP_N3 (we assume that IP_N3=IP3). 333 PE3 won't add the OPE TLV to these routes because it works as a 334 normal EVPN PE. 336 C2: PE1 and PE2 receive R1 and R2 from PE3. 338 C3: PE1 sends a MAC/IP route R4, an EAD/EVI route R5 and an IMET 339 route R6 to PE2 and PE3. The nexthop of these routes is IP1. 340 PE2 sends a MAC/IP route R7, an EAD/EVI route R8 and an IMET 341 route R9 to PE1 and PE3. The nexthop of these route is IP2. 342 PE1 and PE2 will both add the OPE TLV to these routes because 343 they are configured with protector LOCs. The OPE TLV carries 344 their BGP update-source IP address (IP_N1 or IP_N2). 346 C4: When PE2 receives R4, R5 and R6 from PE1, it installs the bypass 347 tunnel . Because that their nexthops is an IP 348 address within the prefix LOC1_P on PE2. The bypass tunnel 349 is called Egress ESI Link Protection (EELP) 350 bypass tunnel. and PE2 will apply the egress link protection 351 procedures to the received EAD/EVI route R5 following the second 352 approach of [RFC8679] section 6. Please see [Section 5.2, 353 Paragraph 1] for details. 355 Note that the MAC/IP entries from PE1 is installed in GRT by PE2 356 as mirrored entries. 358 The procedures when PE1 receives R7, R8 and R9 are simlar to the 359 above. 361 C5: When PE3 receives the EVPN routes from PE1/PE2, it will ignore 362 the OPE TLV because the route's tunnel encapsulation is VXLAN or 363 SRv6 and the nexthop is not a local address on PE3. 365 4.2. VXLAN-Specific Procedures 367 First of all, we assume that the VNI for the same EVI on PE1 and PE2 368 must be the same. 370 The VXLAN-specific procedures are defined in the following list: 372 S1: In [Section 4.1, Paragraph 3, Item 2], when PE1 receives the 373 MAC/IP route from PE3, it constructs two VXLAN tunnels: and . Because it is configured with 375 egress loopback and protector loopback. 377 S2: In [Section 4.1, Paragraph 3, Item 4], the bypass tunnel is a 378 VXLAN tunnel. 380 4.3. SRv6-Specific Procedures 382 In VXLAN EVPN, the VXLAN tunnels are constructed for packet- 383 validating purpose. In SRv6 EVPN, there aren't such packet- 384 validating tunnels. So when a SRv6 PE receives EVPN routes from 385 other PEs, no packet-validating tunnels will be installed. 387 But the bypass tunnels aren't constructed for packet-validating 388 purpose, they are used to transport flows among the PEs of the same 389 egress protection group. So the bypass tunnel between PE1 and PE2 390 must also be installed in SRv6 EVPN scenarios. 392 The SRv6-specific procedures are defined in the following list: 394 S3: In [Section 4.1, Paragraph 3, Item 4], The bypass tunnel is a 395 SRv6 tunnel. 397 S4: In [Section 4.1, Paragraph 3, Item 4], When PE2 receives R4, R5 398 from PE1, it mirrors the remote EVPN-SID of these routes in the 399 GRT. This is for the requirements from [Section 2.3, Paragraph 400 2]. 402 Note that the End.DT2M SID of IMET route R5 SHOULD not be 403 mirrored on PE2. The reason will be described in 404 [Section 5.1.1]. 406 S5: In [Section 4.1, Paragraph 3, Item 4], PE2 may apply the egress 407 link protection control-plane procedures to the received EAD/EVI 408 route R5 following the first approach of [RFC8679] section 6. 409 The corresponding data-plane details will be described in 410 [Section 5.2.2, Paragraph 1, Item 2]. 412 5. Protection Procedures 414 This section describes how Layer 2 unicast and BUM (Broadcast, 415 Unknown unicast, and Multicast) packet forwarding are protected. A 416 description of how Layer 3 packet forwarding are protected will be 417 provided in a furture version of this document. 419 5.1. EVPN Egress Node Protection (EENP) 421 The following two subsections discuss EENP procedures for BUM 422 forwarding and Unicast Forwarding. 424 5.1.1. BUM Forwarding Protection 426 5.1.1.1. Bypass-BUM Filter 428 PE3 will do ingress replication to PE1 and PE2 for BUM packets, one 429 copy for each PE. So BUM packets need not to be protected by the 430 egress node protection mechanism. But there will be another issue 431 along with the BUM packets. It is: 433 PE1 and PE2 will receive a copy of BUM packet from PE3 separately, 434 and the DF node for the will forward it to the CE node. 435 When the non-DF node of them fails, the BUM packets destined to it 436 will be re-routed to the other one, which will be the DF-node for 437 that , so these BUM packets will be forwarded to CE2. But 438 PE3 has sent another copy of BUM packets directly to the DF-node, and 439 this copy will be forwarded to CE2 either. So CE2 will receive 440 duplicated BUM packets from the DF-node after the FRR switch of PLR 441 untill the global repair finishes. 443 In order to avoid the excessive BUM packets, some specific rules are 444 defined in the following list: 446 * For VXLAN EVPN: The BUM packet received via LOC1_P or LOC2_P will 447 be dropped. 449 * For SRv6 EVPN: Because the End.DT2M SIDs are not mirrored 450 according to [Section 4.3, Paragraph 4.2.2], those duplicating BUM 451 packets will be dropped due to the absence of SRv6 function 452 indication. 454 5.1.1.2. NDF-Bias Rules for Bypass-BUM filter 456 When PE1 node fails, the DF-election between PE1 and PE2 will be 457 restarted, and the PLR will do FRR-switch. We assume that the PLR 458 FRR-switch may be faster than the DF re-election. So if PE1 is the 459 DF node for before its failure, the rules that described 460 in [Section 5.1.1.1, Paragraph 3] will cause packet drop before the 461 DF re-election finishes. Because that PE2 will be the non-DF (NDF) 462 node for at that time. 464 In order to accelerate the convergence of bypass-BUM packets, some 465 specific rules are defined in the following list: 467 * For VXLAN EVPN: The BUM packet received via LOC1_P or LOC2_P will 468 not be dropped when it is about to forwarded to an AC whose DE- 469 role is NDF. 471 * For SRv6 EVPN: The End.DT2M SIDs need to be mirrored, those BUM 472 packets received via a mirrored End.DT2M SID will not be dropped 473 when it is about to forwarded to an AC whose DE-role is NDF. 475 These rules are called as "NDF-Bias" rules in this draft. 477 5.1.2. Unicast Forwarding Protection 479 When PE1 fails, the data packets (destined to CE2) from PE3 to PE1 480 are fast- rerouted to PE2 by the PLR node in the underlay network, 481 the PE2 won't discard these packets because of the existence of VXLAN 482 tunnel or mirrored EVPN SID on PE2 itself. The PE2 will 483 forward them to CE. 485 5.2. Egress ESI Link Protection (EELP) 487 The EELP forwarding entry on PE1 will take the ESI link as 488 primary forwarding path, and take the EAD/EVI route from PE2 as 489 backup forwarding path. This procedure follows the second approach 490 of [RFC8679] section 6. 492 When the ESI2 link fails, the backup path will be activated on the 493 result of a FRR switch by the overlay network. 495 Note that even when the ESI is All-Active redundancy mode the EELP 496 will follow the FRR behavior. The EELP behavior is the same for All- 497 Active redundancy mode and Single-Active redundancy mode. 499 When ESI is All-Active redundancy mode PE3 will performing overlay 500 ECMP via EAD/EVI routes to PE1/PE2, When the ESI link on PE1 fails, 501 PE1 will forwarding the packets via EELP bypass tunnel before PE3 502 delete the EAD/EVI routes. But the bypass forwarding is temporary, 503 after PE3 delete the EAD/EVI routes upon the withdraw of the EAD/EVI 504 route from PE1, there won't be any bypass forwarding again. 506 Note that when ESI is Single-Active redundancy mode, there is no 507 importance for PE3 to use the EAD/EVI routes from PE1/PE2. But the 508 EAD/EVI route is still useful between PE1 and PE2 for EELP procedures 509 in Single- Active redundancy mode. 511 5.2.1. Source Squelching Rules 513 When a PE of an egress protection group receives packets from an EELP 514 bypass tunnel, that PE MUST not send it to another PE in the same 515 egress protection group over any of the bypass tunnels. But when a 516 PE receives a VXLAN/SRv6 encapsulated data packet from an ordinary 517 underlay destination IP address, that PE can bypass that packet 518 following a bypass tunnel. 520 5.2.2. SRv6-specific EELP Rules 522 * When the ESI2 link on PE1 fails, the bypassed EVPN packet's 523 underlay destination IP adrress can't be the EVPN SID directly. 524 The EVPN SID have to be hiden in the SRH header in order to avoid 525 the problems described in [Section 2.1.1, Paragraph 2], even if 526 the bypass tunnel is a SR-BE tunnel. 528 * When [Section 4.3, Paragraph 4, Item 3] is applied, PE1 will use 529 the EVPN SID of itself to encapsulate the bypassed EVPN packet, 530 not use the EVPN SID from the received EAD/EVI route. 532 When that bypassed EVPN packet is received by PE2, the packet will 533 match a mirrored EVPN SID on PE2. So PE2 will know that the 534 packet is a bypassed data packet. The bypassed data packets will 535 be forwarded to local CEs only. 537 6. Comparison with Other Drafts 539 6.1. Questions 541 We compare this draft with three other drafts in this section. These 542 drafts are: 544 * VTEP Group - [I-D.eastlake-bess-evpn-vxlan-bypass-vtep]. 546 * DT2UL DX2L - [I-D.hu-bess-srv6-vpn-bypass-sid]. 548 * Mirror SID - [I-D.ietf-rtgwg-srv6-egress-protection]. 550 We use the following questions for these solutions to do the 551 comparison: 553 ** Steady bypassing 554 #1 - When AC fails but PE node still works well, will there be 555 steady bypassing traffic?. 557 ** Bypass-BUM filter 558 #2 - Is Bypass-BUM filter rules supported by that solution? The 559 "Bypass-BUM filter" rules are defined in [Section 5.1.1.1, 560 Paragraph 3] 562 ** Node Protect 563 #3 - Will Egress Node Protection be supported? 565 ** Link Protect 566 #4 - Will Egress Link Protection be supported? 568 ** PLR SRv6-aware 569 #5 - Must the PLR node be SRv6-aware? 571 ** Extra VPN SID 572 #6 - Should Extra EVPN SID be configured (Like what have been done 573 by "DT2UL DX2L" Solution) for that solution ? 575 ** Special BGP 576 #7 - Should special BGP extensions dedicated to SRv6 scenarios be 577 implemented for that solution? 579 ** Special IGP 580 #8 - Should special IGP extensions dedicated to SRv6 scenarios be 581 implemented for that solution? 583 ** Implicit IP-VRF 584 #9 - Are implicit IP-VRF instances (identified by "mirror SID") 585 needed by that solution? 587 ** RT-1 coworking 588 #10 - Can the solution cowork with Ethernet A-D route per EVI? 590 ** NDF-Bias Rules 591 #11 - Is NDF-Bias rules supported by that solution? The "NDF- 592 Bias" rules are defined in [Section 5.1.1.2, Paragraph 2] 594 6.2. Summary Comparisons 596 We place the detailed comparisons about the ansowers of these 597 questions for each solution in separated sections, but we place the 598 brief comparisons in the following table: 600 +-------------------+------------+-------+------------+------------+ 601 | Questions | This Draft | DT2UL | Mirror-SID | VTEP-Group | 602 +===================+============+=======+============+============+ 603 | Steady bypassing | No | No | No | Yes | 604 +-------------------+------------+-------+------------+------------+ 605 | Bypass-BUM filter | Yes | No | No | No | 606 +-------------------+------------+-------+------------+------------+ 607 | Node Protect | Yes | No | Yes | Yes | 608 +-------------------+------------+-------+------------+------------+ 609 | Link Protect | Yes | Yes | No | Yes | 610 +-------------------+------------+-------+------------+------------+ 611 | PLR SRv6-aware | No | No | Yes | N/A | 612 +-------------------+------------+-------+------------+------------+ 613 | Extra VPN-SID | No | Yes | No | N/A | 614 +-------------------+------------+-------+------------+------------+ 615 | Special BGP | No | Yes | No | N/A | 616 +-------------------+------------+-------+------------+------------+ 617 | Special IGP | No | No | Yes | N/A | 618 +-------------------+------------+-------+------------+------------+ 619 | Implicit IP-VRF | No | No | Yes | N/A | 620 +-------------------+------------+-------+------------+------------+ 621 | RT-1 coworking | Yes | Yes | Yes | No | 622 +-------------------+------------+-------+------------+------------+ 623 | NDF-Bias rules | Yes | No | No | No | 624 +-------------------+------------+-------+------------+------------+ 626 Table 1: Solution Comparisons 628 6.3. Detailed Comparisons with VTEP Group 630 When ACs of ESI2 (All-Active mode) fails on PE1 but PE1 itself still 631 works well, no steady bypassing traffic (to ES2) will arise according 632 to current draft. But according to 633 [I-D.eastlake-bess-evpn-vxlan-bypass-vtep], there will be steady 634 bypassing. 636 6.4. Detailed Comparisons with DT2UL and DX2L 638 Only one End.DT2U/DX2 SID need to be configured per EVI. No 639 SRv6-dedicated BGP extension needed according to current draft. 640 End.DT2UL/DX2L is only suitable for EELP, it can't be used in EENP 641 scenarios. 643 6.5. Detailed Comparisons with Mirror SID 645 We don't expect the PLR to support SRv6 extensions, it can be just a 646 simple IPv6 router. The mirrored locators and mirrored EVPN SIDs 647 will be installed in GRT, not in a "context-specific routing space" 648 which is identified by a "mirror-SID". The dataplane will be a 649 little more simpler according to current draft. And the solution of 650 current draft will be a common solution for SRv6 EVPNs and VXLAN 651 EVPNs. 653 The mirror-SID is advertised in the underlay network, but the egress 654 link protection (EELP in this draft) is processed in the overlay 655 network. So [I-D.ietf-rtgwg-srv6-egress-protection] can't support 656 egress link protection. 658 The locators LOC1 and LOC2 won't overlap with each other (If so, the 659 problems that [I-D.eastlake-bess-evpn-vxlan-bypass-vtep] encountered 660 will come up, the details see Section 6.3). So the mirrored locator 661 LOC1_P don't have to be installed into different routing spaces. It 662 means that the mirror-SID need not to identify an implicit IP-VRF 663 instance which is called "context-specific routing space" in that 664 draft. 666 In fact, the PLRs will obtain no awareness of that, whether the 667 mirror-SID actually identifies the GRT or not. Any node SID that 668 won't be mirrored by other PEs can be used as a mirror-SID. 670 Two approaches for egress link protection is defined in [RFC8679] 671 section 6. The second approach don't use the context-specific 672 forwarding method even in MPLS dataplane. We prefer the second 673 approach, because that it is more simpler. When using the second 674 approach, the destination IP of the bypass-tunnel takes the mirror- 675 SID's place in egress link protection procedures. But in egress node 676 protection, the mirror-SID typically brings out no significant 677 results. 679 It is very important to be noticed that [RFC8679] is written totally 680 in MPLS environments. So it is necessary for [RFC8679] to assume 681 that the VPN labels are downstream-assigned dynamically. But the 682 SRv6 locator is typically assigned by a centerlized authority. So it 683 is not necessary for us to use a "context-specific forwarding table" 684 again in SRv6 scenarios. 686 7. IANA Considerations 688 IANA Considerations for OPE TLV following 689 [I-D.heitz-bess-evpn-option-b]. 691 8. Security Considerations 693 This section will be added in future versions. 695 9. Acknowledgements 697 The authors would like to thank the following for their comments and 698 review of this document: 700 Chunning Dai, Bing Song, Zheng Zhou. 702 10. References 704 10.1. Normative References 706 [I-D.heitz-bess-evpn-option-b] 707 Heitz, J., Sajassi, A., Drake, J., and J. Rabadan, "Multi- 708 homing and E-Tree in EVPN with Inter-AS Option B", Work in 709 Progress, Internet-Draft, draft-heitz-bess-evpn-option- 710 b-01, 13 November 2017, . 713 [I-D.ietf-bess-evpn-inter-subnet-forwarding] 714 Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. 715 Rabadan, "Integrated Routing and Bridging in EVPN", Work 716 in Progress, Internet-Draft, draft-ietf-bess-evpn-inter- 717 subnet-forwarding-08, 5 March 2019, 718 . 721 [I-D.ietf-bess-evpn-prefix-advertisement] 722 Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. 723 Sajassi, "IP Prefix Advertisement in EVPN", Work in 724 Progress, Internet-Draft, draft-ietf-bess-evpn-prefix- 725 advertisement-11, 18 May 2018, 726 . 729 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 730 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 731 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 732 2015, . 734 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 735 Uttaro, J., and W. Henderickx, "A Network Virtualization 736 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 737 DOI 10.17487/RFC8365, March 2018, 738 . 740 [RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H., 741 Michel, C., and H. Chen, "MPLS Egress Protection 742 Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019, 743 . 745 10.2. Informative References 747 [I-D.eastlake-bess-evpn-vxlan-bypass-vtep] 748 Eastlake, D., Li, Z., and S. Zhuang, "EVPN VXLAN Bypass 749 VTEP", Work in Progress, Internet-Draft, draft-eastlake- 750 bess-evpn-vxlan-bypass-vtep-05, 27 April 2020, 751 . 754 [I-D.hu-bess-srv6-vpn-bypass-sid] 755 Hu, C., "Enhance IPv6-Segment-Routing-based EVPN VPWS All 756 Active Usage", Work in Progress, Internet-Draft, draft-hu- 757 bess-srv6-vpn-bypass-sid-00, 2 July 2018, 758 . 761 [I-D.ietf-rtgwg-srv6-egress-protection] 762 Hu, Z., Chen, H., Chen, H., Wu, P., Toy, M., Cao, C., Liu, 763 L., and X. Liu, "SRv6 Path Egress Protection", Work in 764 Progress, Internet-Draft, draft-ietf-rtgwg-srv6-egress- 765 protection-00, 18 March 2020, 766 . 769 Author's Address 771 Yubao Wang 772 ZTE Corporation 773 No. 50 Software Ave, Yuhuatai Distinct 774 Nanjing 775 China 777 Email: yubao.wang2008@hotmail.com