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

This document defines a Per-flow DF Election Algorithm to provide fine-grained load sharing. This document updates [RFC8584] by defining a new DF Algorithm value.

2. Designated Forwarder Election Extended Community Extensions

This solution reuses and extends 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. 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

The DF Alg 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 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.

3. Operation

A PE that supports the Per-flow DF Algorithm MUST advertise the ES route with the DF Election Extended Community, with the DF Algorithm field set to Per-flow.

A PE that supports the Per-flow DF Algorithm SHOULD perform DF election on a Per-flow basis when it receives an ES route containing the DF Election Extended Community with the DF Algorithm field set to Per-flow.

A PE that does not recognize the advertised DF Algorithm SHALL process the DF Election Extended Community according to [RFC8584].

The ordered PE list defined in [RFC8584] SHALL be used. When operating in Per-flow Designated Forwarder (DF) mode, the hash computation SHALL use 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. 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 (CRC) 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 PE routers participating in the ES, all such PE routers 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 PE routers in the ordered PE list defined by [RFC8584]. The number of participating PE routers MUST be 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 defined by [RFC8584] 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 PE routers 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 PE routers changes, the value of N changes, and the resulting DF assignment for existing flows may also change.

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

[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