idnits 2.17.1 draft-wang-bess-evpn-bum-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 ([I-D.ietf-rtgwg-srv6-egress-protection]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 10 instances of lines with non-RFC3849-compliant IPv6 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 (30 July 2021) is 1001 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: 'CE1' is mentioned on line 126, but not defined == Outdated reference: A later version (-16) exists of draft-ietf-rtgwg-srv6-egress-protection-03 == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-07 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS WG Y. Wang 3 Internet-Draft R. Chen 4 Intended status: Standards Track ZTE Corporation 5 Expires: 31 January 2022 30 July 2021 7 Egress Protection for EVPN BUM 8 draft-wang-bess-evpn-bum-egress-protection-00 10 Abstract 12 When the procedures per [I-D.ietf-rtgwg-srv6-egress-protection] are 13 applied to EVPN services, the egress-protection on PLR is typically 14 more faster than the new DF node of the affected ESI is re-elected. 15 As a result of that, replicated BUM packets will be sent to the CEs 16 of the affected ES. This draft describes a "NDF-bias" mechanism that 17 is used to avoid such excessive BUM packets. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 31 January 2022. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Terminology and Acronyms . . . . . . . . . . . . . . . . 2 54 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.1. Solution 1: Separate Locators for End.DT2M SIDs . . . . . 5 57 3.2. Solution 2: The mirrored End.DT2M SIDs are not 58 installed . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.3. Solution 3: NDF-Bias Mechanism . . . . . . . . . . . . . 6 60 4. Condisderations on EVPN Mulicast and Other EVPNs . . . . . . 6 61 4.1. Condisderations on EVPN Mulicast . . . . . . . . . . . . 6 62 4.2. Condisderations on Other EVPNs . . . . . . . . . . . . . 6 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 7.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 A principal feature of EVPN is the ability to support multi-homing 73 from a customer equipment (CE) to multiple PE with Ethernet segment 74 (ES) links. This draft leverages the egress protection mechanism per 75 [I-D.ietf-rtgwg-srv6-egress-protection] in the multi-homed cases and 76 enhance EVPN convergency on the egress PE node failures, especially 77 for the convergency of BUM packets (Section 3.3). 79 1.1. Terminology and Acronyms 81 Most of the acronyms and terms used in this documents comes from 82 [RFC7432], [RFC8679], [I-D.ietf-bess-srv6-services] and 83 [I-D.ietf-rtgwg-srv6-egress-protection] except for the following: 85 * Mirrored SID - A mirrored SID is a VPN SID which will be installed 86 in the context of a mirror SID (as per 87 [I-D.ietf-rtgwg-srv6-egress-protection]). 89 * bypassed BUM packet - A BUM packet that is received via a mirrored 90 End.DT2M SID. 92 * EVPN SID - SRv6 SID for EVPN Instances, e.g. End.DT2M SID, 93 End.DT2U SID, End.DX2 SID, End.DX2V SID. 95 * NDF - non-DF, non Designated-Forwarder. Note that Backup DF is a 96 special NDF. 98 * NDF-Bias - An exception for filtering bypassed BUM packets. It 99 says that when an outgoing AC is a DF on its ES, the bypassed BUM 100 packets will be dropped but when an outgoing AC is a NDF on its 101 ES, the bypassed BUM packets will not be dropped. 103 * Pairing Route - When IMET_PE3 and IMET_PE4 are two IMET routes of 104 same Bridge Domain, and IMET_PE4 is a local IMET route, while 105 IMET_PE3 is a remote IMET route whose End.DT2M SID is allocated 106 from a remote locator that is protected by a local Mirror SID, we 107 say that IMET_PE4 are paired with IMET_PE3 by the Mirror SID, or 108 just say that IMET_PE4 is IMET_PE3's pairing route. Note that we 109 don't say IMET_PE3 is IMET_PE4's pairing route, because that a 110 local route will have many pairing routes, one per local mirror 111 SID. 113 * ORIP - Originating Router's IP Address, or Originator's IP 114 Address. 116 2. Problem Statement 118 Figure 1 shows an example of protecting egress PE3 of a SR path, 119 which is from ingress PE1 to egress PE3. 121 Locator: A3:1::/64 122 ******* ******* VPN SID: A3:1::B100 123 [PE1]-----[P1]-----[PE3]---[CE2] PE3 Egress 124 / | |& | \ / PE4 Backup Egress 125 / | |& | \ / CEx Customer Edge 126 [CE1] | |& | X Px Non-Provider Edge 127 \ | |& | / \ *** SR Path 128 \ | |& &&&&& | / \ &&& Backup Path 129 [PE2]-----[P2]-----[PE4]---[CE3] 130 Locator: A4:1::/64 131 VPN SID: A4:1::B100 132 Mirror SID: A4:1::3, protect A3:1::/64 134 Figure 1: Egress Protection Scenario 136 In Figure 2, All PEs are EVPN PEs per [RFC7432], and Both CE2 and CE3 137 are dual homed to PE3 and PE4. PE3 has a locator A3:1::/64 and a 138 End.DT2M SID A3:1::B100. PE4 has a locator A4:1::/64 and a End.DT2M 139 SID A4:1::B100. A Mirror SID A4:1::3 is configured on PE4 for 140 protecting a remote locator (PE3's locator) A3:1::/64. P1 has a 141 locator A1:1::/64. CE2 is on Ethernet Segment ES2 whose DF is PE4, 142 non-DF is PE3. CE3 is on Ethernet Segment ES3 whose DF is PE3, non- 143 DF is PE4. Both ES2 and ES3 are all-active mode. 145 After the configuration, PE4 advertises this information through an 146 IGP LS (i.e., LSA in OSPF or LSP in IS-IS), which includes PE3's 147 locator and Mirror SID A4:1::3. Every node in the SR domain will 148 receive this IGP LS, which indicates that PE4 wants to protect PE3's 149 locator with Mirror SID A4:1::3. 151 When PE4 (e.g., BGP on PE4) receives a IMET route IMET_PE3 whose VPN 152 SID belongs to PE3 that is protected by PE4 through Mirror SID 153 A4:1::3, it finds IMET_PE3's VPN SID corresponding to a remote 154 locator (A3:1::/64) which is protected by a local Mirror SID 155 (A4:1::3). Then PE4 find out the corresponding local IMET route (say 156 IMET_PE4) which are paired with IMET_PE3 by the Mirror SID. 158 Note that although PE4 don't have a local IMET route of IMET_PE3, It 159 can know that the IMET_PE3 is for the same EVPN VPLS of a local IMET 160 route IMET_PE4. Because that the IMET_PE3 will be imported into the 161 EVPN VPLS of the IMET_PE4. So the IMET_PE3 is the corresponding 162 route of IMET_PE4 from the Mirror SID's point of view. In other 163 words, we say that IMET_PE4 are paired with IMET_PE3 by the Mirror 164 SID, or just say that IMET_PE4 is IMET_PE3's pairing route. This 165 procedure is different from [I-D.ietf-rtgwg-srv6-egress-protection]. 167 The forwarding behaviors for the VPN SID (PE3's EVPN SID A3:1::B100 168 of End.DT2M Function) of IMET_PE3 are the same as the VPN SID 169 (A4:1::B100) of the local IMET_PE4 from function's point of view. If 170 the behavior for PE3's VPN SID in PE3 forwards the packet with it to 171 CE2, then the behavior for PE4's VPN SID in PE4 forwards the packet 172 to the same CE2; and vice versa. PE4 creates a forwarding entry for 173 PE3's VPN SID A3:1::B100 in the FIB table identified by Mirror SID 174 A4:1::3 according to the forwarding behavior for PE4's VPN SID 175 A4:1::B100. 177 Note that there are two FIB entries for A3:1:B100, one(say FIB_1) is 178 on PE3 , the other(say FIB_2) is on PE4. We call the FIB entry FIB_2 179 as the FIB entry FIB_1's mirrored FIB entry. Because that the FIB_2 180 is in the FIB table identified by a Mirror SID. The SID instance 181 corresponding to a mirrored FIB entry is called as a Mirrored SID. 183 Node P1's pre-computed backup path for destination PE3`s locator is 184 from P1 to PE4 having mirror SID A4:1::3. When P1 receives a packet 185 destined to PE3's VPN SID A3:1::B100, in normal operations, it 186 forwards the packet with source A1:1:: and destination PE3's VPN SID 187 A3:1::B100 according to the FIB using the destination PE3's VPN SID 188 A3:1::B100. 190 When PE3 fails, P1 as PLR sends the packet to PE4 via the backup path 191 pre-computed. P1 encapsulates the packet using H.Encaps before 192 sending it to PE4. 194 When PE4 receives the re-routed packet, it decapsulates the packet 195 and forwards the decapsulated packet by executing End.DT6 behavior 196 for an End.DT6 SID instance. The SID instance is End.M, the Mirror 197 SID that is associated with the IPv6 FIB table for PE3. The packet 198 received by PE4 is (T, Mirror SID A4:1::3) (A1:1::, PE3's VPN SID 199 A3:1::B100)Pkt0. 201 PE4 obtains Mirror SID A4:1::3 in the outer IPv6 header of the 202 packet, removes this outer IPv6 header, and then processes the inner 203 IPv6 packet (A1:1::, A3:1::B100)Pkt0. It finds the FIB table for PE3 204 using Mirror SID A4:1::3 as the context ID, gets the forwarding entry 205 for PE3's VPN SID A3:1::B100 from the table, and forwards the packet 206 to CE2 using the entry. 208 When the SID instance A3:1::B100 is End.DT2M, the Pkt0 is a BUM 209 packet. The Pkt0 will be replicated to CE2 as long as PE4 is the DF 210 of The Pkt0 will be replicated to CE3 as long as PE4 is 211 the DF of 213 Typically, the local-repair on P1 is more faster than the new DFs of 214 ES2 and ES3 are re-elected. So PE4 will still be the DF of untill the DF re-election finishes, and PE4 will still be the 216 non-DF of untill DF the re-election finishes, 218 Note that PE1 will broadcast a BUM packet (say BUM0) to PE3 and PE4 219 separately. One copy of BUM0 which is replicated by PE1 for PE3 is 220 called as BUM3. The other copy of BUM0 which is replicated by PE1 221 for PE4 is called as BUM4. 223 As a result of current DF filtering rules, CE2 will receive both BUM3 224 and BUM4 untill the DF re-election finishes. At the same time, CE3 225 will receive niether BUM3 nor BUM4. 227 3. Solutions 229 3.1. Solution 1: Separate Locators for End.DT2M SIDs 231 The End.DT2M SIDs are not allocated from the same locator with the 232 End.DT2U/End.DX2/End.DX2V SIDs. The locator from where the End.DT2M 233 SIDs are allocated are called as DT2M_LOCATOR. The DT2M_LOCATOR must 234 not be protected by any Mirror SID. 236 This solution can prevent CE2 from receiving excessive BUM packets, 237 but can not help to accelerate the convergence of CE3's BUM packets. 239 3.2. Solution 2: The mirrored End.DT2M SIDs are not installed 241 When the SID instance A3:1::B100 is not installed on PE4, BUM4 will 242 be dropped after PLR's egress protection procedures. 244 Note that a mirrored SID is very different from a Mirror SID. A 245 mirrored SID is a VPN SID which will be installed in the context of a 246 mirror SID as per [I-D.ietf-rtgwg-srv6-egress-protection]. But it 247 must not be installed in this solution. 249 This solution can prevent CE2 from receiving excessive BUM packets, 250 but can not help CE3 to receive one copy of BUM0 as soon as possible. 252 3.3. Solution 3: NDF-Bias Mechanism 254 In order to accelerate the convergence of bypass-BUM packets, some 255 specific rules are defined in the following6: 257 The mirrored End.DT2M SIDs need to be installed, and those BUM 258 packets which is received via a mirrored End.DT2M SID are called as 259 bypass BUM packets. Those bypass BUM packets will not be dropped 260 when they are about to be forwarded to an AC whose DF-role is NDF. 261 Note that the single-homing ACs are always considered as DF-role, so 262 those ACs will filter all bypass BUM packets. Accordingly, those 263 bypass BUM packets will be dropped when they are about to be 264 forwarded to an AC whose DF-role is DF. 266 These rules are called as "NDF-Bias" rules in this draft. 268 This solution can prevent CE2 from receiving excessive BUM packets, 269 at the same time, this solution can accelerate the convergence of 270 CE3's BUM packets. 272 4. Condisderations on EVPN Mulicast and Other EVPNs 274 4.1. Condisderations on EVPN Mulicast 276 The pairing routes for EVPN multicast are two EVPN routes of the same 277 . And they are of the same EVPN 278 route type, while they have different ORIPs. 280 4.2. Condisderations on Other EVPNs 282 Just the recognition methods to pick the bypassed BUM packets out are 283 different. 285 * MPLS EVPN - The bypassed BUM packets will be received over an ILM 286 entry in a context-specific label-space. 288 * VXLAN EVPN - see [I-D.wang-bess-evpn-egress-protection]. 290 5. IANA Considerations 292 no IANA Considerations. 294 6. Security Considerations 296 TBD. 298 7. References 300 7.1. Normative References 302 [I-D.ietf-rtgwg-srv6-egress-protection] 303 Hu, Z., Chen, H., Chen, H., Wu, P., Toy, M., Cao, C., He, 304 T., Liu, L., and X. Liu, "SRv6 Path Egress Protection", 305 Work in Progress, Internet-Draft, draft-ietf-rtgwg-srv6- 306 egress-protection-03, 28 May 2021, 307 . 310 [I-D.ietf-bess-srv6-services] 311 Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., 312 Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based 313 Overlay Services", Work in Progress, Internet-Draft, 314 draft-ietf-bess-srv6-services-07, 11 April 2021, 315 . 318 [RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H., 319 Michel, C., and H. Chen, "MPLS Egress Protection 320 Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019, 321 . 323 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 324 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 325 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 326 2015, . 328 7.2. Informative References 330 [I-D.wang-bess-evpn-egress-protection] 331 Wang, Y. and R. Chen, "EVPN Egress Protection", Work in 332 Progress, Internet-Draft, draft-wang-bess-evpn-egress- 333 protection-04, 29 October 2020, 334 . 337 Authors' Addresses 339 Yubao Wang 340 ZTE Corporation 341 No.68 of Zijinghua Road, Yuhuatai Distinct 342 Nanjing 343 China 345 Email: wang.yubao2@zte.com.cn 347 Ran Chen 348 ZTE Corporation 349 No. 50 Software Ave, Yuhuatai Distinct 350 Nanjing 351 China 353 Email: chen.ran@zte.com.cn