idnits 2.17.1 draft-saumvinayak-bess-all-df-bum-02.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 ([RFC8584], [RFC7432]), 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 (6 March 2022) is 782 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) == Unused Reference: 'RFC7348' is defined on line 273, but no explicit reference was found in the text == Unused Reference: 'RFC9014' is defined on line 286, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS WG S. Dikshit 3 Internet-Draft V. Joshi 4 Intended status: Standards Track Aruba, HPE 5 Expires: 7 September 2022 6 March 2022 7 All PEs as DF 8 draft-saumvinayak-bess-all-df-bum-02 10 Abstract 12 The Designated forwarder concept is leveraged to prevent looping of 13 BUM traffic into tenant network sourced across NVO fabric for 14 multihoming deployments. [RFC7432] defines a prelimn approach to 15 select the DF for an ES,VLAN or ES,Vlan Group panning across multiple 16 NVE's. [RFC8584] makes the election logic more robust and fine 17 grained inculcating fair election of DF handling most of the 18 prevalent use-cases. This document presents a deployment problem and 19 a corresponding solution which cannot be easily resolve by rules 20 mentioned in [RFC7432] and [RFC8584]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 7 September 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Important Terms . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 58 4. Problem Description . . . . . . . . . . . . . . . . . . . . . 3 59 5. Solution(s) . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 5.1. Sending All PEs are DF mode . . . . . . . . . . . . . . . 4 61 5.2. Receive All PEs are DF mode . . . . . . . . . . . . . . . 5 62 5.3. Example of algorithm . . . . . . . . . . . . . . . . . . 5 63 6. Interoperability with other Algos . . . . . . . . . . . . . . 5 64 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 6 65 8. Impact on Local Bias . . . . . . . . . . . . . . . . . . . . 6 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 69 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 12.1. Normative References . . . . . . . . . . . . . . . . . . 6 71 12.2. Informative References . . . . . . . . . . . . . . . . . 6 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Important Terms 76 DF: Designated Forwarder as defined in [RFC7432]. 78 VTEP: Virtual Tunnel End Point or Vxlan Tunnel End Point 80 2. Introduction 82 The Designated forwarder concept is leveraged to prevent looping of 83 BUM traffic into tenant network sourced across NVO fabric for 84 multihoming deployments. [RFC7432] defines a prelimn approach to 85 select the DF for an ES,VLAN or ES,Vlan Group panning across multiple 86 NVE's. [RFC8584] makes the election logic more robust and fine 87 grained inculcating fair election of DF handling most of the 88 prevalent use-cases. This document presents a deployment problem and 89 a corresponding solution which cannot be easily resolve by rules 90 mentioned in [RFC7432] and [RFC8584]. 92 3. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 When used in lowercase, these words convey their typical use in 99 common language, and they are not to be interpreted as described in 100 [RFC2119]. 102 4. Problem Description 104 It's a typical case of Firewall devices also configured as default 105 gateway for the NVO fabric or default gateways inturn redirect 106 traffic to firewalls over shared vlan. This example for simplicity 107 assumes the former case wherein firewall is also configured as 108 default gateway for all VLANs in the site (SITE-1 and SITE-2). 110 All PEs(Vtep1 and Vtep2 in below example) in the diagram are attached 111 to same ES and both intend to act act as DF for the broadcast domain 112 (BD-1) for their respective sites. As already mentioned, this is a 113 typical case of firewall-gatewaus (active/active) across fabrics 114 (sites), Where in, the preferred firewall-gateway is the one local to 115 the site, whereas, upon failure, packets need to be redirected (over 116 WAN, via DCI/VPN) towards the remote site firewall. The firewall- 117 device is connected to it's first-hop vtep over the same bridge- 118 domain and same ESI. All in all, it's an emulated multi-homing 119 scenario. This is a scenario of firewall devices hosting same(IP and 120 MAC) credentials. 122 Simplistic example : There are two sites, SITE-1 and SITE-2 in the 123 below diagram. Traffic (including BUM) generated by Host1 (in SITE- 124 1) (for a bridge-domain) should run through site-local firewall 125 instance (firewall_1) preferably. Only in case of local-outage, the 126 traffic should be send across over WAN to the remote firewall 127 (firewall_2). Same should apply to traffic generated by Host2 (in 128 SITE-2), wherein, it should preferably run through the local firewall 129 (firewall_2) and over a failure should go over the WAN towards 130 firewall_1. 132 Vtep1/2 learn the firewall MAC (MAC_F) as local learning and also 133 from the remote Vtep2/1. But since both the learnings are over the 134 same ESI, it should not lead to MAC move. Cometh the local firewall 135 failure, Vteps (1 or 2) should start redirecting the traffic to 136 remote SITE. Any ARP request (BUM traffic) for firewall credentials 137 landing at either Vtep1 or Vtep2 should be flooded to network towards 138 the local firewall. 140 SITE-1 | SITE-2 141 ------------------------------------------------------ 142 Host1 Host2 143 \ / 144 \ / 145 Vtep_host1 Vtep_host2 146 | | 147 | [ EVPN-fabric ] | 148 | | 149 Vtep1============WAN==============Vtep2 150 / \ 151 / \ 152 Firewall _1 Firewall_2 153 (MAC_F) (MAC_F) 155 Figure 1: Figure 1: Active-Active Firewall Across Sites 157 5. Solution(s) 159 The control plane part of the solution can be leveraged from the 'DF 160 Election Extended Community' described in [RFC8584]. Since the 161 requirement is to ensure all the PEs attached to ESI forward the BUM 162 traffic arriving from NVO fabric towards the Attachment circuits 163 (ACs) configured over the ES for a BD (broadcast domain) mapped to 164 Vlan or bundle of Vlans. As explained in the above section that this 165 is a case where PEs are in disparate networks and the ACs behind them 166 are not connected to each other to a common physical device. 168 This document proposes a new mode of DF-election, ALL-PEs-DF where-in 169 all of the pariticipating PEs intend to play DF role for a vlan(s) 170 enabled on an ESI. This requires "DF Election Extended Community" to 171 carry this information with the ES route to indicate it to remote 172 PEs. This ensures all PEs receiving BUM traffic over NVO fabric 173 destined to ESI, BD, SHOULD flood it on the associated ES on the 174 access/tenant side. PE MAY be explicitly configured to choose the 175 ALL-PEs-DF mode. 177 5.1. Sending All PEs are DF mode 179 The All-PEs-DF mode is used as follows: 181 (1) PEs configured to use ALL-PEs-DF mode SHOULD set "DF Alg" 182 algorithm field in 'DF Election Extended Community' to 183 appropriate value. 185 (2) This document proposes value '2' for All-PEs-DF mode, as values 186 '0' and '1' are already defined for usage in [RFC8584]. 188 (3) This algorithm is agnostic to the values carried in 'Bitmap' but 189 does not discounts any use-case(s) in future which may need 190 extra information carried in 'Bitmap' along with All-PEs-DF 191 mode. 193 5.2. Receive All PEs are DF mode 195 When a PE receives the ES routes from all the other PEs for the ES in 196 question carrying the ALL-PEs-DF mode set in 'DF Election Extended 197 Community', it SHOULD checks to see if all the advertisements have 198 the Extended Community with 'All-DF-mode' set as 'DF Alg'. If yes, 199 then SHOULD ignore the 'Bitmap' and 'Rsvd' field in the extended 200 community. As also mentioned in [RFC8584] , if even a single 201 advertisement for Route Type 4 is received without the locally 202 configured DF Alg and capability, the default DF election algorithm 203 MUST be used as prescribed in [RFC7432]. 205 5.3. Example of algorithm 207 The BGP-EVPN control plane support prescribed in this document helps 208 in resolving the problem decsribed in Section 4. If PEs Vtep1 and 209 Vtep2 are configured to use ALL-PEs-DF mode, then any BUM traffic 210 from respective hosts Host1/Host2 over the EVPN fabric, should get 211 broadcasted towards the AC for the ESI, Vlan to which the firewall_1/ 212 firewall_2 (respectively) is attached. For example the arp-request 213 for the Firewall IP will be honored by the Firewall_1 behind the 214 Vtep1 which receives the ARP-request, whereas, when Vtep2 receives 215 the arp-request it will be honored by Firewall_2. Vtep1 and Vtep2 216 will publish the arp-request in their respective ACs attached to the 217 firewall on which Vlan, ESI is enabled 219 6. Interoperability with other Algos 221 Since All-DF-algo is special mode and not exactly an algorithm, which 222 requires the participation of all PEs for an ESI, VLAN. Hence, even 223 if one PE publishes an algo which is NOT "All-DF-mode", other PEs 224 SHOULD revert back to default algorithm. The reason being that, if 225 there are PE1, PE2, PE3 and PE4 in contention. PE1 and PE2 publishes 226 DF Algo 'ALL-PEs-DF', PE3 publishes '0' and PE4 publishes '1'. Once 227 this mismatch is perceived, all PEs SHOULD try and converge towards 228 the default mode. An admin intervention may be required to achieve 229 the same or to converge on any other supported 'DF Algo'. 231 7. Backward Compatibility 233 As prescribed in [RFC8584], PEs not supporting (hence not publishing) 234 'ALL-PEs-DF', SHOULD ignore the processing of the 'DF Election 235 Extended Community' and SHOULD indulge in DF-election using the 236 default aglorithm mentioned in [RFC7432]. The PEs configured with 237 this new alogrithm (hence publishing it), if receive Route Type 4 238 without 'DF Election Extended Community', SHOULD also revert back to 239 default algorithm. If PEs receive Route Type 4 with another 240 algorithm published in 'DF Election Extended Community', then it 241 should follow procedures prescribed in Section 6. 243 8. Impact on Local Bias 245 There is no impact on the local-bias handling, as the PE receiving 246 the BUM from access side over {ESI, VLAN} and relays it to other PEs 247 that published {ESI, VLAN} in Route Type 4; the receiving side PEs 248 will not relay it to EVPN fabric nor will they redirect it to same 249 ESI configured with same VLAN on the access/tenant side. 251 9. Security Considerations 253 This document inherits all the security considerations discussed in 254 [RFC7432] and [RFC8584]. 256 10. IANA Considerations 258 This document inherits all the IANA considerations discussed in 259 [RFC7432] and [RFC8584]. 261 11. Acknowledgements 263 12. References 265 12.1. Normative References 267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, March 1997, 269 . 271 12.2. Informative References 273 [RFC7348] Mahalingam, M., "Virtual eXtensible Local Area Network 274 (VXLAN): A Framework for Overlaying Virtualized Layer 2 275 Networks over Layer 3 Networks", RFC 7348, August 2014, 276 . 278 [RFC7432] Sajassi, A., "BGP MPLS-Based Ethernet VPN", RFC 7432, 279 February 2015, 280 . 282 [RFC8584] Rabadan, J., "Framework for Ethernet VPN Designated 283 Forwarder Election Extensibility", RFC 8584, April 2019, 284 . 286 [RFC9014] Rabadan, J., "Interconnect Solution for Ethernet VPN 287 (EVPN) Overlay Networks", RFC 9014, May 2021, 288 . 290 Authors' Addresses 292 Saumya Dikshit 293 Aruba Networks, HPE 294 Mahadevpura 295 Bangalore 560 048 296 Karnataka 297 India 298 Email: saumya.dikshit@hpe.com 300 Vinayak Joshi 301 Aruba Networks, HPE 302 Mahadevpura 303 Bangalore 560 048 304 Karnataka 305 India 306 Email: vinayak.joshi@hpe.com