idnits 2.17.1 draft-jiang-bess-evpn-split-horizon-enhancement-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 3, 2020) is 1416 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 B. Nie 4 Intended status: Standards Track Ericsson 5 Expires: December 5, 2020 June 3, 2020 7 EVPN Split Horizon Filtering Enhancement 8 draft-jiang-bess-evpn-split-horizon-enhancement-00 10 Abstract 12 Ethernet Virtual Private Network (EVPN) multi-homing accommodates 13 load balance, link/node redundancy and fast convergence. The split 14 horizon filtering in EVPN avoids loop happens on multi-homed CE. 15 However, this mechanism brings challenges switching chipsets on data 16 plane. This document describes an approach for the challenges by 17 enhancing current split horizon filtering mechanism. The advantage 18 of this approach is that it simplifies data plane behaviors. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 5, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Advertising EVPN VRF Route Import Extended Community . . 4 59 4.2. Constructing IMET Routes . . . . . . . . . . . . . . . . 4 60 4.3. Flooding Handling on Data Plane . . . . . . . . . . . . . 5 61 5. EVPN VRF Route Import Extended Community . . . . . . . . . . 5 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 6.1. EVPN VRF Route Import Extended Community . . . . . . . . 6 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 Ethernet Virtual Private Network (EVPN) multi-homing accommodates 71 load balance, link/node redundancy and fast convergence. The split 72 horizon filtering in EVPN avoids loop happens on multi-homed CE. In 73 particular, there are two split horizon filtering mechanisms to avoid 74 looped frames on the multi-homed CE: ESI Label based [RFC7432] for 75 MPLS based tunnels and Local Bias[RFC8365] for non-MPLS NVO tunnels, 76 E.g. VXLAN tunnels. 78 However, each mechanism introduces challenges for data plane because 79 extra logic is introduced but not available on some typical switching 80 chipsets. ESI Label based mechanism requires ingress PE to push ESI 81 label into MPLS stack to indicate Ethernet Segment Identifier, and 82 requires egress PE to filter out the corresponding port based on ESI 83 label before flooding. Local Bias does not require ingress PE to 84 have extra procedure but still requires egress PE to filter out the 85 corresponding ports based on source IP address before flooding. 87 This document describes an approach towards the challenges, by 88 enhancing current Local Bias split horizon filtering mechanism, for 89 MPLS based tunnels and non-MPLS NVO tunnels. The advantage of this 90 approach is that it simplifies data plane behaviors. 92 2. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in BCP 97 14 [RFC2119] [RFC8174] when, and only when, they appear in all 98 capitals, as shown here. 100 BUM: Broadcast, Unknown unicast and Multicast 102 CE: Customer Edge device, e.g., a host, router, or switch. 104 Ethernet Segment (ES): When a customer site (device or network) is 105 connected to one or more PEs via a set of Ethernet links, then 106 that set of links is referred to as an 'Ethernet segment'. 108 Ethernet Segment Identifier (ESI): A unique non-zero identifier 109 that identifies an Ethernet segment is called an 'Ethernet Segment 110 Identifier'. 112 EVI: An EVPN instance spanning the Provider Edge (PE) devices 113 participating in that EVPN. 115 EVPN: Ethernet Virtual Private Network 117 NVO: Network Virtualization Overlay 119 PE: Provider Edge device. 121 VXLAN: Virtual Extensible LAN 123 NVGRE: Network Virtualization using Generic Routing Encapsulation 125 VNI: VXLAN Network Identifier 127 VSID: Virtual Subnet Identifier (for NVGRE) 129 3. Approach 131 When the PE advertises Inclusive Multicast Ethernet Tag (IMET) Routes 132 to PEs which share the same multi-homed CE, it allocates unique label 133 for each PE, rather than using the same label for all PEs. To 134 accomplish this, An EVPN VRF Route Import Extended Community is 135 introduced. 137 When the PE receives BUM packet from ingress PE, based on the BUM 138 label encapsulated, it can determine the packet is from PEs which 139 share the same multi-homed CE or not. If yes, the PE can also 140 determine which PE the packet is from. Because the PE has determined 141 the ingress PE, Local Bias based mechanism can be implemented for 142 split horizon filtering without source IP information, but simply 143 based on a single BUM label to determine the flooding scope. 145 For NVO solution, this approach requires locally assigned VNIs to be 146 used just like downstream-assigned MPLS labels. 148 Based on this extended mechanism, for MPLS based tunnels, no ESI 149 label encapsulation is required on ingress PE either. 151 4. Procedures 153 Let's suppose an EVPN network, where CE1 is multi-homed to PE1 and 154 PE2 with all-active mode, CE2 and CE3 are single-homed to PE2 and PE3 155 separately. 157 +--------------+ 158 /--- PE1 | | 159 CE1 | EVPN | PE3 --- CE3 160 \--- PE2 | | 161 | +--------------+ 162 CE2 164 Figure 1: Sample EVPN Multi-homing Scenario 166 4.1. Advertising EVPN VRF Route Import Extended Community 168 In order to receive IMET route with unique label assigned by multi- 169 homed peer, each VRF on PE1 MUST have an import Route Target Extended 170 Community, and communicate the value to all other multi-homed peers. 172 We refer to this Route Target as the "EVPN IMET Import RT", as this 173 Route Target controls imports of EVPN IMET routes into a particular 174 VRF. 176 To communicate the value to all other multi-homed peers, PE1 when 177 advertising an Ethernet Auto-discovery Route per EVI SHALL carry the 178 EVPN VRF Route Import Extended Community (as defined in Section 5) 179 that has the value of the EVPN IMET Import RT of the VRF associated 180 with the route. 182 4.2. Constructing IMET Routes 184 Once EVPN routes with EVPN VRF Route Import Extended Community 185 received on PE2, PE2 extracts the value of the EVPN VRF Route Import 186 Extended Community. The value of EVPN IMET Import RT is set to this 187 value. 189 Besides advertising IMET routes to other PEs as usual, PE2 advertises 190 IMET route with unique BUM label to each multi-homed peer (here only 191 PE1) by using EVPN IMET Import RT as route target. It is suggested 192 to set a higher LOCAL_PREF for this BGP message, if another general 193 IMET route is sent to PE1 also. 195 Now suppose PE3 receives IMET route with label BUM0 from PE2, and PE1 196 receives IMET route with label BUM1 from PE2. 198 4.3. Flooding Handling on Data Plane 200 Once PE2 advertises all IMET routes, including general and unique 201 ones, it sets data plane to handle BUM labels as figure 2 described 202 below (Suppose it is the Designated Forwarder). 204 +-----------+-------------+ 205 | In Label | Out Ports | 206 +-----------+-------------+ 207 (from PE3) -> | BUM0 | CE1, CE2 | 208 +-----------+-------------+ 209 (from PE1) -> | BUM1 | CE2 | 210 +-----------+-------------+ 212 Figure 2: Flooding handling on PE2 Data Plane 214 Now BUM traffic is properly handled, no matter from multi-homed peers 215 (E.g. PE1) or other PEs (E.g. PE3). Unlike ESI Label based or 216 Local Bias which requires two parameters for flooding decision, this 217 flooding behavior requires only one parameter, the single BUM label. 219 5. EVPN VRF Route Import Extended Community 221 This document defines a new BGP Extended Community called "EVPN VRF 222 Route Import". 224 The EVPN VRF Route Import is an IP-address-specific Extended 225 Community, of an extended type, and is transitive across AS 226 boundaries [RFC4360]. 228 The EVPN VRF Route Import Extended Community has following format: 230 0 1 2 3 231 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Type=0x06 | Sub-Type=TBD | Global Administrator | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Global Administrator (cont.) | Local Administrator | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 This document expands the definition of EVPN Extended Community 238 [RFC7153]. This Extended Community has a Type field value of 0x06 239 and the Sub-Type TBD. 241 The Global Administrator field of the EVPN VRF Route Import EC MUST 242 be set to an IP address of the PE. This address SHOULD be common for 243 all the VRFs on the PE (e.g., this address may be the PE's loopback 244 address).The Local Administrator field of the EVPN VRF Route Import 245 EC associated with a given VRF contains a 2-octet number that 246 uniquely identifies that VRF within the PE. 248 For procedures and usage of this attribute, please see Section 4 250 6. IANA Considerations 252 6.1. EVPN VRF Route Import Extended Community 254 This document makes the following registrations for EVPN VRF Route 255 Import Extended Community. 257 Type Description 258 ---- ----------- 259 TBD EVPN VRF Route Import Extended Community 261 7. Security Considerations 263 If BGP is used as a CE-PE routing protocol, then when a PE receives a 264 route from a CE, if this route carries the EVPN VRF Route Import 265 Extended Community, the PE MUST remove this Community from the route 266 before turning it into a VPF. Routes that a PE advertises to a CE 267 MUST NOT carry the EVPN VRF Route Import Extended Community. 269 8. Normative References 271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 272 Requirement Levels", BCP 14, RFC 2119, 273 DOI 10.17487/RFC2119, March 1997, 274 . 276 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 277 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 278 February 2006, . 280 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 281 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 282 March 2014, . 284 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 285 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 286 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 287 2015, . 289 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 290 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 291 May 2017, . 293 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 294 Uttaro, J., and W. Henderickx, "A Network Virtualization 295 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 296 DOI 10.17487/RFC8365, March 2018, 297 . 299 Authors' Addresses 301 Jiang He (editor) 302 Ericsson 303 No. 5, Lize east street, Chaoyang district 304 Beijing 100102 305 CN 307 Email: jiang.he@ericsson.com 309 Bolin Nie 310 Ericsson 311 No. 5, Lize east street, Chaoyang district 312 Beijing 100102 313 CN 315 Email: zephyr.nie@ericsson.com