idnits 2.17.1 draft-jiang-bess-evpn-egress-frr-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 -- The document date (June 29, 2020) is 1397 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 (-21) exists of draft-ietf-bess-evpn-igmp-mld-proxy-05 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group J. He, Ed. 3 Internet-Draft X. Li 4 Intended status: Standards Track Z. Zhou 5 Expires: December 31, 2020 H. Qu 6 Ericsson 7 June 29, 2020 9 EVPN Egress Fast ReRoute 10 draft-jiang-bess-evpn-egress-frr-00 12 Abstract 14 Ethernet Virtual Private Network (EVPN) multi-homing accommodates 15 load balance, link/node redundancy and fast convergence. Once link 16 failure happens, egress traffic can be fast rerouted to multi-homed 17 peer(s) to reach CE. However, this fast reroute brings transient 18 loops among multi-homed peers. This document specifies a fast 19 reroute approach with loop prevention. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 31, 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Loop Prevention . . . . . . . . . . . . . . . . . . . . . 4 59 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.1. Constructing EVPN Routes . . . . . . . . . . . . . . . . 4 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 65 7.2. Informative References . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 Ethernet Virtual Private Network (EVPN) multi-homing accommodates 71 load balance, link/node redundancy and fast convergence. Upon link 72 failure, the PE withdraws the corresponding set of Ethernet A-D per 73 ES routes, which triggers all PEs to switchover traffic towards other 74 multi-homed peers for the PE. However, failure propagation still 75 consumes much time. The switchover performance can be improved by 76 using local protection at the same time, called egress Fast ReRoute 77 (eFRR). 79 For example in figure 1, CE1 is multi-homed to PE1 and PE2 with All- 80 Active mode, CE2 and CE3 are single-homed to PE2 and PE3 separately. 81 EVPN VPLS is provided for CE1, CE2,and CE3. 83 In case link failure happens between CE1 and PE2, PE2 withdraws EAD/ 84 ES route for this link which triggers PE3 to switchover traffic 85 towards CE1 from PE2 to PE1. At the same time, traffic towards CE1 86 via PE2 (CE2->CE1 or CE3->CE1) is rerouted to PE1 to reach CE1. The 87 local protection improves the traffic switchover performance. 89 +-----------+ 90 /-------- PE1 | | 91 CE1(AA mode) | EVPN | PE3 --- CE3 92 \-------- PE2 | | 93 | +-----------+ 94 CE2 96 Figure 1 EVPN All-Active multi-homing scenario 98 [RFC8679] specifies a fast reroute approach for egress traffic 99 protection. It defines roles for routers and also procedures among 100 them. However, it only protect traffic from core and it does not 101 define how a unique service label is advertised. This document 102 describes a light weighted approach dedicated for EVPN service, while 103 adding protecting traffic from access link and defining the specific 104 service label advertisement behavior. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 CE: Customer Edge device, e.g., a host, router, or switch. 116 Ethernet Segment (ES): When a customer site (device or network) is 117 connected to one or more PEs via a set of Ethernet links, then 118 that set of links is referred to as an 'Ethernet segment'. 120 EVI: An EVPN instance spanning the Provider Edge (PE) devices 121 participating in that EVPN. 123 EVPN: Ethernet Virtual Private Network. 125 PE: Provider Edge device. 127 NVO: Network Virtualization Overlay. 129 VNI: VXLAN Network Identifier. 131 3. Approach 133 Using figure 1 as an example, when link failure happens between CE1 134 and PE2, on PE2 the rerouted traffic from CE (CE2->CE1 via PE2) is 135 encapsulated with the EVPN label advertised by PE1. For rerouted 136 traffic from EVPN core (CE3->CE1 via PE2), the EVPN label inside is 137 swapped to the one advertised by PE1 also. 139 The EVPN label is from the Ethernet Auto-Discovery Route per EVI or 140 MAC/IP Advertisement Route advertised by PE1. Which label to 141 encapsulate traffic towards PE1 is a local decision on PE2. 143 However, if CE1 fails, PE1 and PE2 try to reroute traffic to each 144 other, which leads to transient loop till EAD/ES withdrawal(s) 145 received by PE1 and/or PE2. This document introduces a loop 146 prevention mechanism to solve the problem. 148 3.1. Loop Prevention 150 When advertise Ethernet Auto-Discovery Route per EVI or MAC/IP 151 Advertisement Route, PE1 allocates one dedicated EVPN label for all 152 PEs (e.g. PE2 here) which share the same multi-homed CE, while 153 allocates another one for all other PEs not multi-homed (e.g. PE3 154 here). Please note if EVPN VPWS, only Ethernet Auto-Discovery Route 155 per EVI is required. 157 When PE2 detects link towards CE1 fails (regardless of CE node 158 failure or only link failure), it encapsulates traffic towards CE1 159 using the dedicated EVPN label advertised by PE1 and reroutes to PE1. 160 On PE1, the multi-homed peer, based on the EVPN label encapsulated, 161 the rerouted traffic is identified as from peer. If PE1 detects link 162 towards CE1 fails, the traffic from peer will not be rerouted but 163 simply discarded. Thus loop is avoided. If no link failure, the 164 traffic from PE1 is forwarded to CE1. 166 The mechanism also works for NVO scenarios [RFC8365], where the label 167 mentioned above will be referred to as the VNI. 169 4. Procedures 171 4.1. Constructing EVPN Routes 173 In order to assign dedicated EVPN label for all PEs which share the 174 same multi-homed CE, when advertising Ethernet Auto-Discovery Route 175 per EVI or MAC/IP Advertisement Route, the PE MUST carry exactly one 176 ES-Import Route Target extended community. It MUST also carry 177 exactly one EVI-RT Extended Community (EC) as defined in 178 [I-D.ietf-bess-evpn-igmp-mld-proxy]. 180 EVI-RT EC is an Extended Community that can be used to identify the 181 EVI with which an EVPN route is associated. But it is not a Route 182 Target Extended Community, is not visible to the RT Constrain 183 mechanism [RFC4684], and is not intended to influence the propagation 184 of EVPN routes by BGP. 186 The combination of the ES-Import RT and EVI-RT EC guarantees the EVPN 187 routes to be distributed only to PEs that share the same multi-homed 188 CE for a specific EVPN instance. If the EVPN route has no EVI-RT EC, 189 or has more than one EVI-RT EC, the PE MUST apply the "treat-as- 190 withdraw" procedure of [RFC7606]. 192 It is suggested to set a higher LOCAL_PREF value in the BGP message 193 for the EVPN routes, considering if another general EVPN route is 194 also advertised to all PEs, for example, through BGP Route Reflector. 196 5. IANA Considerations 198 No requests to the IANA by this document. 200 6. Security Considerations 202 Same security considerations as [RFC7432]. 204 7. References 206 7.1. Normative References 208 [I-D.ietf-bess-evpn-igmp-mld-proxy] 209 Sajassi, A., Thoria, S., Patel, K., Drake, J., and W. Lin, 210 "IGMP and MLD Proxy for EVPN", draft-ietf-bess-evpn-igmp- 211 mld-proxy-05 (work in progress), April 2020. 213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 214 Requirement Levels", BCP 14, RFC 2119, 215 DOI 10.17487/RFC2119, March 1997, 216 . 218 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 219 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 220 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 221 2015, . 223 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 224 Patel, "Revised Error Handling for BGP UPDATE Messages", 225 RFC 7606, DOI 10.17487/RFC7606, August 2015, 226 . 228 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 229 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 230 May 2017, . 232 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 233 Uttaro, J., and W. Henderickx, "A Network Virtualization 234 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 235 DOI 10.17487/RFC8365, March 2018, 236 . 238 7.2. Informative References 240 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 241 R., Patel, K., and J. Guichard, "Constrained Route 242 Distribution for Border Gateway Protocol/MultiProtocol 243 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 244 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 245 November 2006, . 247 [RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H., 248 Michel, C., and H. Chen, "MPLS Egress Protection 249 Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019, 250 . 252 Authors' Addresses 254 Jiang He (editor) 255 Ericsson 256 No. 5, Lize east street, Chaoyang district 257 Beijing 100102 258 CN 260 Email: jiang.he@ericsson.com 262 Xianmin Li 263 Ericsson 264 No. 5, Lize east street, Chaoyang district 265 Beijing 100102 266 CN 268 Email: xianmin.li@ericsson.com 270 Zhe Zhou 271 Ericsson 272 No. 5, Lize east street, Chaoyang district 273 Beijing 100102 274 CN 276 Email: zhe.zhou@ericsson.com 277 Haifeng Qu 278 Ericsson 279 No. 5, Lize east street, Chaoyang district 280 Beijing 100102 281 CN 283 Email: haifeng.qu@ericsson.com