Network Working Group S. Dikshit Internet-Draft V. Joshi Intended status: Standards Track C. Lin Expires: 27 January 2027 Aruba, HPE / Oracle New H3C Technologies 27 July 2026 All PEs as DF draft-saumvinayak-bess-all-df-bum-13 Abstract The Designated Forwarder concept is leveraged to prevent looping of BUM traffic into a tenant network sourced across an NVO fabric for multihoming deployments. [RFC7432] defines a preliminary approach to select the DF for an ES, VLAN or ES, VLAN Group, spanning multiple NVEs. [RFC8584] makes the election logic more robust and fine grained by inculcating fair election of DF, handling most of the prevalent use cases. This document presents a deployment problem and a corresponding solution which cannot be easily resolved by rules mentioned in [RFC7432] and [RFC8584]. It involves redundant firewall deployment on disparate overlay sites connected over WAN. The requirement is to allow reachability, ONLY, to the local firewall, unless there is an outage. In case of outage the reachability can be extended to the remote site's firewall over WAN. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 27 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Important Terms 2. Introduction 3. Requirements Language 4. Problem Description 4.1. Problem Example 5. Solution(s) 5.1. Sending All PEs are DF mode 5.2. Receive All PEs are DF mode 5.3. Example of algorithm 6. Interoperability with other Algos 7. Backward Compatibility 8. Impact on Local Bias 9. Security Considerations 10. IANA Considerations 11. Acknowledgements 12. References 12.1. Normative References 12.2. Informative References Authors' Addresses 1. Important Terms DF: Designated Forwarder as defined in [RFC7432]. VTEP: Virtual Tunnel End Point or Vxlan Tunnel End Point 2. Introduction The Designated Forwarder concept is leveraged to prevent looping of BUM traffic into a tenant network sourced across an NVO fabric for multihoming deployments. [RFC7432] defines a preliminary approach to select the DF for an ES, VLAN or ES, VLAN Group, spanning multiple NVEs. [RFC8584] makes the election logic more robust and fine grained by inculcating fair election of DF, handling most of the prevalent use cases. This document presents a deployment problem and a corresponding solution which cannot be easily resolved by rules mentioned in [RFC7432] and [RFC8584]. It involves redundant firewall deployment on disparate overlay sites connected over WAN. The requirement is to allow reachability, ONLY, to the local firewall, unless there is an outage. In case of outage the reachability can be extended to the remote site's firewall over WAN. [RFC8584] has since been extended by other per-flow/per-group DF Algorithm proposals, including per-multicast-flow DF election ([I-D.ietf-bess-evpn-per-mcast-flow-df-election], now a WG document) and per-unicast-flow DF election ([I-D.kriswamy-bess-evpn-perflow- df]). ALL-PEs-DF addresses a distinct use case from both -- simultaneous active-active BUM forwarding by every PE on an Ethernet Segment, for redundant firewall/gateway deployments -- and is compatible with, rather than a substitute for, those flow-splitting extensions. 3. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. When used in lowercase, these words convey their typical use in common language, and they are not to be interpreted as described in [RFC2119]. 4. Problem Description It's a typical deployment case of Firewall devices, also configured as default gateway for the NVO fabric. The default gateways in turn redirect traffic to firewalls over a shared VLAN. This example, for simplicity, assumes the former case wherein the firewall is also configured as the default gateway for all VLANs on the site (SITE-1 and SITE-2). All PEs (Vtep1 and Vtep2 in the below example) in the diagram are attached to the same ES and both intend to act as DF for the broadcast domain (BD-1) for their respective sites. As already mentioned, this is a typical case of firewall-gateways (active/ active) across fabrics (sites). The preferred firewall-gateway is the one local to the site. All ARP broadcast requests generated for the gateway are directed to the local firewall and NOT to the remote one. Whereas, upon failure of the local firewall, all packets originating from the affected site, including broadcast packets like ARP requests, need to be redirected (over WAN, via DCI/VPN) towards the remote site firewall. The firewall device is connected to its first-hop VTEP over the same bridge-domain and same ESI across all sites. All in all, it's an emulated multi-homing scenario. This is a scenario of firewall devices hosting the same (IP and MAC) credentials. 4.1. Problem Example The following details out the problem further. There are two sites, SITE-1 and SITE-2, in the below diagram. Traffic (including BUM) generated by Host1 (in SITE-1), for a bridge-domain, should run through the site-local firewall instance (firewall_1) preferably and should not be leaked to the remote sites. Only in case of local outage, the traffic should be sent across over WAN to the remote firewall (firewall_2). Same should apply to traffic generated by Host2 (in SITE-2), wherein it should ONLY run through the local firewall (firewall_2), unless there is a local firewall outage. In that case it should go over the WAN towards the remote site's firewall, firewall_1. Vtep1 and/or Vtep2 learn the firewall MAC (MAC_F) as a local host learning and also from the remote VTEPs, Vtep2 and Vtep1, respectively. But since both the learnings are over the same ESI, it should not lead to a MAC move. Come the local firewall failure, Vtep1 or Vtep2 should start redirecting the traffic to the remote SITE firewall, firewall_2 and firewall_1, respectively. Any ARP request (BUM traffic) for firewall credentials landing at either Vtep1 or Vtep2 from the remote fabric should then be flooded to the network or LAN towards the locally connected firewall. SITE-1 SITE-2 ------------------------------------------------------ Host1 Host2 \ / \ / Vtep_host1 Vtep_host2 | | | [ EVPN-fabric ] | | | Vtep1============WAN==============Vtep2 / \ / \ Firewall_1 Firewall_2 (MAC_F) (MAC_F) Figure 1: Active-Active Firewall Across Sites 5. Solution(s) The control plane part of the solution can be leveraged from the 'DF Election Extended Community' described in [RFC8584]. Since the requirement is to ensure all the PEs attached to the ESI forward the BUM traffic arriving from hosts connected to the local NVO fabric towards the Attachment Circuits (ACs) that are configured over the ES for a BD (broadcast or bridge domain) mapped to a VLAN or bundle of VLANs. As explained in the above section, this is a case where PEs are in disparate networks and the ACs behind them are not connected to a common physical device, even though they are part of the same ES. The diagram gives an overview of the network or deployment in contention. This document proposes a new mode of DF-election called 'ALL-PEs-DF', wherein all the participating PEs intend to play the DF role for a subset of VLAN(s) enabled on an ESI. This requires the "DF Election Extended Community" to carry this information with the ES route to indicate it to remote PEs. This ensures all PEs receiving BUM traffic over the NVO fabric destined to ESI, BD, SHOULD flood it on the associated ES on the access/tenant side. A PE device MAY be explicitly configured to choose the ALL-PEs-DF mode. 5.1. Sending All PEs are DF mode The All-PEs-DF mode is used as follows: (1) PEs configured to use ALL-PEs-DF mode SHOULD set the "DF Alg" algorithm field in the 'DF Election Extended Community' to the appropriate value. (2) This document proposes value TBD3 for All-PEs-DF mode (see Section 10), as values '0', '1' and '2' are already reserved for usage. (3) This algorithm is agnostic to the values carried in 'Bitmap' but does not discount any use case(s) in the future which may need extra information carried in 'Bitmap' along with the All-PEs-DF mode. 5.2. Receive All PEs are DF mode When a PE receives the ES routes from all the other PEs, for the ES in question, carrying the ALL-PEs-DF mode set, in the 'DF Election Extended Community', it SHOULD check to see if all the advertisements have the Extended Community with 'All-DF-mode' set as 'DF Algo'. If yes, then the PE SHOULD ignore the 'Bitmap' and 'Rsvd' fields in the extended community. As also mentioned in [RFC8584], even if a single advertisement for Route Type 4 is received without the locally configured DF Alg and capability, the default DF election algorithm MUST be used as mandated in [RFC7432]. 5.3. Example of algorithm The BGP-EVPN control plane extension, as mentioned in this document, helps in resolving the problem described in Section 4. If PEs, Vtep1 and Vtep2, are configured to use ALL-PEs-DF mode, then any BUM traffic from respective local hosts Host1/Host2 connected to the EVPN fabric SHOULD get redirected towards the AC for the ESI, VLAN to which the firewall_1/firewall_2 (respectively) is attached. For example, the ARP-request for the Firewall IP will be honored by Firewall_1 behind Vtep1 which receives the ARP-request. Whereas, when Vtep2 receives the ARP-request it will be honored by Firewall_2. Vtep1 and Vtep2 will publish the ARP-request in their respective ACs attached to the firewall on which VLAN, ESI is configured and enabled. 6. Interoperability with other Algos Since the All-DF-algo is a special mode and not exactly an algorithm, it requires the participation of all PEs for an ESI, VLAN. Hence, even if one PE publishes an algo which is NOT "All-DF-mode", other PEs SHOULD revert back to the default algorithm. The reason being that if there are PE1, PE2, PE3 and PE4 in contention -- PE1 and PE2 publish DF Algo 'ALL-PEs-DF', PE3 publishes '0' and PE4 publishes '1' -- once this mismatch is perceived, all PEs SHOULD try and converge towards the default mode. An admin intervention may be required to achieve the same or to converge on any other supported 'DF Algo'. 7. Backward Compatibility As prescribed in [RFC8584], PEs not supporting (hence not publishing) 'ALL-PEs-DF' SHOULD ignore the processing of the 'DF Election Extended Community' and SHOULD indulge in DF-election using the default algorithm mentioned in [RFC7432]. The PEs configured with this new algorithm (hence publishing it), if they receive Route Type 4 without the 'DF Election Extended Community', SHOULD also revert back to the default algorithm. If PEs receive Route Type 4 with another algorithm published in the 'DF Election Extended Community', then it should follow the procedures prescribed in Section 6. 8. Impact on Local Bias There is no impact on the local-bias handling, as the PE receiving the BUM from the access side over {ESI, VLAN} and relaying it to other PEs that published {ESI, VLAN} in Route Type 4; the receiving side PEs will not relay it to the EVPN fabric nor will they redirect it to the same ESI configured with the same VLAN on the access/ tenant side. 9. Security Considerations This document inherits all the security considerations discussed in [RFC7432] and [RFC8584]. 10. IANA Considerations This document defines a new DF Election Algorithm, "ALL-PEs-DF", extending the "DF Alg" registry created by [RFC8584]. IANA is requested to allocate a new value from that registry as follows: Alg Name Reference --- --------------------------------- ------------- TBD3 ALL-PEs-DF This document This document suggests value 7 as a placeholder, chosen to avoid a collision with the concurrently-requested value 6 ("Per-flow") in [I-D.kriswamy-bess-evpn-perflow-df]; the authors note that both documents are individual drafts requesting new codepoints from the same small registry at roughly the same time, and recommend that IANA/the BESS WG coordinate final value assignment between the two documents (and any other concurrent DF Alg registry requests, e.g. [I-D.ietf-bess-evpn-per-mcast-flow-df-election]) rather than treat this as a placeholder to defer indefinitely. 11. Acknowledgements The authors want to thank Jorge Rabadan and Luc Andre for their valuable comments. They also advised on other potential solutions while helping in paraphrasing the problem statement. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . 12.2. Informative References [RFC7348] Mahalingam, M., "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, August 2014, . [RFC7432] Sajassi, A., Ed., "BGP MPLS-Based Ethernet VPN", RFC 7432, February 2015, . [RFC8584] Rabadan, J., Ed., "Framework for Ethernet VPN Designated Forwarder Election Extensibility", RFC 8584, April 2019, . [RFC9014] Rabadan, J., Ed., "Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks", RFC 9014, May 2021, . [I-D.kriswamy-bess-evpn-perflow-df] Ananthamurthy, K., Sajassi, A., and L. Krattiger, "Per-Flow EVPN Designated Forwarder Election", Work in Progress, draft-kriswamy-bess-evpn-perflow-df-02, 22 July 2026. [I-D.ietf-bess-evpn-per-mcast-flow-df-election] "Per Multicast Flow Designated Forwarder Election for EVPN", Work in Progress, draft-ietf-bess-evpn-per-mcast- flow-df-election-13. Authors' Addresses Saumya Dikshit Aruba Networks, HPE Mahadevpura Bangalore 560 048 Karnataka India Email: saumya.dikshit@hpe.com Vinayak Joshi Oracle India Pvt Ltd Bangalore Karnataka India Email: vinayak.j.joshi@oracle.com Changwang Lin New H3C Technologies Beijing China Email: linchangwang.04414@h3c.com