Internet-Draft Per-Flow EVPN Designated Forwarder Elect July 2026
Ananthamurthy, et al. Expires 23 January 2027 [Page]
Workgroup:
BESS Working Group
Internet-Draft:
draft-kriswamy-bess-evpn-perflow-df-02
Published:
Intended Status:
Standards Track
Expires:
Authors:
K. Ananthamurthy
Cisco
A. Sajassi
Cisco
L. Krattiger
Cisco

Per-Flow EVPN Designated Forwarder Election

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/.

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.

Table of Contents

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).

[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:

 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

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 hash function MAY use a Cyclic Redundancy Check 32 (CRC-32) or any other implementation-specific 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.

3.1. Per-Flow DF Election Example


                                         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:

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:

6. Normative References

[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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8584>.

Authors' Addresses

Krishnaswamy Ananthamurthy
Cisco
170 W. Tasman Drive
San Jose, CA 95134
United States of America
Ali Sajassi
Cisco
170 W. Tasman Drive
San Jose, CA 95134
United States of America
Lukas Krattiger
Cisco
170 W. Tasman Drive
San Jose, CA 95134
United States of America