idnits 2.17.1 draft-wang-bess-evpn-egress-protection-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8679]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 20, 2020) is 1460 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) == Missing Reference: 'RFC7348' is mentioned on line 156, but not defined == Unused Reference: 'I-D.ietf-bess-evpn-inter-subnet-forwarding' is defined on line 367, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bess-evpn-prefix-advertisement' is defined on line 373, but no explicit reference was found in the text == Unused Reference: 'RFC7432' is defined on line 379, but no explicit reference was found in the text == Unused Reference: 'RFC8365' is defined on line 384, 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 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS WG Yubao. Wang 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track April 20, 2020 5 Expires: October 22, 2020 7 EVPN Egress Protection 8 draft-wang-bess-evpn-egress-protection-00 10 Abstract 12 A fast reroute framework for egress node protection is specified by 13 [RFC8679] . But it cannot be applied to VXLAN EVPN directly. This 14 document specifies a mechanism to apply Egress Node Protection to 15 VXLAN EVPN nodes and apply Egress Link Protection to EVPN EAD/EVI 16 routes. 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 October 22, 2020. 35 Copyright Notice 37 Copyright (c) 2020 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 1.1. Terminology and Acronyms . . . . . . . . . . . . . . . . 2 54 2. Detailed Problem and Solution Requirement . . . . . . . . . . 4 55 3. Encoding the Originating Router Address . . . . . . . . . . . 6 56 4. Control Plane Processing . . . . . . . . . . . . . . . . . . 6 57 5. Protection Procedures . . . . . . . . . . . . . . . . . . . . 7 58 5.1. EVPN Egress Node Protection (EENP) . . . . . . . . . . . 7 59 5.1.1. BUM Forwarding Protection . . . . . . . . . . . . . . 7 60 5.1.2. Unicast Forwarding Protection . . . . . . . . . . . . 7 61 5.2. Egress ESI Link Protection (EELP) . . . . . . . . . . . . 8 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 65 9. Normative References . . . . . . . . . . . . . . . . . . . . 9 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 A principal feature of EVPN is the ability to support multi-homing 71 from a customer equipment (CE) to multiple PE/VTEP with Ethernet 72 segment (ES) links. This draft specifies a VXLAN gateway mechanism 73 to simplify VTEP processing in the dual-homed case and enhance EVPN 74 convergency on egress failures. 76 1.1. Terminology and Acronyms 78 This document uses the following acronyms and terms: 80 All-Active Redundancy Mode - When a device is multihomed to a group 81 of two or more PEs and when all PEs in such redundancy group can 82 forward traffic to/from the multihomed device or network for a given 83 VLAN. 85 Backup egress router - Given an egress-protected tunnel and its 86 egress router, this is another router that has connectivity with all 87 or a subset of the destinations of the egress-protected services 88 carried by the egress-protected tunnel. 90 BUM - Broadcast, Unknown unicast, and Multicast. 92 CE - Customer Edge equipment. 94 DCI - Data Center Interconnect. 96 EELP bypass tunnel - Egress ESI Link Protection bypass tunnel - A 97 tunnel used to reroute service packets upon an egress ESI link 98 failure. 100 Egress failure - An egress node failure or an egress link failure. 102 Egress link failure - A failure of the egress link (e.g., PE-CE link, 103 attachment circuit) of a service. 105 Egress loopback - the loopback interface on the Egress router, whose 106 IP address is the destination of the Egress-protected tunnel. 108 Egress node failure - A failure of an egress router. 110 Egress router - A router at the egress endpoint of a tunnel. It 111 hosts service instances for all the services carried by the tunnel 112 and has connectivity with the destinations of the services. 114 Egress-protected tunnel - A tunnel whose egress router is protected 115 by a mechanism according to this framework. The egress router is 116 hence called a protected egress router. 118 Egress-protected EVI - An EVPN MAC-VRF or IP-VRF that is carried by 119 an egress-protected tunnel and hence protected by a mechanism 120 according to this framework. 122 Egress-protecting tunnel - A VXLAN tunnel whose destination IP 123 address is the same value as the Egress-protected tunnel. The 124 Egress-protecting tunnel is constructed on the Protector not on the 125 Egress router. The egress router of the egress-protecting tunnel is 126 the protector. Note that from the view of the ingress router the 127 egress-protecting tunnel and the egress-protected tunnel is the same 128 tunnel. 130 ESI - Ethernet Segment Identifier - A unique non-reserved identifier 131 that identifies an Ethernet segment. 133 OPE - Originating PE - the original Router of an EVPN route. 135 PE - Provider Edge equipment. 137 PLR - A router at the point of local repair. In egress node 138 protection, it is the penultimate hop router on an egress-protected 139 tunnel. In egress link protection, it is the egress router of the 140 egress- protected tunnel. 142 Protector - A role acted by a router as an alternate of a protected 143 egress router, to handle service packets in the event of an egress 144 failure. A protector is physically independent of the egress router. 146 Protector loopback - the loopback interface on the Protector, whose 147 IP address is the destination of the Egress-protected tunnel. 149 Single-Active Redundancy Mode - When a device or a network is 150 multihomed to a group of two or more PEs and when only a single PE in 151 such a redundancy group can forward traffic to/from the multihomed 152 device or network for a given VLAN. 154 VTEP - VXLAN Tunnel End Point. 156 VXLAN - Virtual eXtensible Local Area Network [RFC7348]. 158 2. Detailed Problem and Solution Requirement 160 In the scenario illustrated in Figure 1, where an CE1 is dual-homed 161 to VTEP1 and VTEP2 to access the VXLAN network, which enhances 162 network access reliability. When one VTEP fails, services can be 163 rapidly switched to the other VTEP, minimizing the impact on 164 services. 166 As shown in Figure 1, the VTEP address of VTEP1 is IP1 and the VTEP 167 address of VTEP2 is IP2, the VTEP address of VTEP3 is IP3, they are 168 three different IP addresses. The BGP update-source of VTEP1 is 169 IP10, of VTEP2 is IP20, and of VTEP3 is IP30. Note that IP1 may be 170 the same as IP10, IP2 may be the same as IP20, IP3 may be the same as 171 IP30. 173 +-------+ 174 ----------------------- | VTEP3 | 175 ^ | (IP3) | 176 | +-------+ 177 | / \ 178 | / \ 179 VXLAN Tunnels / \ 180 | / \ 181 | / Egress \ 182 | +----------+ protection +-----------+ 183 v | IP1_E | | IP2_E | 184 --------- | |--------------| | VTEP2 185 | IP2_P | EELP bypass | IP1_P | (IP2) 186 +--+----+--+ +--+-----+--+ 187 VTEP1 | | ES2 | | 188 (IP1) | +--------+ +--------+ | 189 | ES1 | | | ES3 190 | | | | 191 CE1 CE2 CE3 193 Figure 1: Egress Protection for VXLAN EVPN 195 From the view of VTEP3, the VXLAN tunnel to IP1 is the tunnel for 196 VTEP1, the VXLAN tunnel to IP2 is the tunnel for VTEP2. But now we 197 add a loopback interface on VTEP2 and let its IP address be IP1 too, 198 add another loopback interface on VTEP1 and let its IP address be IP2 199 too. Then we call there is an egress loopback for IP1 on VTEP1 200 called IP1_E, and there is a protector loopback for IP1 on VTEP2 201 called IP1_P, and there is an egress loopback for IP2 on VTEP2 called 202 IP2_E, and there is a protector loopback for IP2 on VTEP1 called 203 IP2_P. 205 Then, for IP1, we make the metric of the IGP route for IP1_P lower 206 than that for IP1_E. Then we do the same for IP2. Now we call the 207 VXLAN tunnel from IP3 to IP1_E as the egress-protected tunnel for 208 VTEP1, and we call the VXLAN tunnel from IP3 to IP1_P as the egress- 209 protecting tunnel for VTEP1. The egress-protected tunnel and egress- 210 protecting tunnel for VTEP2 are similar to those tunnels for VTEP1. 212 Note that from the view of VTEP3 the egress-protected tunnel and 213 egress-protecting tunnel for the same VTEP is actually the same 214 tunnel. When the VTEP node is active, the packets to the VTEP are 215 forwarded to it by the egress-protected tunnel. When the VTEP node 216 fails, the packets to it are forwarded to its protector by the 217 egress-protecting tunnel. 219 But when VTEP2 receives the EVPN routes from VTEP3, only the egress- 220 protected tunnel for VTEP2 itself is constructed. the egress- 221 protecting tunnel for VTEP1 is not constructed by default. so when 222 VTEP1 fails, although the packets to VTEP1 are fast-rerouted to VTEP2 223 by underlay network, the VTEP2 may discard these packets because of 224 the absent of the corresponding VXLAN tunnel entity for their SIP and 225 DIP. 227 When VTEP2 receives the EVPN routes from VTEP1, it may discard these 228 routes because their nexthop is the IP address of a loopback on VTEP2 229 itself. Even though VTEP2 don't disccard these EVPN routes, it 230 cannot use their nexthop to construct a VXLAN tunnel for the same 231 reason as above. 233 3. Encoding the Originating Router Address 235 This sections describe the extensions specified to meeting the 236 requirements given in Section 3 and enhance VXLAN EVPN convergency. 238 This document reuse the OPE TLV defined in 239 [I-D.heitz-bess-evpn-option-b] section 3. the OPE TLV carries the 240 BGP update-source on corresponding VTEP. The VTEPs with egress 241 protection procedures described in this document will add the OPE TLV 242 in the EVPN routes they are about to advertise. 244 Note that the ESI label or leaf Label is not used in VXLAN packet, so 245 the usage for OPE TLV here won't conflict with the usage in 246 [I-D.heitz-bess-evpn-option-b]. 248 4. Control Plane Processing 250 Using the topology in Figure 1: 252 We assume that the VNI for the same EVI on VTEP1 and VTEP2 must be 253 the same. 255 1) VTEP3 sends a MAC/IP route and an IMET route to VTEP1 and VTEP2. 256 The nexthop of these routes is IP3 (we assume that IP30=IP3). VTEP3 257 won't add the OPE TLV to these routes because it works as normal EVPN 258 VTEP. 260 2) When VTEP1 receives the IMET route from VTEP3, it constructs the 261 VXLAN tunnel (IP3,IP10). When VTEP1 receives the MAC/IP route from 262 VTEP3, it constructs the VXLAN tunnel (IP3,IP1) and (IP3, IP2) 263 because it is configured with egress loopback and protector loopback. 264 The procedures on VTEP2 is simlar to the above. 266 3) VTEP1 sends a MAC/IP route, an EAD/EVI route and an IMET route to 267 VTEP2 and VTEP3. The nexthop of the MAC/IP route and the EAD/EVI 268 route is IP1 and the nexthop of the IMET route is IP10. VTEP2 sends 269 a MAC/IP route, an EAD/EVI route and an IMET route to VTEP1 and 270 VTEP3. The nexthop of the MAC/IP route and the EAD/EVI route is IP2 271 and the nexthop of the IMET route is IP20. VTEP1 and VTEP2 will both 272 add the OPE TLV to these routes because they are configured with 273 egress loopback and protector loopback. The OPE TLV carries their 274 BGP update-source IP address (IP10 or IP20). 276 4) When VTEP2 receives the MAC/IP or EAD/EVI route from VTEP1, it 277 constructs the VXLAN tunnel(IP10,IP20) because that the nexthop is 278 the IP address of the protector loopback on VTEP2. When VTEP2 279 receives the IMET route from VTEP1, it constructs the VXLAN 280 tunnel(IP10,IP20) too. The VXLAN tunnel(IP10,IP20) is called Egress 281 ESI Link Protection (EELP) bypass tunnel. and VTEP2 will apply the 282 egress link protection procedures to the received EAD/EVI route 283 following the second approach of RFC8679 section 6. The procedures 284 on VTEP1 is simlar to the above. 286 5) When VTEP3 receives the MAC/IP route from VTEP1/VTEP2, it will 287 ignore the OPE TLV because the route's tunnel encapsulation is VXLAN 288 and the nexthop is not a local address on VTEP3. 290 5. Protection Procedures 292 This section describes how Layer 2 unicast and BUM (Broadcast, 293 Unknown unicast, and Multicast) packet forwarding are protected. A 294 description of how Layer 3 packet forwarding are protected will be 295 provided in a furture version of this document. 297 5.1. EVPN Egress Node Protection (EENP) 299 The following two subsections discuss EENP procedures for BUM 300 forwarding and Unicast Forwarding. 302 5.1.1. BUM Forwarding Protection 304 VTEP1 and VTEP2 will receive a copy of BUM packet from VTEP3 305 separately, and the DF node for the (ESI,EVI) will forward it to the 306 CE node. When either of them fails, the other one will become the DF 307 for all (ESI,EVI)s. 309 5.1.2. Unicast Forwarding Protection 311 When VTEP1 fails, the data packets from VTEP3 to VTEP1 is fast- 312 rerouted to VTEP2 by the PLR node in the underlay network, the VTEP2 313 won't discard these packets because of the existence of VXLAN 314 tunnel(IP3, IP1) on itself. The VTEP2 will forward them to CE. 316 5.2. Egress ESI Link Protection (EELP) 318 The EELP (ESI,EVI) forwarding entry on VTEP1 will take the ESI link 319 as primary forwarding path, and take the EAD/EVI route from VTEP2 as 320 backup forwarding path. This procedure follows the second approach 321 of RFC8679 section 6. 323 When the ESI link fails, the backup path will be activated on the 324 result of a FRR switch. 326 Note that even when the ESI is All-Active redundancy mode the EELP 327 will follow the FRR behavior. The EELP behavior is the same for All- 328 Active redundancy mode and Single-Active redundancy mode. 330 When ESI is All-Active redundancy mode VTEP3 will performing overlay 331 ECMP via EAD/EVI routes to VTEP1/VTEP2, When the ESI link on VTEP1 332 fails, VTEP1 will forwarding the packets via EELP bypass tunnel 333 before VTEP3 delete the EAD/EVI routes. But the bypass forwarding is 334 temporary, when VTEP delete the EAD/EVI routes upon the withdraw of 335 the EAD/EVI route from VTEP1, there won't be any bypass forwarding 336 again. 338 But when ESI is Single-Active redundancy mode, there is no importance 339 for VTEP3 to use the EAD/EVI routes from VTEP1/VTEP2. The EAD/EVI is 340 still useful between VTEP1 and VTEP2 for EELP procedures in Single- 341 Active redundancy mode. 343 6. IANA Considerations 345 IANA Considerations for OPE TLV following 346 [I-D.heitz-bess-evpn-option-b]. 348 7. Security Considerations 350 This section will be added in future versions. 352 8. Acknowledgements 354 The authors would like to thank the following for their comments and 355 review of this document: 357 Chunning Dai, Bing Song, Zheng Zhou. 359 9. Normative References 361 [I-D.heitz-bess-evpn-option-b] 362 Heitz, J., Sajassi, A., Drake, J., and J. Rabadan, "Multi- 363 homing and E-Tree in EVPN with Inter-AS Option B", draft- 364 heitz-bess-evpn-option-b-01 (work in progress), November 365 2017. 367 [I-D.ietf-bess-evpn-inter-subnet-forwarding] 368 Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. 369 Rabadan, "Integrated Routing and Bridging in EVPN", draft- 370 ietf-bess-evpn-inter-subnet-forwarding-08 (work in 371 progress), March 2019. 373 [I-D.ietf-bess-evpn-prefix-advertisement] 374 Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. 375 Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf- 376 bess-evpn-prefix-advertisement-11 (work in progress), May 377 2018. 379 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 380 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 381 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 382 2015, . 384 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 385 Uttaro, J., and W. Henderickx, "A Network Virtualization 386 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 387 DOI 10.17487/RFC8365, March 2018, 388 . 390 [RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H., 391 Michel, C., and H. Chen, "MPLS Egress Protection 392 Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019, 393 . 395 Author's Address 397 Yubao Wang 398 ZTE Corporation 399 No. 50 Software Ave, Yuhuatai Distinct 400 Nanjing 401 China 403 Email: wang.yubao2@zte.com.cn