Per-Flow EVPN Designated Forwarder Election
draft-kriswamy-bess-evpn-perflow-df-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Krishnaswamy Ananthamurthy , Ali Sajassi , Lukas Krattiger | ||
| Last updated | 2026-07-22 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-kriswamy-bess-evpn-perflow-df-02
BESS Working Group K. Ananthamurthy
Internet-Draft A. Sajassi
Intended status: Standards Track L. Krattiger
Expires: 23 January 2027 Cisco
22 July 2026
Per-Flow EVPN Designated Forwarder Election
draft-kriswamy-bess-evpn-perflow-df-02
Abstract
The Ethernet Virtual Private Network (EVPN) solution offers
procedures for electing a Designated Forwarder (DF) for multihomed
Ethernet Segments. In this context, the Provider Edge (PE) router is
responsible for sending Broadcast, Unknown Unicast, and Multicast
(BUM) traffic to a multihomed device or network. This applies in
cases of an all-active multihomed Ethernet Segment (ES) as well as
for BUM and unicast traffic in the case of single-active multihoming.
While the Default Algorithm provides an efficient and automated
mechanism for selecting the DF across Ethernet Tags within an
Ethernet Segment, it does not provide Per-flow DF selection within an
EVPN Instance (EVI).
This document defines a new DF Election Algorithm that performs Per-
flow DF selection by defining a new DF Algorithm value.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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/.
Ananthamurthy, et al. Expires 23 January 2027 [Page 1]
Internet-Draft Per-Flow EVPN Designated Forwarder Elect July 2026
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 23 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Designated Forwarder Election Extended Community . . . . . . 3
3. Per-Flow DF Election Operation . . . . . . . . . . . . . . . 4
3.1. Per-Flow DF Election Example . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
The EVPN solution offers procedures for electing a Designated
Forwarder (DF) for multihomed Ethernet Segments. In this context,
the PE is responsible for sending BUM traffic to a multihomed device
or network. This applies in cases of an all-active multihomed ES as
well as for BUM and unicast traffic in the case of single-active
multihoming. While the Default Algorithm provides an efficient and
automated mechanism for selecting the DF across Ethernet Tags within
an Ethernet Segment, it does not provide Per-flow DF selection within
an EVPN Instance (EVI).
Ananthamurthy, et al. Expires 23 January 2027 [Page 2]
Internet-Draft Per-Flow EVPN Designated Forwarder Elect July 2026
[RFC8584] and [I-D.ietf-bess-evpn-per-mcast-flow-df-election] enhance
the default DF election by introducing the Highest Random Weight
(HRW) algorithm and the tuple consisting of Ethernet Segment
Identifier (ESI), VLAN, and multicast flow to provide more
deterministic and stable DF selection respectively.
Existing DF election procedures maintain state in both the control
plane and the forwarding plane. These procedures improve the
distribution of BUM traffic across the PEs attached to a multihomed
Ethernet Segment. However, the forwarding responsibility is assigned
at the Ethernet Tag or multicast-group granularity and does not
provide per-flow load distribution.
[I-D.ietf-bess-evpn-per-mcast-flow-df-election] extends the DF
election procedures to support per-flow load distribution for
multicast traffic. In that approach, a multicast-group-specific DF
election is performed when a host attached to a multihomed Ethernet
Segment joins a multicast group using IGMP or MLD. As a result, the
participating PEs maintain multicast-group-specific DF election state
in the control plane.
This document addresses the remaining gap for BUM forwarding by
defining a per-flow DF election algorithm that does not require
maintaining per-flow control-plane state. Instead, all participating
PEs independently derive the same Designated Forwarder for a given
flow by applying a common hashing function to the flow key and
selecting the DF from the ordered PE list defined in [RFC8584]. This
approach distributes flows across the available PEs while ensuring
deterministic and consistent forwarding decisions. This document
updates [RFC8584] by defining a new DF Algorithm value.
2. Designated Forwarder Election Extended Community
To advertise support for the Per-flow DF election algorithm, this
document reuses the Designated Forwarder Election Extended Community
defined in [RFC8584] that is advertised along with the Ethernet
Segment route. This document defines a new DF Algorithm type Per-
flow. A PE can notify other participating PEs in the redundancy
group about its support for the Per-flow DF Algorithm by signaling a
DF Election Extended Community. A PE that supports the procedures
specified in this document MUST advertise the corresponding DF Alg in
its Ethernet Segment Route (Route Type 4). This enables all PEs
participating in the redundancy group to discover the capability and
consistently apply the enhanced DF election procedures in a backward-
compatible and interoperable manner.
The format of the DF Election Extended Community that is used in this
document follows:
Ananthamurthy, et al. Expires 23 January 2027 [Page 3]
Internet-Draft Per-Flow EVPN Designated Forwarder Elect July 2026
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type(0x06)| RSV | DF Alg | Bitmap ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Bitmap | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: DF Election Extended Community
* The DF Alg (5 bits) field identifies the DF Election Algorithm
used for the Ethernet Segment.
- This document defines a new DF Algorithm value, Per-flow. IANA
is requested to assign the value 6 from the "DF Alg" registry
defined in [RFC8584]. The assigned value is encoded in the DF
Algorithm field of the DF Election Extended Community.
* The procedures defined in [RFC8584] to handle Designated Forwarder
Election Extended Community are applicable.
* A PE SHOULD attach the DF Election Extended Community to the ES
route and the Extended Community MUST be advertised if the ES is
locally configured for DF type Per-flow DF election.
* A PE MUST use the Per-flow DF Algorithm only if all participating
PEs advertise the same DF Algorithm value for the Ethernet
Segment. Otherwise, the procedures of [RFC8584] apply.
Once all participating PEs advertise the Per-flow DF Algorithm, they
perform DF selection as specified in Section 3.
3. Per-Flow DF Election Operation
Once all PEs in the redundancy group have advertised support for the
Per-flow DF Algorithm, they independently compute the Designated
Forwarder for each flow using the procedures described in this
section. No additional control-plane signaling is required beyond
the ordered PE list.
When operating in Per-flow Designated Forwarder (DF) mode, the
ordered (ordinal) PE list defined in [RFC8584] SHALL be used. This
is the only control plane state maintained.
When a BUM packet arrives, the hash is computed using a set of packet
header fields that are applicable to the packet being processed.
* The selection of fields is dependent on the packet format and
protocol type.
Ananthamurthy, et al. Expires 23 January 2027 [Page 4]
Internet-Draft Per-Flow EVPN Designated Forwarder Elect July 2026
* The exact choice of fields is outside the scope of this document.
* However, all participating PEs MUST use a consistent set of packet
header fields for a given packet format to ensure that identical
packets produce the same hash value across all participating PEs.
The hash function MAY use a Cyclic Redundancy Check 32 (CRC-32) or
any other implementation-specific hashing algorithm.
* The choice of hash function is outside the scope of this document.
* To ensure consistent Per-flow DF selection across all PEs
participating in the ES, all such PEs MUST use the same hashing
algorithm.
Let H denote the hash value computed over the flow key, and let N
denote the number of active PEs in the ordered PE list. The value of
N is used in the DF selection algorithm.
The DF index, I, MUST be computed as follows:
I = H mod N
The PE at position I in the ordered PE list SHALL be elected as the
Designated Forwarder for the corresponding flow.
* This approach allows multiple flows within the same VLAN to be
forwarded by different PEs elected as the Designated Forwarder for
a given Ethernet Segment.
* As long as the ordered PE list remains unchanged, a given flow is
always mapped to the same DF.
* Whenever the set of active PEs changes, the value of N changes,
and the resulting DF assignment for existing flows may also
change.
3.1. Per-Flow DF Election Example
Ananthamurthy, et al. Expires 23 January 2027 [Page 5]
Internet-Draft Per-Flow EVPN Designated Forwarder Elect July 2026
BUM Source
|
|
|
|
+---------+
+--------------+ PE-4 +--------------+
| | | |
| +---------+ |
| |
| EVPN |
| |
| |
| |
+---------+ +---------+ +---------+
| PE1 +--------+ PE2 +---------+ PE3 |
| EVI-1 | | EVI-1 | | EVI-1 |
+---------+ +---------+ +---------+
|__________________|___________________|
AC-1 ESI-1 | AC-2 AC-3
+---------+
| CE-1 |
| |
+---------+
|
|
|
|
BUM Receivers
Figure-1 : Multihomed network
Figure-1 illustrates Ethernet Segment ESI-1 multihomed to PE1, PE2,
and PE3. Assume that all three PEs advertise support for the Per-
flow DF Algorithm and derive the following ordered PE list according
to [RFC8584]:
Ordered PE List = {PE1, PE2, PE3}
N = 3
PE1, PE2 and PE3 receive BUM traffic from the EVPN core for the same
VLAN (e.g., VLAN 101) and sends the traffic toward the multihomed
Ethernet Segment. For each flow, every participating PE computes the
same hash value over the selected packet header fields and compute
the DF index as specified in this section. The following example
uses representative hash values:
Ananthamurthy, et al. Expires 23 January 2027 [Page 6]
Internet-Draft Per-Flow EVPN Designated Forwarder Elect July 2026
Flow VLAN Hash Value (H) DF Index (H mod 3) Elected DF
---- ----- -------------- ------------------ ----------
Flow-A 101 101 2 PE3
Flow-B 101 205 1 PE2
Flow-C 101 300 0 PE1
Flow-D 101 401 2 PE3
Because all participating PEs use the same flow-key fields, hashing
algorithm, and ordered PE list, they independently elect the same DF
for each flow without requiring per-flow control-plane signaling.
Consequently, Flow-A and Flow-D are forwarded toward CE-1 only by
PE3, Flow-B only by PE2, and Flow-C only by PE1. This distributes
different BUM flows within the same VLAN and Ethernet Segment across
the available PEs while ensuring that each individual flow is
forwarded by only one DF.
If the membership of the redundancy group changes, the participating
PEs update the ordered PE list and recompute the DF index using the
new value of N. For example, if PE2 is no longer active, the ordered
PE list becomes:
Ordered PE List = {PE1, PE3}
N = 2
As a result, some existing flows may be assigned to a different DF.
All remaining participating PEs nevertheless continue to derive
identical forwarding decisions because they use the same ordered PE
list, flow-key fields, and hashing algorithm.
4. Security Considerations
This document introduces no new security considerations beyond those
discussed in [RFC7432] and [RFC8584].
5. IANA Considerations
This document solicits:
* The allocation of one new value in the "DF Alg" registry created
by [RFC8584] as follows:
Alg Name Reference
---- ----------------------------- -------------
6 Per-flow This document
6. Normative References
Ananthamurthy, et al. Expires 23 January 2027 [Page 7]
Internet-Draft Per-Flow EVPN Designated Forwarder Elect July 2026
[I-D.ietf-bess-evpn-per-mcast-flow-df-election]
Sajassi, A., Mishra, M. P., Thoria, S., Rabadan, J., and
J. Drake, "Per multicast flow Designated Forwarder
Election for EVPN", Work in Progress, Internet-Draft,
draft-ietf-bess-evpn-per-mcast-flow-df-election-13, 2
March 2026, <https://datatracker.ietf.org/doc/html/draft-
ietf-bess-evpn-per-mcast-flow-df-election-13>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake,
J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet
VPN Designated Forwarder Election Extensibility",
RFC 8584, DOI 10.17487/RFC8584, April 2019,
<https://www.rfc-editor.org/info/rfc8584>.
Authors' Addresses
Krishnaswamy Ananthamurthy
Cisco
170 W. Tasman Drive
San Jose, CA 95134
United States of America
Email: kriswamy@cisco.com
Ali Sajassi
Cisco
170 W. Tasman Drive
San Jose, CA 95134
United States of America
Email: sajassi@cisco.com
Ananthamurthy, et al. Expires 23 January 2027 [Page 8]
Internet-Draft Per-Flow EVPN Designated Forwarder Elect July 2026
Lukas Krattiger
Cisco
170 W. Tasman Drive
San Jose, CA 95134
United States of America
Email: lkrattig@cisco.com
Ananthamurthy, et al. Expires 23 January 2027 [Page 9]