rfc9785xml2.original.xml   rfc9785.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7432.xml">
<!ENTITY RFC8214 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8214.xml">
<!ENTITY RFC7623 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7623.xml">
<!ENTITY RFC8365 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8365.xml">
<!ENTITY RFC8584 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8584.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY I-D.ietf-bess-evpn-virtual-eth-segment SYSTEM "https://xml2rfc.ietf.org
/public/rfc/bibxml3/reference.I-D.ietf-bess-evpn-virtual-eth-segment.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-bess-evpn-pref-df-13"
ipr="trust200902" submissionType="IETF" updates="8584">
<!--Generated by id2xml 1.5.0 on 2019-12-17T09:50:28Z -->
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc text-list-symbols="o-*+"?> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie tf-bess-evpn-pref-df-13" number="9785" ipr="trust200902" submissionType="IETF" u pdates="8584" obsoletes="" xml:lang="en" consensus="true" tocInclude="true" toc Depth="3" symRefs="true" sortRefs="true" version="3">
<front> <front>
<title>Preference-based EVPN DF Election</title> <title abbrev="Preference-Based EVPN DF Election">Preference-Based EVPN Desi
gnated Forwarder (DF) Election</title>
<author fullname="J. Rabadan" initials="J." role="editor" <seriesInfo name="RFC" value="9785"/>
surname="Rabadan"> <author fullname="Jorge Rabadan" initials="J." role="editor" surname="Rabada
n">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street>520 Almanor Avenue</street> <street>520 Almanor Avenue</street>
<city>Sunnyvale</city> <city>Sunnyvale</city>
<region>CA</region> <region>CA</region>
<code>94085</code> <code>94085</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>jorge.rabadan@nokia.com</email> <email>jorge.rabadan@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Senthil Sathappan" initials="S." surname="Sathappan">
<author fullname="S. Sathappan" initials="S." surname="Sathappan">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<email>senthil.sathappan@nokia.com</email> <email>senthil.sathappan@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Wen Lin" initials="W." surname="Lin">
<author fullname="W. Lin" initials="W." surname="Lin">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<email>wlin@juniper.net</email> <email>wlin@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="John Drake" initials="J." surname="Drake">
<author fullname="J. Drake" initials="J." surname="Drake">
<organization>Independent</organization> <organization>Independent</organization>
<address> <address>
<email>je_drake@yahoo.com</email> <email>je_drake@yahoo.com</email>
</address> </address>
</author> </author>
<author fullname="Ali Sajassi" initials="A." surname="Sajassi">
<author fullname="A. Sajassi" initials="A." surname="Sajassi">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<email>sajassi@cisco.com</email> <email>sajassi@cisco.com</email>
</address> </address>
</author> </author>
<date month="May" year="2025"/>
<date day="9" month="October" year="2023"/> <area>RTG</area>
<workgroup>bess</workgroup>
<workgroup>BESS Workgroup</workgroup>
<abstract> <abstract>
<t>The Designated Forwarder (DF) in Ethernet Virtual Private Networks <t>The Designated Forwarder (DF) in Ethernet Virtual Private Networks
(EVPN) is defined as the Provider Edge (PE) router responsible for (EVPNs) is defined as the Provider Edge (PE) router responsible for
sending Broadcast, Unknown unicast and Multicast traffic (BUM) to a sending Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a
multi-homed device/network in the case of an all-active multi-homing multihomed device/network in the case of an All-Active multihoming
Ethernet Segment (ES), or BUM and unicast in the case of single-active Ethernet Segment (ES) or BUM and unicast in the case of Single-Active
multi-homing. The Designated Forwarder is selected out of a candidate multihoming. The Designated Forwarder is selected out of a candidate
list of PEs that advertise the same Ethernet Segment Identifier (ESI) to list of PEs that advertise the same Ethernet Segment Identifier (ESI) to
the EVPN network, according to the Default Designated Forwarder Election the EVPN network, according to the default DF election
algorithm. While the Default Algorithm provides an efficient and algorithm. While the default algorithm provides an efficient and
automated way of selecting the Designated Forwarder across different automated way of selecting the Designated Forwarder across different
Ethernet Tags in the Ethernet Segment, there are some use cases where a Ethernet Tags in the Ethernet Segment, there are some use cases where a
more 'deterministic' and user-controlled method is required. At the same more "deterministic" and user-controlled method is required. At the same
time, Network Operators require an easy way to force an on-demand time, Network Operators require an easy way to force an on-demand
Designated Forwarder switchover in order to carry out some maintenance Designated Forwarder switchover in order to carry out some maintenance
tasks on the existing Designated Forwarder or control whether a new tasks on the existing Designated Forwarder or control whether a new
active PE can preempt the existing Designated Forwarder PE.</t> active PE can preempt the existing Designated Forwarder PE.</t>
<t>This document proposes use of a DF election algorithm that
<t>This document proposes a Designated Forwarder Election algorithm that
meets the requirements of determinism and operation control. This meets the requirements of determinism and operation control. This
document updates RFC8584 by modifying the definition of the DF Election document updates RFC 8584 by modifying the definition of the DF Election
Extended Community. </t> Extended Community. </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="sect-1" title="Introduction"> <section anchor="sect-1" numbered="true" toc="default">
<section anchor="sect-1.1" title="Problem Statement"> <name>Introduction</name>
<t><xref target="RFC7432"/> defines the Designated Forwarder (DF) in <section anchor="sect-1.1" numbered="true" toc="default">
<name>Problem Statement</name>
<t><xref target="RFC7432" format="default"/> defines the Designated Forw
arder (DF) in
EVPN networks as the PE responsible for sending Broadcast, Unknown EVPN networks as the PE responsible for sending Broadcast, Unknown
unicast and Multicast traffic (BUM) to a multi-homed device/network in Unicast, and Multicast (BUM) traffic to a multihomed device/network in
the case of an all-active multi-homing Ethernet Segment or BUM and the case of an All-Active multihoming Ethernet Segment or BUM and
unicast traffic to a multi-homed device or network in the case of unicast traffic to a multihomed device or network in the case of
single-active multi-homing. The Designated Forwarder is selected out Single-Active multihoming. The Designated Forwarder is selected out
of a candidate list of PEs that advertise the Ethernet Segment of a candidate list of PEs that advertise the Ethernet Segment
Identifier (ESI) to the EVPN network and according to the Designated Identifier (ESI) to the EVPN network and according to the DF election al
Forwarder Election Algorithm, or DF Alg as per <xref gorithm or to DF Alg as per <xref target="RFC8584" format="default"/>.</t>
target="RFC8584"/>.</t>
<t>While the Default Designated Forwarder Algorithm <xref <t>While the default DF algorithm or the Highest Random Weight (HRW) alg
target="RFC7432"/> or the Highest Random Weight algorithm (HRW) <xref orithm <xref target="RFC8584" format="default"/> provide an efficient and automa
target="RFC8584"/> provide an efficient and automated way of selecting ted way of selecting
the Designated Forwarder across different Ethernet Tags in the the Designated Forwarder across different Ethernet Tags in the
Ethernet Segment, there are some use-cases where a more Ethernet Segment, there are some use cases where a more
user-controlled method is required. At the same time, Network user-controlled method is required. At the same time, Network
Operators require an easy way to force an on-demand Designated Operators require an easy way to force an on-demand Designated Forwarde
Forwarder switchover in order to carry out some maintenance tasks on r switchover in order to carry out some maintenance tasks on
the existing Designated Forwarder or control whether a new active PE the existing Designated Forwarder or control whether a new active PE
can preempt the existing Designated Forwarder PE.</t> can preempt the existing Designated Forwarder PE.</t>
</section> </section>
<section anchor="sect-1.2" numbered="true" toc="default">
<section anchor="sect-1.2" title="Solution Requirements"> <name>Solution Requirements</name>
<t>The procedures described in this document meet the following <t>The procedures described in this document meet the following
requirements:<list style="letters"> requirements:</t>
<ol spacing="normal" type="a"><li>
<t>The solution provides an administrative preference option so <t>The solution provides an administrative preference option so
that the user can control in what order the candidate PEs may that the user can control in what order the candidate PEs may
become Designated Forwarder, assuming they are all operationally become the Designated Forwarder, assuming they are all operationally
ready to take over as Designated Forwarder. The operator can ready to take over as the Designated Forwarder. The operator can
determine whether the Highest-Preference or Lowest-Preference PE determine whether the Highest-Preference or Lowest-Preference PE
among the PEs in the Ethernet Segment will be elected as among the PEs in the Ethernet Segment will be elected as
Designated Forwarder, based on the DF Algorithms described in this the Designated Forwarder, based on the DF algorithms described in th is
document.</t> document.</t>
</li>
<t>The extensions in this document work for <xref <li>
target="RFC7432"/> Ethernet Segments and virtual Ethernet <t>The extensions described in this document work for Ethernet Segme
Segments, as defined in <xref nts <xref target="RFC7432" format="default"/> and virtual Ethernet
target="I-D.ietf-bess-evpn-virtual-eth-segment"/>.</t> Segments as defined in <xref target="RFC9784" format="default"/>.</t
>
</li>
<li>
<t>The user may force a PE to preempt the existing Designated <t>The user may force a PE to preempt the existing Designated
Forwarder for a given Ethernet Tag without re-configuring all the Forwarder for a given Ethernet Tag without reconfiguring all the
PEs in the Ethernet Segment, by simply modifying the existing PEs in the Ethernet Segment, by simply modifying the existing
administrative preference in that PE.</t> administrative preference in that PE.</t>
</li>
<li anchor="DP-capability">
<t>The solution allows an option to NOT preempt the current <t>The solution allows an option to NOT preempt the current
Designated Forwarder ("Don't Preempt" capability), even if the Designated Forwarder (the "Don't Preempt" Capability), even if the
former Designated Forwarder PE comes back up after a failure. This former Designated Forwarder PE comes back up after a failure. This
is also known as "non-revertive" behavior, as opposed to the <xref is also known as "non-revertive" behavior, as opposed to the DF elec
target="RFC7432"/> Designated Forwarder election procedures that tion procedures <xref target="RFC7432" format="default"/> that
are always revertive (because the winner PE of the default are always revertive (because the winner PE of the default
Designated Forwarder election algorithm always takes over as the DF election algorithm always takes over as the
operational Designated Forwarder).</t> operational Designated Forwarder).</t>
</li>
<t>The procedures described in this document support single-active <li>
and all-active multi-homing Ethernet Segments.</t> <t>The procedures described in this document support Single-Active
</list></t> and All-Active multihoming Ethernet Segments.</t>
</li>
</ol>
</section> </section>
<section anchor="sect-1.3" numbered="true" toc="default">
<section anchor="sect-1.3" title="Solution Overview"> <name>Solution Overview</name>
<t>To provide a solution that satisfies the above requirements, we <t>To provide a solution that satisfies the above requirements, we
introduce two new DF Algorithms that can be advertised in the DF introduce two new DF algorithms that can be advertised in the DF
Election Extended Community <xref target="sect-3"/>. Carried with the Election Extended Community (<xref target="sect-3" format="default"/>).
new DF Election Extended Community variants are a DF election Carried with the
preference advertised for each PE, that influences which PE will new DF Election Extended Community variants is a DF election
become DF <xref target="sect-4.1"/>. The advertised DF election preference advertised for each PE that influences which PE will
become the DF (<xref target="sect-4.1" format="default"/>). The advertis
ed DF election
preference can dynamically vary from the administratively configured preference can dynamically vary from the administratively configured
preference to provide non-revertive behavior <xref preference to provide non-revertive behavior (<xref target="sect-4.3" fo
target="sect-4.3"/>. An optional solution is discussed in <xref rmat="default"/>). In <xref target="sect-4.2" format="default"/>, an optional so
target="sect-4.2"/>, for use in Ethernet segments that support large lution is discussed for use in Ethernet Segments that supports large numbers of
numbers of Ethernet Tags and therefore need to balance load among Ethernet Tags and therefore needs to balance load among
multiple DFs. </t> multiple DFs. </t>
</section> </section>
</section> </section>
<section anchor="sect-2" numbered="true" toc="default">
<name>Requirements Language and Terminology</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<section anchor="sect-2" title="Requirements Language and Terminology"> <dl spacing="normal" newline="false">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <dt>AC:</dt><dd>Attachment Circuit. An AC has an Ethernet Tag
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and associated to it.</dd>
"OPTIONAL" in this document are to be interpreted as described in BCP 14 <dt>CE:</dt><dd>Customer Equipment router</dd>
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, <dt>DF:</dt><dd>Designated Forwarder</dd>
they appear in all capitals, as shown here.</t> <dt>DF Alg:</dt><dd>Refers to the DF election
algorithm, which is sometimes shortened to "Alg" in this document.</dd>
<t><list style="symbols"> <dt>DP:</dt><dd>Refers to the "Don't Preempt" Capability in the
<t>AC - Attachment Circuit. An AC has an Ethernet Tag associated to DF Election Extended Community.</dd>
it.</t> <dt>ENNI:</dt><dd>External Network-Network Interface</dd>
<dt>ES and vES:</dt><dd>Ethernet Segment and virtual Ethernet Segment.</
<t>CE - Customer Equipment router.</t> dd>
<dt>Ethernet A-D per EVI route:</dt><dd>Refers to Route Type 1 or Auto-D
<t>DF - Designated Forwarder.</t> iscovery per
EVPN Instance route <xref target="RFC7432" format="default"/>.</dd>
<t>DF Alg - refers to Designated Forwarder Election Algorithm. This <dt>EVC:</dt><dd>Ethernet Virtual Circuit</dd>
is sometimes shortened to &ldquo;Alg&rdquo; in this document.</t> <dt>EVI:</dt><dd>EVPN Instance</dd>
<dt>Ethernet Tag:</dt><dd>Used to represent a broadcast domain that is
<t>DP - refers to the "Don't Preempt" (me) capability in the configured on a given Ethernet Segment for the purpose of DF election. N
Designated Forwarder Election extended community.</t> ote that any of the following may be used to
represent a broadcast domain: VLAN IDs (VIDs) (including Q-in-Q tags), c
<t>ENNI - Ethernet Network to Network Interface.</t> onfigured
IDs, VXLAN Network Identifiers (VNIs), normalized VIDs, Service
<t>ES and vES - Ethernet Segment and virtual Ethernet Segment.</t> Instance Identifiers (I-SIDs), etc., as long as the representation of th
e
<t>Ethernet A-D per EVI route - refers to <xref target="RFC7432"/> broadcast domains is configured consistently across the multihomed
route type 1 or Auto-Discovery per EVPN Instance route.</t> PEs attached to that Ethernet Segment. The Ethernet Tag value
<bcp14>MUST NOT</bcp14> be zero.</dd>
<t>EVC - Ethernet Virtual Circuit.</t> <dt>HRW:</dt><dd>Highest Random Weight, as per <xref target="RFC8584"
format="default"/>.</dd>
<t>EVI - EVPN Instance.</t> <dt>OAM:</dt><dd>Operations, Administration, and Maintenance.</dd>
</dl>
<t>Ethernet Tag - used to represent a Broadcast Domain that is
configured on a given Ethernet Segment for the purpose of Designated
Forwarder election. Note that any of the following may be used to
represent a Broadcast Domain: VIDs (including Q-in-Q tags),
configured IDs, VNI (VXLAN Network Identifiers), normalized VID,
I-SIDs (Service Instance Identifiers), etc., as long as the
representation of the broadcast domains is configured consistently
across the multi-homed PEs attached to that Ethernet Segment. The
Ethernet Tag value MUST NOT be zero.</t>
<t>HRW - Highest Random Weight, as per <xref target="RFC8584"/>.</t>
<t>OAM - refers to Operations And Maintenance protocols.</t>
</list></t>
</section> </section>
<section anchor="sect-3" numbered="true" toc="default">
<name>EVPN BGP Attribute Extensions</name>
<section anchor="sect-3" title="EVPN BGP Attributes Extensions"> <t>This solution reuses and extends the DF Election
<t>This solution reuses and extends the Designated Forwarder Election Extended Community defined in <xref target="RFC8584" format="default"/> th
Extended Community defined in <xref target="RFC8584"/> that is at is
advertised along with the Ethernet Segment route. It does so by advertised along with the Ethernet Segment route. It does so by
replacing the last two reserved octets of the DF Election Extended replacing the last two reserved octets of the DF Election Extended
Community when the DF Algorithm is set to Highest-Preference or Community when the DF algorithm is set to Highest-Preference or
Lowest-Preference. This document also defines a new capability referred Lowest-Preference. This document also defines a new capability referred
to as the "Don't Preempt" capability, that MAY be used with to as the "Don't Preempt" Capability, which <bcp14>MAY</bcp14> be used wit
Highest-Preference or Lowest-Preference DF Algorithms. The format of the h
DF Election Extended Community that is used in this document Highest-Preference or Lowest-Preference Algorithms. The format of the
DF Election Extended Community used in this document is as
follows:</t> follows:</t>
<figure anchor="df-election-extended-community">
<figure anchor="df-election-extended-community" <name>DF Election Extended Community</name>
title="DF Election Extended Community"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
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 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 ~ | Type=0x06 | Sub-Type(0x06)| RSV | DF Alg | Bitmap ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Bitmap | Reserved | DF Preference (2 octets) | ~ Bitmap | Reserved | DF Preference (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where the above fields are defined as follows:</t> <t>Where the above fields are defined as follows:</t>
<ul spacing="normal">
<t><list style="symbols"> <li><t>The DF algorithm can have the following values:</t>
<t>DF Algorithm can have the following values:<list style="symbols"> <ul spacing="normal">
<t>Alg 0 - Default Designated Forwarder Election algorithm, or <li>Alg 0 - Default DF election algorithm, i.e.,
modulus-based algorithm as per <xref target="RFC7432"/>.</t> the modulus-based algorithm as per <xref target="RFC7432"
format="default"/>.</li>
<t>Alg 1 - HRW algorithm as per <xref target="RFC8584"/>.</t> <li>Alg 1 - HRW algorithm as per <xref target="RFC8584" format="defa
ult"/>.</li>
<t>Alg 2 - Highest-Preference algorithm (this document <xref <li>Alg 2 - Highest-Preference Algorithm (<xref target="sect-4.1" fo
target="sect-4.1"/>).</t> rmat="default"/>).</li>
<li>Alg 3 - Lowest-Preference Algorithm (<xref
<t>Alg TBD - Lowest-Preference algorithm (this document <xref target="sect-4.1" format="default"/>).</li>
target="sect-4.1"/>). TBD will be replaced by the allocated </ul>
value at the time of publication.</t> </li>
</list></t> <li><t>Bitmap (2 octets) encodes "capabilities" <xref target="RFC8584"
</list><list style="symbols"> format="default"/>, whereas this document defines the "Don't Preempt"
<t>Bitmap (2 octets) encodes "capabilities" <xref Capability, which is used to indicate if a PE supports a non-revertive
target="RFC8584"/>, where this document defines the "Don't Preempt" behavior:</t>
capability, used to indicate if a PE supports a non-revertive <figure anchor="bitmap-field-in-the-df-election-extended-community">
behavior:</t> <name>Bitmap Field in the DF Election Extended Community</name>
</list></t> <artwork name="" type="" align="left" alt=""><![CDATA[
<figure anchor="bitmap-field-in-the-df-election-extended-community"
title="Bitmap field in the DF Election Extended Community">
<artwork><![CDATA[
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|A| | |D|A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<ul spacing="normal">
<t><list style="empty"> <li>Bit 0 (corresponds to Bit 24 of the DF
<t><list style="symbols"> Election Extended Community, and it is defined by this document):
<t>Bit 0 (corresponds to Bit 24 of the Designated Forwarder The D bit, or "Don't Preempt" Capability, determines if the
Election Extended Community and it is defined by this document): PE advertising the Ethernet Segment route requests the remote PEs
the D bit or 'Don't Preempt' bit (DP hereafter), determines if in the Ethernet Segment to not preempt it as the Designated
the PE advertising the Ethernet Segment route requests the Forwarder. The default value is DP=0, which is compatible with the
remote PEs in the Ethernet Segment not to preempt it as 'preempt' or 'revertive' behavior in the default DF algorithm
Designated Forwarder. The default value is DP=0, which is <xref target="RFC7432" format="default"/>. The "Don't Preempt" Capab
compatible with the 'preempt' or 'revertive' behavior in the ility is
Default DF Algorithm <xref target="RFC7432"/>. The DP capability supported by the Highest-Preference or Lowest-Preference
is supported by the Highest-Preference or Lowest-Preference DF Algorithms. The procedures of the "Don't Preempt" Capability for
Algorithms. The procedures of the "Don't Preempt" capability for other DF algorithms are out of the scope of this document. The
other DF Algorithms are out of the scope of this document. The procedures of the "Don't Preempt" Capability for the
procedures of the "Don't Preempt" capability for the Highest-Preference and Lowest-Preference Algorithms are
Highest-Preference and Lowest-Preference DF Algorithms are described in <xref target="sect-4.1" format="default"/>.</li>
described in <xref target="sect-4.1"/>.</t> <li>Bit 1: AC-Influenced DF (AC-DF) election is
described in <xref target="RFC8584" format="default"/>. When set
<t>Bit 1: AC-DF or AC-Influenced Designated Forwarder Election to 1, it indicates the desire to use AC-DF with the rest of the PEs
is described in <xref target="RFC8584"/>. When set to 1, it in the Ethernet
indicates the desire to use AC-Influenced Designated Forwarder Segment. The AC-DF capability bit <bcp14>MAY</bcp14> be set along
Election with the rest of the PEs in the Ethernet Segment. The with the "Don't Preempt" Capability and Highest-Preference or
AC-DF capability bit MAY be set along with the DP capability and Lowest-Preference Algorithms.</li>
the Highest-Preference or Lowest-Preference DF Algorithms.</t> </ul>
</list></t> </li>
</list><list style="symbols"> <li>Designated Forwarder (DF) Preference:
<t>Designated Forwarder (DF) Preference (described in this Defines a 2-octet value that indicates the PE preference to become the
document): defines a 2-octet value that indicates the PE preference Designated Forwarder in the Ethernet Segment, as described in <xref
to become the Designated Forwarder in the Ethernet Segment, as target="sect-4.1" format="default"/>. The allowed values are within
described in <xref target="sect-4.1"/>. The allowed values are the range 0-65535, and the default value <bcp14>MUST</bcp14> be
within the range 0-65535, and the default value MUST be 32767. This 32767. This value is the midpoint in the allowed Preference range of
value is the midpoint in the allowed Preference range of values, values, which gives the operator the flexibility of choosing a
which gives the operator the flexibility of choosing a significant significant number of values, above or below the default Preference. A
number of values, above or below the default Preference. A numerically higher or lower value of this field is more preferred for
numerically higher or lower value of this field is more preferred DF election depending on the DF algorithm being
for Designated Forwarder election depending on the DF Algorithm used, as explained in <xref target="sect-4.1" format="default"/>. The
being used, as explained in <xref target="sect-4.1"/>. The Designated Forwarder Preference field is specific to
Designated Forwarder Preference field is specific to DF Algorithms Highest-Preference and Lowest-Preference Algorithms, and this document d
Highest-Preference and Lowest-Preference, and this document does not oes not
define any meaning for other algorithms. If the DF Algorithm is define any meaning for other algorithms. If the DF algorithm is
different from Highest-Preference or Lowest-Preference, these two different from Highest-Preference or Lowest-Preference, these 2
octets can be encoded differently.</t> octets can be encoded differently.</li>
<li>RSV and Reserved fields (from bit 16 to bit 18, and from bit 40 to
<t>RSV and Reserved fields (from bit 16 to bit 18, and from bit 40 47): When the DF algorithm is set to Highest-Preference or
to 47): when DF Algorithm is set to Highest-Preference or Lowest-Preference, the values are set to zero when
Lowest-Preference algorithm, the values are set to zero when advertising the Ethernet Segment route, and they are ignored when
advertising the Ethernet Segment route, and they are ignored when receiving the Ethernet Segment route.</li>
receiving the Ethernet Segment route.</t> </ul>
</list></t>
</section> </section>
<section anchor="sect-4" numbered="true" toc="default">
<section anchor="sect-4" title="Solution description"> <name>Solution Description</name>
<t><xref target="es-and-deterministic-df-election"/> illustrates an <t><xref target="es-and-deterministic-df-election" format="default"/> illu
strates an
example that will be used in the description of the solution.</t> example that will be used in the description of the solution.</t>
<figure anchor="es-and-deterministic-df-election">
<figure anchor="es-and-deterministic-df-election" <name>Preference-Based DF Election</name>
title="Preference-based DF Election"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ EVPN Network
EVPN network
+-------------------+ +-------------------+
| +-------+ ENNI Aggregation | +-------+ ENNI Aggregation
| <---ESI1,500 | PE1 | /\ +----Network---+ | <---ESI1,500 | PE1 | /\ +----Network---+
| <-----ESI2,100 | |===||=== | | <-----ESI2,100 | |===||=== |
| | |===||== \ vES1 | +----+ | | |===||== \ vES1 | +----+
+-----+ | | \/ |\----------------+CE1 | +-----+ | | \/ |\----------------+CE1 |
CE3--+ PE4 | +-------+ | \ ------------+ | CE3--+ PE4 | +-------+ | \ ------------+ |
+-----+ | | \ / | +----+ +-----+ | | \ / | +----+
| | | X | | | | X |
| <---ESI1,255 +-----+============ \ | | <---ESI1,255 +-----+============ \ |
| <-----ESI2,200 | PE2 |========== \ vES2 | +----+ | <-----ESI2,200 | PE2 |========== \ vES2 | +----+
| +-----+ | \ ----------+CE2 | | +-----+ | \ ----------+CE2 |
| | | --------------+ | | | | --------------+ |
| +-----+ ----------------------+ | | +-----+ ----------------------+ |
| <-----ESI2,300 | PE3 +--/ | | +----+ | <-----ESI2,300 | PE3 +--/ | | +----+
| +-----+ +--------------+ | +-----+ +--------------+
--------------------+]]></artwork> --------------------+]]></artwork>
</figure> </figure>
<t><xref target="es-and-deterministic-df-election" format="default"/> show
<t><xref target="es-and-deterministic-df-election"/> shows three PEs s three PEs
that are connecting EVCs coming from the Aggregation Network to their that are connecting EVCs coming from the Aggregation Network to their
EVIs in the EVPN network. CE1 is connected to vES1 - that spans PE1 and EVIs in the EVPN network. CE1 is connected to vES1, which spans PE1 and
PE2 - and CE2 is connected to vES2, that is attached to PE1, PE2 and PE2, and CE2 is connected to vES2, which is attached to PE1, PE2, and
PE3.</t> PE3.</t>
<t>If the algorithm chosen for vES1 and vES2 is the
<t>If the algorithm chosen for vES1 and vES2 is DF Algorithm Highest-Preference or Lowest-Preference Algorithm, the PEs may become the
Highest-Preference or Lowest-Preference, the PEs may become Designated Designated
Forwarder irrespective of their IP address and based on the Forwarder irrespective of their IP address and based on the
administrative Preference value. The following sections provide some administrative preference value. The following sections provide some
examples of the procedures and how they are applied in the use-case of examples of the procedures and how they are applied in the use case of
<xref target="es-and-deterministic-df-election"/>.</t> <xref target="es-and-deterministic-df-election" format="default"/>.</t>
<section anchor="sect-4.1" numbered="true" toc="default">
<name>Use of the Highest-Preference and Lowest-Preference Algorithm</nam
e>
<section anchor="sect-4.1" <t>Assuming the operator wants to control -- in a flexible way -- what
title="Use of the Highest-Preference and Lowest Preference Algori
thm">
<t>Assuming the operator wants to control - in a flexible way - what
PE becomes the Designated Forwarder for a given virtual Ethernet PE becomes the Designated Forwarder for a given virtual Ethernet
Segment and the order in which the PEs become Designated Forwarder in Segment and the order in which the PEs become a Designated Forwarder in
case of multiple failures, the Highest-Preference or Lowest-Preference case of multiple failures, the Highest-Preference or Lowest-Preference
algorithms can be used. Using the example in <xref Algorithms can be used. Per the example in <xref target="es-and-determin
target="es-and-deterministic-df-election"/>, these algorithms are used istic-df-election" format="default"/>, these
algorithms are used
as follows:</t> as follows:</t>
<ol spacing="normal" type="a">
<t><list style="letters"> <li><t>vES1 and vES2 are now configurable with three optional
<t>vES1 and vES2 are now configurable with three optional parameters that are signaled in the DF Election
parameters that are signaled in the Designated Forwarder Election Extended Community. These parameters are the Preference,
extended community. These parameters are the Preference, Preemption (or "Don't Preempt" Capability) option, and DF algorithm. We
Preemption option (or "Don't Preempt" option) and DF Algorithm. We will
will represent these parameters as (Pref,DP,Alg). For instance, represent these parameters as (Pref, DP, Alg). For instance, vES1
vES1 (Pref,DP,Alg) is configured as (500,0,Highest-Preference) in (Pref, DP, Alg) is configured as:</t>
PE1, and (255,0,Highest-Preference) in PE2. vES2 is configured as <ul empty="true" spacing="compact">
(100,0,Highest-Preference), (200,0,Highest-Preference) and <li>(500, 0, Highest-Preference) in PE1,</li>
(300,0,Highest-Preference) in PE1, PE2 and PE3 respectively.</t> <li>(255, 0, Highest-Preference) in PE2.</li>
</ul>
<t>vES2 is configured as</t>
<ul empty="true" spacing="compact">
<li>(100, 0, Highest-Preference) in PE1,</li>
<li>(200, 0, Highest-Preference) in PE2, and</li>
<li>(300, 0, Highest-Preference) in PE3.</li>
</ul>
</li>
<li>
<t>The PEs advertise an Ethernet Segment route for each virtual <t>The PEs advertise an Ethernet Segment route for each virtual
Ethernet Segment, including the three parameters indicated in 'a' Ethernet Segment, including the three parameters indicated in (a)
above, in the Designated Forwarder Election Extended Community above, in the DF Election Extended Community
(encoded as described in <xref target="sect-3"/>).</t> (encoded as described in <xref target="sect-3" format="default"/>).<
/t>
<t>According to <xref target="RFC8584"/>, each PE will run the </li>
Designated Forwarder election algorithm upon expiration of the DF <li>
<t>According to <xref target="RFC8584" format="default"/>, each PE w
ill run the
DF election algorithm upon expiration of the DF
Wait timer. Each PE runs the Highest-Preference or Wait timer. Each PE runs the Highest-Preference or
Lowest-Preference DF Algorithm for each Ethernet Segment as Lowest-Preference Algorithm for each Ethernet Segment as
follows: <list style="symbols"> follows: </t>
<t>The PE will check the DF Algorithm value in each Ethernet <ul spacing="normal">
<li>
<t>The PE will check the DF algorithm value in each Ethernet
Segment route, and assuming all the Ethernet Segment routes Segment route, and assuming all the Ethernet Segment routes
(including the local route) are consistent in this DF (including the local route) are consistent in this DF
Algorithm (that is, all are configured for Highest-Preference algorithm (that is, all are configured for Highest-Preference
or Lowest-Preference, but not a mix), the PE runs the or Lowest-Preference, but not a mix), the PE runs the
procedure in this section. Otherwise, the procedure falls back procedure in this section. Otherwise, the procedure falls back
to <xref target="RFC7432"/> Default Algorithm. The to the default DF algorithm <xref target="RFC7432" format="defau
Highest-Preference and Lowest-Preference Algorithms are lt"/>.
different Algorithms, therefore if two PEs configured for The Highest-Preference and Lowest-Preference Algorithms are
Highest-Preference and Lowest-Preference respectively, are different algorithms; therefore, if two PEs configured for
Highest-Preference and Lowest-Preference, respectively, are
attached to the same Ethernet Segment, the operational attached to the same Ethernet Segment, the operational
Designated Forwarder Election Algorithm will fall back to the DF election algorithm will fall back to the
Default Algorithm.</t> default DF algorithm.</t>
</li>
<li>
<t>If all the PEs attached to the Ethernet Segment advertise <t>If all the PEs attached to the Ethernet Segment advertise
Highest-Preference Algorithm, each PE builds a list of the Highest-Preference Algorithm, each PE builds a list of
candidate PEs, ordered by Preference value from the candidate PEs, ordered by preference value from the
numerically highest value to lowest value. E.g., PE1 builds a numerically highest value to lowest value. For example, PE1 buil
ds a
list of candidate PEs for vES1 ordered by the Preference, from list of candidate PEs for vES1 ordered by the Preference, from
high to low: &lt;PE1, PE2&gt; (since PE1's preference is more high to low: &lt;PE1, PE2&gt; (since PE1's preference is more
preferred than PE2's). Hence, PE1 becomes the Designated preferred than PE2's). Hence, PE1 becomes the Designated
Forwarder for vES1. In the same way, PE3 becomes the Forwarder for vES1. In the same way, PE3 becomes the
Designated Forwarder for vES2.</t> Designated Forwarder for vES2.</t>
</li>
<li>
<t>If all the PEs attached to the Ethernet Segment advertise <t>If all the PEs attached to the Ethernet Segment advertise
Lowest-Preference Algorithm, then the candidate list is the Lowest-Preference Algorithm, then the candidate list is
ordered from the numerically lowest Preference value to the ordered from the numerically lowest preference value to the
highest Preference value. E.g., PE1's ordered list for vES1 is highest preference value. For example, PE1's ordered list for vE
S1 is
&lt;PE2, PE1&gt;. Hence, PE2 becomes the Designated Forwarder &lt;PE2, PE1&gt;. Hence, PE2 becomes the Designated Forwarder
for vES1. In the same way, PE1 becomes the Designated for vES1. In the same way, PE1 becomes the Designated
Forwarder for vES2.</t> Forwarder for vES2.</t>
</list></t> </li>
</ul>
<t>Assuming some maintenance tasks had to be executed on a PE the </li>
<li>
<t>Assuming some maintenance tasks had to be executed on a PE, the
operator may want to make sure the PE is not the Designated operator may want to make sure the PE is not the Designated
Forwarder for the Ethernet Segment so that the impact on the Forwarder for the Ethernet Segment so that the impact on the
service is minimized. E.g., if PE3 is going on maintenance and the service is minimized. For example, if PE3 is going on maintenance an
DF Algorithm is Highest-Preference, the operator could change d the
vES2's Preference on PE3 from 300 to e.g., 50 (hence, the Ethernet DF algorithm is Highest-Preference, the operator could change
Segment route from PE3 is updated with the new preference value) vES2's Preference on PE3 from 300 to, e.g., 50 (hence, the Ethernet
Segment route from PE3 is updated with the new preference value),
so that PE2 is forced to take over as Designated Forwarder for so that PE2 is forced to take over as Designated Forwarder for
vES2 (irrespective of the DP capability). Once the maintenance vES2 (irrespective of the "Don't Preempt" Capability). Once the main tenance
task on PE3 is over, the operator could decide to leave the latest task on PE3 is over, the operator could decide to leave the latest
configured preference value or configure the initial preference configured preference value or configure the initial preference
value back. A similar procedure can be used for DF Algorithm value back. A similar procedure can be used for the
Lowest-Preference too, that is, suppose the algorithm for vES2 is Lowest-Preference Algorithm too. For example, suppose the algorithm
for vES2 is
Lowest-Preference, and PE1 (the DF) goes on maintenance mode. The Lowest-Preference, and PE1 (the DF) goes on maintenance mode. The
operator could change vES2's Preference on PE1 from 100 to e.g., operator could change vES2's Preference on PE1 from 100 to, e.g.,
250, so that PE2 is forced to take over as Designated Forwarder 250, so that PE2 is forced to take over as the Designated Forwarder
for vES2.</t> for vES2.</t>
</li>
<li>
<t>In case of equal Preference in two or more PEs in the Ethernet <t>In case of equal Preference in two or more PEs in the Ethernet
Segment, the DP bit and the numerically lowest IP address of the Segment, the "Don't Preempt" Capability and the numerically lowest I P address of the
candidate PE(s) are used as tiebreakers. The procedures for the candidate PE(s) are used as tiebreakers. The procedures for the
use of the DP bit are specified in <xref target="sect-4.3"/>.If use of the "Don't Preempt" Capability are specified in <xref target= "sect-4.3" format="default"/>. If
more than one PE is advertising itself as the preferred Designated more than one PE is advertising itself as the preferred Designated
Forwarder, an implementation MUST first select the PE advertising Forwarder, an implementation <bcp14>MUST</bcp14> first select the PE
the DP bit set, and then select the PE with the lowest IP address advertising
(if the DP bit selection does not yield a unique candidate). The the "Don't Preempt" Capability set, and then select the PE with the
PE's IP address is the address used in the candidate list and it lowest IP address
(if the "Don't Preempt" Capability selection does not yield a unique
candidate). The
PE's IP address is the address used in the candidate list, and it
is derived from the Originating Router's IP address of the is derived from the Originating Router's IP address of the
Ethernet Segment route. In case PEs use the Originating Router's Ethernet Segment route. In case PEs use the Originating Router's
IP address of different families, an IPv4 address is always IP address of different families, an IPv4 address is always
considered numerically lower than an IPv6 address. Some examples considered numerically lower than an IPv6 address. Some examples
of the use of the DP bit and IP address tiebreakers follow: <list of using the "Don't Preempt" Capability and IP address tiebreakers f
style="symbols"> ollow: </t>
<t>If vES1 parameters were (500,0,Highest-Preference) in PE1 <ul spacing="normal">
and (500,1,Highest-Preference) in PE2, PE2 would be elected <li>
due to the DP bit. The same example applies if PE1 and PE2 <t>If vES1 parameters were (500, 0, Highest-Preference) in PE1
advertise Lowest-Preference DF Algorithm instead.</t> and (500, 1, Highest-Preference) in PE2, PE2 would be elected
due to the "Don't Preempt" Capability. The same example applies
<t>If vES1 parameters were (500,0,Highest-Preference) in PE1 if PE1 and PE2
and (500,0,Highest-Preference) in PE2, PE1 would be elected, advertise the Lowest-Preference Algorithm instead.</t>
</li>
<li>
<t>If vES1 parameters were (500, 0, Highest-Preference) in PE1
and (500, 0, Highest-Preference) in PE2, PE1 would be elected,
if PE1's IP address is lower than PE2's. Or PE2 would be if PE1's IP address is lower than PE2's. Or PE2 would be
elected if PE2's IP address is lower than PE1's. The same elected if PE2's IP address is lower than PE1's. The same
example applies if PE1 and PE2 advertise Lowest-Preference DF example applies if PE1 and PE2 advertise the Lowest-Preference
Algorithm instead.</t> Algorithm instead.</t>
</list></t> </li>
</ul>
<t>The Preference is an administrative option that MUST be </li>
configured on a per-Ethernet Segment basis, and it is normally <li>
configured from the management plane. The Preference value MAY <t>The Preference is an administrative option that <bcp14>MUST</bcp1
4> be
configured on a per-Ethernet-Segment basis, and it is normally
configured from the management plane. The preference value <bcp14>MA
Y</bcp14>
also be dynamically changed based on the use of local policies also be dynamically changed based on the use of local policies
that react to events on the PE. The following examples illustrate that react to events on the PE. The following examples illustrate
the use of local policy to change the Preference value in a the use of local policy to change the preference value in a
dynamic way.<list style="empty"> dynamic way.</t>
<t>E.g., on PE1, if the DF Algorithm is Highest-Preference, <ul spacing="normal">
ES1's Preference value can be lowered from 500 to 100 in case <li>
<t>On PE1, if the DF algorithm is Highest-Preference,
ES1's preference value can be lowered from 500 to 100 in case
the bandwidth on the ENNI port is decreased by 50% (that could the bandwidth on the ENNI port is decreased by 50% (that could
happen if e.g., the 2-port Link Aggregation Group between PE1 happen if, e.g., the 2-port Link Aggregation Group between PE1
and the Aggregation Network loses one port).</t> and the Aggregation Network loses one port).</t>
</li>
<t>Local policy MAY also trigger dynamic Preference changes <li>
<t>Local policy <bcp14>MAY</bcp14> also trigger dynamic Preferen
ce changes
based on the PE's bandwidth availability in the core, specific based on the PE's bandwidth availability in the core, specific
ports going operationally down, etc.</t> ports going operationally down, etc.</t>
</li>
<li>
<t>The definition of the actual local policies is out of scope <t>The definition of the actual local policies is out of scope
of this document.</t> of this document.</t>
</list></t> </li>
</list></t> </ul>
</li>
</ol>
<t>The Highest-Preference and Lowest-Preference Algorithms MAY be used <t>Highest-Preference and Lowest-Preference Algorithms <bcp14>MAY</bcp14 > be used
along with the AC-DF capability. Assuming all the PEs in the Ethernet along with the AC-DF capability. Assuming all the PEs in the Ethernet
Segment are configured consistently with Highest-Preference or Segment are configured consistently with the Highest-Preference or
Lowest-Preference Algorithm and AC-DF capability, a given PE in the Lowest-Preference Algorithm and AC-DF capability, a given PE in the
Ethernet Segment is not considered as a candidate for Designated Ethernet Segment is not considered as a candidate for DF election until
Forwarder Election until its corresponding Ethernet A-D per ES and its corresponding Ethernet A-D per ES and
Ethernet A-D per EVI routes are received, as described in <xref Ethernet A-D per EVI routes are received, as described in <xref target="
target="RFC8584"/>.</t> RFC8584" format="default"/>.</t>
<t>Highest-Preference and Lowest-Preference Algorithms can be
<t>The Highest-Preference and Lowest-Preference DF Algorithms can be
used in different virtual Ethernet Segments on the same PE. For used in different virtual Ethernet Segments on the same PE. For
instance, PE1 and PE2 can use Highest-Preference for vES1 and PE1, PE2 instance, PE1 and PE2 can use Highest-Preference for vES1 and PE1, and P
and PE3 Lowest-Preference for vES2. The use of one DF Algorithm over E2
and PE3 can use Lowest-Preference for vES2. The use of one DF algorithm
over
the other is the operator's choice. The existence of both provides the other is the operator's choice. The existence of both provides
flexibility and full control to the operator.</t> flexibility and full control to the operator.</t>
<t>The procedures in this document can be used in <xref <t>The procedures in this document can be used in an Ethernet Segment as
target="RFC7432"/>-based Ethernet Segment or virtual Ethernet Segment defined in <xref target="RFC7432" format="default"/> or a virtual Ethernet Segm
as in <xref target="I-D.ietf-bess-evpn-virtual-eth-segment"/>, and ent per <xref target="RFC9784" format="default"/> and
also EVPN networks as in <xref target="RFC8214"/>, <xref also in EVPN networks as described in <xref target="RFC8214" format="def
target="RFC7623"/> or <xref target="RFC8365"/>.</t> ault"/>, <xref target="RFC7623" format="default"/>, or <xref target="RFC8365" fo
rmat="default"/>.</t>
</section> </section>
<section anchor="sect-4.2" numbered="true" toc="default">
<section anchor="sect-4.2" <name>Use of the Highest-Preference or Lowest-Preference Algorithm in Et
title="Use of the Highest-Preference or Lowest-Preference algorit hernet Segments</name>
hm in [RFC7432] Ethernet Segments"> <t>While the Highest-Preference or Lowest-Preference Algorithm
<t>While the Highest-Preference or Lowest-Preference DF Algorithm described in <xref target="sect-4.1" format="default"/> is typically use
described in <xref target="sect-4.1"/> is typically used in virtual d in virtual
Ethernet Segment scenarios where there is normally an individual Ethernet Segment scenarios where there is normally an individual
Ethernet Tag per virtual Ethernet Segment, the existing <xref Ethernet Tag per virtual Ethernet Segment, the existing definition of an
target="RFC7432"/> definition of an Ethernet Segment allows Ethernet Segment <xref target="RFC7432" format="default"/> allows
potentially up to thousands of Ethernet Tags on the same Ethernet potentially up to thousands of Ethernet Tags on the same Ethernet
Segment. If this is the case, if Highest-Preference or Segment. If this is the case, and if the Highest-Preference or
Lowest-Preference Algorithm is configured in all the PEs of the Lowest-Preference Algorithm is configured in all the PEs of the
Ethernet Segment, the same PE will be the elected Designated Forwarder Ethernet Segment, the same PE will be the elected Designated Forwarder
for all the Ethernet Tags of the Ethernet Segment. A potential way to for all the Ethernet Tags of the Ethernet Segment. A potential way to
achieve a more granular load balancing is described below.</t> achieve a more granular load balancing is described below.</t>
<t>The Ethernet Segment is configured with an administrative <t>The Ethernet Segment is configured with an administrative
Preference value and an administrative DF Algorithm, i.e., preference value and an administrative DF algorithm, i.e.,
Highest-Preference or Lowest-Preference Algorithm. However, the Highest-Preference or Lowest-Preference Algorithm. However, the
administrative DF Algorithm (which is used to signal the DF Algorithm administrative DF algorithm (which is used to signal the DF algorithm
for the Ethernet Segment) MAY be overridden to a different operational for the Ethernet Segment) <bcp14>MAY</bcp14> be overridden to a differen
DF Algorithm for a range of Ethernet Tags. With this option, the PE t operational
builds a list of candidate PEs ordered by Preference, however the DF algorithm for a range of Ethernet Tags. With this option, the PE
builds a list of candidate PEs ordered by Preference; however, the
Designated Forwarder for a given Ethernet Tag will be determined by Designated Forwarder for a given Ethernet Tag will be determined by
the locally overridden DF Algorithm.</t> the locally overridden DF algorithm.</t>
<t>For instance:</t> <t>For instance:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Assuming ES3 is defined in PE1 and PE2, PE1 may be configured <t>Assuming ES3 is defined in PE1 and PE2, PE1 may be configured
as (500,0,Highest-Preference) for ES3 and PE2 as as (500, 0, Highest-Preference) and PE2 as (100, 0, Highest-Preferen
(100,0,Highest-Preference). Both PEs will advertise the Ethernet ce) for ES3.
Both PEs will advertise the Ethernet
Segment routes for ES3 with the indicated parameters in the DF Segment routes for ES3 with the indicated parameters in the DF
Election Extended Community.</t> Election Extended Community.</t>
</li>
<t>In addition, assuming VLAN-based service interfaces and that <li>
<t>In addition, assuming there are VLAN-based service interfaces and
that
the PEs are attached to all Ethernet Tags in the range 1-4000, the PEs are attached to all Ethernet Tags in the range 1-4000,
both PE1 and PE2 may be configured with (Ethernet both PE1 and PE2 may be configured with (Ethernet
Tag-range,Lowest-Preference), e.g., (2001-4000, Tag-range, Lowest-Preference), e.g., (2001-4000, Lowest-Preference).
Lowest-Preference).</t> </t>
</li>
<t>This will result in PE1 being Designated Forwarder for Ethernet <li>
<t>This will result in PE1 being the Designated Forwarder for Ethern
et
Tags 1-2000 (since they use the default Highest-Preference Tags 1-2000 (since they use the default Highest-Preference
Algorithm) and PE2 being Designated Forwarder for Ethernet Tags Algorithm) and PE2 being the Designated Forwarder for Ethernet Tags
2001-4000, due to the local policy overriding the 2001-4000, due to the local policy overriding the
Highest-Preference Algorithm.</t> Highest-Preference Algorithm.</t>
</list></t> </li>
</ul>
<t>While the above logic provides a perfect load balancing <t>While the above logic provides a perfect load-balancing
distribution of Ethernet Tags per Designated Forwarder when there are distribution of Ethernet Tags per Designated Forwarder when there are
only two PEs, for Ethernet Segments attached to three or more PEs, only two PEs, for Ethernet Segments attached to three or more PEs,
there would be only two Designated Forwarder PEs for all the Ethernet there would be only two Designated Forwarder PEs for all the Ethernet
Tags. Any other logic that provides a fair distribution of the Tags. Any other logic that provides a fair distribution of the
Designated Forwarder function among the three or more PEs is valid, as Designated Forwarder function among the three or more PEs is valid, as
long as that logic is consistent in all the PEs in the Ethernet long as that logic is consistent in all the PEs in the Ethernet
Segment. It is important to note that, when a local policy overrides Segment. It is important to note that, when a local policy overrides
the Highest-Preference or Lowest-Preference signaled by all the PEs in the Highest-Preference or Lowest-Preference signaled by all the PEs in
the Ethernet Segment, this local policy MUST be consistent in all the the Ethernet Segment, this local policy <bcp14>MUST</bcp14> be consisten t in all the
PEs of the Ethernet Segment. If the local policy is inconsistent for a PEs of the Ethernet Segment. If the local policy is inconsistent for a
given Ethernet Tag in the Ethernet Segment, packet drops or packet given Ethernet Tag in the Ethernet Segment, packet drops or packet
duplication may occur on that Ethernet Tag. For all these reasons the duplication may occur on that Ethernet Tag. For all these reasons, the
use of virtual Ethernet Segments is RECOMMENDED for cases where more use of virtual Ethernet Segments is <bcp14>RECOMMENDED</bcp14> for cases
than two PEs per Ethernet Segment exist and a good load balancing where more
than two PEs per Ethernet Segment exist and a good load-balancing
distribution per Ethernet Tag of the Designated Forwarder function is distribution per Ethernet Tag of the Designated Forwarder function is
desired. </t> desired. </t>
</section> </section>
<section anchor="sect-4.3" numbered="true" toc="default">
<section anchor="sect-4.3" title="The Non-Revertive Capability"> <name>The Non-Revertive Capability</name>
<t>As discussed in <xref target="sect-1.2"/> (d), a capability to NOT <t>As discussed in <xref target="DP-capability" format="none">item d</xr
ef> of <xref target="sect-1.2" format="default"/>, a capability to NOT
preempt the existing Designated Forwarder (for all the Ethernet Tags preempt the existing Designated Forwarder (for all the Ethernet Tags
in the Ethernet Segment) is required and therefore added to the in the Ethernet Segment) is required and therefore added to the
Designated Forwarder Election extended community. This option allows a DF Election Extended Community. This option allows a
non-revertive behavior in the Designated Forwarder election.</t> non-revertive behavior in the DF election.</t>
<t>Note that when a given PE in an Ethernet Segment is taken down for <t>Note that when a given PE in an Ethernet Segment is taken down for
maintenance operations, before bringing it back, the Preference may be maintenance operations, before bringing it back, the Preference may be
changed in order to provide a non-revertive behavior. The DP bit and changed in order to provide a non-revertive behavior. The "Don't Preempt " Capability and
the mechanism explained in this section will be used for those cases the mechanism explained in this section will be used for those cases
when a former Designated Forwarder comes back up without any when a former Designated Forwarder comes back up without any
controlled maintenance operation, and the non-revertive option is controlled maintenance operation, and the non-revertive option is
desired in order to avoid service impact.</t> desired in order to avoid service impact.</t>
<t>In <xref target="es-and-deterministic-df-election" format="default"/>
<t>In <xref target="es-and-deterministic-df-election"/>, we assume , we assume
that based on the Highest-Preference Algorithm, PE3 is the Designated that based on the Highest-Preference Algorithm, PE3 is the Designated
Forwarder for ESI2.</t> Forwarder for ESI2.</t>
<t>If PE3 has a link, EVC, or node failure, PE2 would take over as the
<t>If PE3 has a link, EVC or node failure, PE2 would take over as
Designated Forwarder. If/when PE3 comes back up again, PE3 will take Designated Forwarder. If/when PE3 comes back up again, PE3 will take
over, causing some unnecessary packet loss in the Ethernet over, causing some unnecessary packet loss in the Ethernet
Segment.</t> Segment.</t>
<t>The following procedure avoids preemption upon failure recovery <t>The following procedure avoids preemption upon failure recovery
(please refer to <xref target="es-and-deterministic-df-election"/>). (see <xref target="es-and-deterministic-df-election" format="default"/>) .
The procedure supports a non-revertive mode that can be used along The procedure supports a non-revertive mode that can be used along
with: <list style="symbols"> with: </t>
<ul spacing="normal">
<li>
<t>Highest-Preference Algorithm</t> <t>Highest-Preference Algorithm</t>
</li>
<li>
<t>Lowest-Preference Algorithm</t> <t>Lowest-Preference Algorithm</t>
</li>
<li>
<t>Highest-Preference or Lowest-Preference Algorithm, where a <t>Highest-Preference or Lowest-Preference Algorithm, where a
local policy overrides the Highest/Lowest-Preference tiebreaker local policy overrides the Highest-/Lowest-Preference tiebreaker
for a range of Ethernet Tags <xref target="sect-4.2"/></t> for a range of Ethernet Tags (<xref target="sect-4.2" format="defaul
</list>The procedure is described assuming Highest-Preference t"/>)</t>
</li>
</ul>
<t>The procedure is described, assuming the Highest-Preference
Algorithm in the Ethernet Segment, where local policy overrides the Algorithm in the Ethernet Segment, where local policy overrides the
tiebreaker for a given Ethernet Tag. The other cases above are a tiebreaker for a given Ethernet Tag. The other cases above are a
sub-set of this one and the differences are explained.</t> subset of this one, and the differences are explained.</t>
<ol spacing="normal" type="1"><li>
<t><list style="numbers"> <t>A "Don't Preempt" Capability is defined on a
<t>A "Don't Preempt" capability is defined on a per-PE / per-Ethernet-Segment basis, as described in <xref target="s
per-PE/per-Ethernet Segment basis, as described in <xref ect-3" format="default"/>. If "Don't Preempt" is disabled (default
target="sect-3"/>. If "Don't Preempt" is disabled (default
behavior), the PE sets DP to zero and advertises it in an Ethernet behavior), the PE sets DP to zero and advertises it in an Ethernet
Segment route. If "Don't Preempt" is enabled, the Ethernet Segment Segment route. If "Don't Preempt" is enabled, the Ethernet Segment
route from the PE indicates the desire of not being preempted by route from the PE indicates the desire of not being preempted by
the other PEs in the Ethernet Segment. All the PEs in an Ethernet the other PEs in the Ethernet Segment. All the PEs in an Ethernet
Segment should be consistent in their configuration of the DP Segment should be consistent in their configuration of the "Don't Pr
capability, however, this document does not enforce the eempt"
Capability; however, this document does not enforce the
consistency across all the PEs. In case of inconsistency in the consistency across all the PEs. In case of inconsistency in the
support of the DP capability in the PEs of the same Ethernet support of the "Don't Preempt" Capability in the PEs of the same Eth ernet
Segment, non-revertive behavior is not guaranteed. However, PEs Segment, non-revertive behavior is not guaranteed. However, PEs
supporting this capability still attempt this procedure.</t> supporting this capability still attempt this procedure.</t>
</li>
<t>We assume we want to avoid 'preemption' in all the PEs in the <li>
<t>Assuming we want to avoid 'preemption' in all the PEs in the
Ethernet Segment, the three PEs are configured with the "Don't Ethernet Segment, the three PEs are configured with the "Don't
Preempt" capability. In this example, we assume ESI2 is configured Preempt" Capability. In this example, we assume ESI2 is configured
as 'DP=enabled' in the three PEs.</t> as 'DP=enabled' in the three PEs.</t>
</li>
<li>
<t>We also assume vES2 is attached to Ethernet Tag-1 and Ethernet <t>We also assume vES2 is attached to Ethernet Tag-1 and Ethernet
Tag-2. vES2 uses Highest-Preference as DF Algorithm and a local Tag-2.
vES2 uses Highest-Preference as the DF algorithm, and a local
policy is configured in the three PEs to use Lowest-Preference for policy is configured in the three PEs to use Lowest-Preference for
Ethernet Tag-2. When vES2 is enabled in the three PEs, the PEs Ethernet Tag-2. When vES2 is enabled in the three PEs, the PEs
will exchange the Ethernet Segment routes and select PE3 as will exchange the Ethernet Segment routes and select PE3 as
Designated Forwarder for Ethernet Tag-1 (due to the the Designated Forwarder for Ethernet Tag-1 (due to the
Highest-Preference), and PE1 as Designated Forwarder for Ethernet Highest-Preference) and PE1 as the Designated Forwarder for Ethernet
Tag-2 (due to the Lowest-Preference).</t> Tag-2 (due to the Lowest-Preference).</t>
</li>
<t>If PE3's vES2 goes down (due to EVC failure - detected by OAM, <li>
or port failure or node failure), PE2 will become the Designated <t>If PE3's vES2 goes down (due to an EVC failure (as detected by OA
M protocols),
a port failure, or a node failure), PE2 will become the Designated
Forwarder for Ethernet Tag-1. No changes will occur for Ethernet Forwarder for Ethernet Tag-1. No changes will occur for Ethernet
Tag-2.</t> Tag-2.</t>
</li>
<li>
<t>When PE3's vES2 comes back up, PE3 will start a boot-timer (if <t>When PE3's vES2 comes back up, PE3 will start a boot-timer (if
booting up) or hold-timer (if the port or EVC recovers). That booting up) or hold-timer (if the port or EVC recovers). That
timer will allow some time for PE3 to receive the Ethernet Segment timer will allow some time for PE3 to receive the Ethernet Segment
routes from PE1 and PE2. This timer is applied between the INIT routes from PE1 and PE2. This timer is applied between the INIT
and the DF_WAIT states in the Designated Forwarder Election Finite and the DF_WAIT states in the DF election Finite
State Machine described in <xref target="RFC8584"/>. PE3 will State Machine described in <xref target="RFC8584" format="default"/>
then:<list style="symbols"> . PE3 will
then:</t>
<ul spacing="normal">
<li>
<t>Select a "reference-PE" among the Ethernet Segment routes <t>Select a "reference-PE" among the Ethernet Segment routes
in the virtual Ethernet Segment. If the Ethernet Segment uses in the virtual Ethernet Segment. If the Ethernet Segment uses
the Highest-Preference algorithm, select a "Highest-PE". If it the Highest-Preference Algorithm, select a "Highest-PE". If it
uses the Lowest-Preference algorithm, select a "Lowest-PE". If uses the Lowest-Preference Algorithm, select a "Lowest-PE". If
a local policy is in use, to override the a local policy is in use, to override the
Highest/Lowest-Preference for a range of Ethernet Tags (as Highest-/Lowest-Preference for a range of Ethernet Tags (as
discussed in <xref target="sect-4.2"/>), it is necessary to discussed in <xref target="sect-4.2" format="default"/>), it is
necessary to
select both a Highest-PE and a Lowest-PE. They are selected as select both a Highest-PE and a Lowest-PE. They are selected as
follows: <list style="symbols"> follows: </t>
<ul spacing="normal">
<li>
<t>The Highest-PE is the PE with higher Preference, using <t>The Highest-PE is the PE with higher Preference, using
the DP bit first (with DP=1 being better) and, after that, the "Don't Preempt" Capability first (with DP=1 being better ) and, after that,
the lower PE-IP address as tiebreakers. </t> the lower PE-IP address as tiebreakers. </t>
</li>
<li>
<t>The Lowest-PE is the PE with lower Preference, using <t>The Lowest-PE is the PE with lower Preference, using
the DP bit first (with DP=1 being better) and, after that, the "Don't Preempt" Capability first (with DP=1 being better ) and, after that,
the lower PE-IP address as tiebreakers. </t> the lower PE-IP address as tiebreakers. </t>
</li>
<t>In our example, the Highest-Preference algorithm is <li>
<t>In our example, the Highest-Preference Algorithm is
used, with a local policy to override it to use used, with a local policy to override it to use
Lowest-Preference for a range of Ethernet Tags. Therefore Lowest-Preference for a range of Ethernet Tags. Therefore,
PE3 selects a Highest-PE and a Lowest-PE. PE3 will select PE3 selects a Highest-PE and a Lowest-PE. PE3 will select
PE2 as Highest-PE over PE1, since, when comparing PE2 as the Highest-PE over PE1, because when comparing
(Pref,DP,PE-IP), (200,1,PE2-IP) wins over (100,1,PE1-IP). (Pref, DP, PE-IP), (200, 1, PE2-IP) wins over (100, 1, PE1-I
PE3 will select PE1 as Lowest-PE over PE2, since P).
(100,1,PE1-IP) wins over (200,1,PE2-IP). Note that if PE3 will select PE1 as the Lowest-PE over PE2, because
(100, 1, PE1-IP) wins over (200, 1, PE2-IP). Note that if
there were only one remote PE in the Ethernet Segment, there were only one remote PE in the Ethernet Segment,
Lowest and Highest PE would be the same PE.</t> the Lowest and Highest PE would be the same PE.</t>
</list></t> </li>
</ul>
</li>
<li>
<t>Check its own administrative Pref and compare it with the <t>Check its own administrative Pref and compare it with the
one of the Highest-PE and Lowest-PE that have the DP one of the Highest-PE and Lowest-PE that have the "Don't Preempt
capability set in their Ethernet Segment routes. Depending on "
this comparison PE3 sends the Ethernet Segment route with a Capability set in their Ethernet Segment routes. Depending on
(Pref,DP) that may be different from its administrative this comparison, PE3 sends the Ethernet Segment route with a
(Pref,DP):<list style="symbols"> (Pref, DP) that may be different from its administrative
<t>If PE3's Pref value is higher or equal than the (Pref, DP):</t>
<ul spacing="normal">
<li>
<t>If PE3's Pref value is higher than or equal to the
Highest-PE's, PE3 will send the Ethernet Segment route Highest-PE's, PE3 will send the Ethernet Segment route
with an 'in-use' operational Pref equal to the with an 'in-use' operational Pref equal to the
Highest-PE's and DP=0.</t> Highest-PE's and DP=0.</t>
</li>
<t>If PE3's Pref value is lower or equal than the <li>
<t>If PE3's Pref value is lower than or equal to the
Lowest-PE's, PE3 will send the Ethernet Segment route with Lowest-PE's, PE3 will send the Ethernet Segment route with
an 'in-use' operational Preference equal to the an 'in-use' operational Preference equal to the
Lowest-PE's and DP=0.</t> Lowest-PE's and DP=0.</t>
</li>
<t>If PE3's Pref value is not higher or equal than the <li>
Highest-PE's and is not lower or equal than the <t>If PE3's Pref value is not higher than or equal to the
Highest-PE's and is not lower than or equal to the
Lowest-PE's, PE3 will send the Ethernet Segment route with Lowest-PE's, PE3 will send the Ethernet Segment route with
its administrative (Pref,DP)=(300,1).</t> its administrative (Pref, DP)=(300, 1).</t>
</li>
<li>
<t>In this example, PE3's administrative Pref=300 is <t>In this example, PE3's administrative Pref=300 is
higher than the Highest-PE with DP=1, that is, PE2 higher than the Highest-PE with DP=1, that is, PE2
(Pref=200). Hence, PE3 will inherit PE2's preference and (Pref=200). Hence, PE3 will inherit PE2's preference and
send the Ethernet Segment route with an operational send the Ethernet Segment route with an operational
'in-use' (Pref,DP)=(200,0).</t> 'in-use' (Pref, DP)=(200, 0).</t>
</list></t> </li>
</ul>
<t>Note that, a PE will always send its DP capability set to </li>
zero as long as the advertised Pref is the 'in-use' <li>
<t>Send its "Don't Preempt" Capability set to
zero, as long as the advertised Pref is the 'in-use'
operational Pref (as opposed to the 'administrative' operational Pref (as opposed to the 'administrative'
Pref).</t> Pref).</t>
</li>
<t>This Ethernet Segment route update sent by PE3, with <li>
(200,0,PE3-IP), will not cause any Designated Forwarder <t>Not trigger any Designated Forwarder changes for Ethernet Tag
switchover for any Ethernet Tag. PE2 will continue being -1. This Ethernet Segment route update sent by PE3, with
Designated Forwarder for Ethernet Tag-1. This is because the (200, 0, PE3-IP), will not cause any Designated Forwarder
DP bit will be used as a tiebreaker in the Designated switchover for any Ethernet Tag. This is because the
Forwarder election. That is, if a PE has two candidate PEs "Don't Preempt" Capability will be used as a tiebreaker in the
DF election. That is, if a PE has two candidate PEs
with the same Pref, it will pick the one with DP=1. There are with the same Pref, it will pick the one with DP=1. There are
no Designated Forwarder changes for Ethernet Tag-2 either.</t> no Designated Forwarder changes for Ethernet Tag-2 either.</t>
</list></t> </li>
</ul>
</li>
<li>
<t>For any subsequent received update/withdraw in the Ethernet <t>For any subsequent received update/withdraw in the Ethernet
Segment, the PEs will go through the process described in (5) to Segment, the PEs will go through the process described in (5) to
select Highest and Lowest-PEs, now considering themselves as select the Highest-PEs and Lowest-PEs, now considering themselves as
candidates. For instance, if PE2 fails, upon receiving PE2's candidates. For instance, if PE2 fails upon receiving PE2's
Ethernet Segment route withdrawal, PE3 and PE1 will go through the Ethernet Segment route withdrawal, PE3 and PE1 will go through the
selection of new Highest and Lowest-PEs (considering their own selection of the new Highest-PEs and Lowest-PEs (considering their o
active Ethernet Segment route) and then they will run the wn
Designated Forwarder Election.<list style="symbols"> active Ethernet Segment route), and then they will run the
<t>If a PE selects itself as new Highest or Lowest-PE and it DF election.</t>
<ul spacing="normal">
<li>
<t>If a PE selects itself as the new Highest-PE or Lowest-PE and
it
was not before, the PE will then compare its operational was not before, the PE will then compare its operational
'in-use' Pref with its administrative Pref. If different, the 'in-use' Pref with its administrative Pref. If different, the
PE will send an Ethernet Segment route update with its PE will send an Ethernet Segment route update with its
administrative Pref and DP values. In the example, PE3 will be administrative Pref and DP values. In the example, PE3 will be
the new Highest-PE, therefore it will send an Ethernet Segment the new Highest-PE; therefore, it will send an Ethernet Segment
route update with (Pref,DP)=(300,1).</t> route update with (Pref, DP)=(300, 1).</t>
</li>
<t>After running the Designated Forwarder Election, PE3 will <li>
<t>After running the DF election, PE3 will
become the new Designated Forwarder for Ethernet Tag-1. No become the new Designated Forwarder for Ethernet Tag-1. No
changes will occur for Ethernet Tag-2.</t> changes will occur for Ethernet Tag-2.</t>
</list></t> </li>
</list></t> </ul>
</li>
<t>Note that, irrespective of the DP bit, when a PE or Ethernet </ol>
Segment comes back and the PE advertises a Designated Forwarder <t>Note that, irrespective of the "Don't Preempt" Capability, when a PE
Election Algorithm different from the one configured in the rest of or Ethernet
Segment comes back and the PE advertises a DF
election algorithm different from the one configured in the rest of
the PEs in the Ethernet Segment, all the PEs in the Ethernet Segment the PEs in the Ethernet Segment, all the PEs in the Ethernet Segment
MUST fall back to the Default <xref target="RFC7432"/> Algorithm.</t> <bcp14>MUST</bcp14> fall back to the default DF algorithm <xref target=" RFC7432" format="default"/>.</t>
<t>This document does not modify the use of the P and B bits in the <t>This document does not modify the use of the P and B bits in the
Ethernet A-D per EVI routes <xref target="RFC8214"/> advertised by the Ethernet A-D per EVI routes <xref target="RFC8214" format="default"/> ad
PEs in the Ethernet Segment after running the Designated Forwarder vertised by the
Election, irrespective of the revertive or non-revertive behavior in PEs in the Ethernet Segment after running the DF
election, irrespective of the revertive or non-revertive behavior in
the PE.</t> the PE.</t>
</section> </section>
</section> </section>
<section anchor="sect-5" numbered="true" toc="default">
<section anchor="sect-5" title="Security Considerations"> <name>Security Considerations</name>
<t>This document describes a Designated Forwarder Election Algorithm <t>This document describes a DF election algorithm
that provides absolute control (by configuration) over what PE is the that provides absolute control (by configuration) over what PE is the
Designated Forwarder for a given Ethernet Tag. While this control is Designated Forwarder for a given Ethernet Tag. While this control is
desired in many situations, a malicious user that gets access to the desired in many situations, a malicious user that gets access to the
configuration of a PE in the Ethernet Segment may change the behavior of configuration of a PE in the Ethernet Segment may change the behavior of
the network. In other DF Algorithms such as HRW, the Designated the network. In other DF algorithms such as HRW, the DF election is more a
Forwarder Election is more automated and cannot be determined by utomated and cannot be determined by
configuration. With Highest-Preference or Lowest-Preference as DF configuration.
Algorithm, an attacker may change the configuration of the Preference If the DF algorithm is Highest-Preference or Lowest-Preference, an attacke
value on a PE and Ethernet Segment, and impact the traffic going through r may change the configuration of the preference
value on a PE and Ethernet Segment to impact the traffic going through
that PE and Ethernet Segment.</t> that PE and Ethernet Segment.</t>
<t>The non-revertive capability described in this document may be seen <t>The non-revertive capability described in this document may be seen
as a security improvement over the regular EVPN revertive Designated as a security improvement over the regular EVPN revertive DF election: an
Forwarder Election: an intentional link (or node) "flapping" on a PE intentional link (or node) "flapping" on a PE
will only cause service disruption once, when the PE goes to will only cause service disruption once, when the PE goes to
Non-Designated Forwarder state. However, an attacker who gets access to Non-Designated Forwarder state. However, an attacker who gets access to
the configuration of a PE in the Ethernet Segment will be able to the configuration of a PE in the Ethernet Segment will be able to
disable the non-revertive behavior, by advertising a conflicting DF disable the non-revertive behavior, by advertising a conflicting DF
election algorithm and thereby forcing fallback to the Default election algorithm and thereby forcing fallback to the default DF
algorithm. </t> algorithm. </t>
<t>The document also describes how a local policy can override the <t>The document also describes how a local policy can override the
Highest-Preference or Lowest-Preference algorithms for a range of Highest-Preference or Lowest-Preference Algorithms for a range of
Ethernet Tags in the Ethernet Segment. If the local policy is not Ethernet Tags in the Ethernet Segment. If the local policy is not
consistent across all PEs in the Ethernet Segment and there is an consistent across all PEs in the Ethernet Segment and there is an
Ethernet Tag that ends up with an inconsistent use of Highest-Preference Ethernet Tag that ends up with an inconsistent use of Highest-Preference
or Lowest-Preference in different PEs, packet drop or packet duplication or Lowest-Preference in different PEs, packet drop or packet duplication
may occur for that Ethernet Tag.</t> may occur for that Ethernet Tag.</t>
<t>Finally, the two DF election algorithms specified
<t>Finally, the two Designated Forwarder Election Algorithms specified
in this document (Highest-Preference and Lowest-Preference) do not in this document (Highest-Preference and Lowest-Preference) do not
change the way the PEs share their Ethernet Segment information, change the way the PEs share their Ethernet Segment information,
compared to the algorithms in <xref target="RFC7432"/> and <xref compared to the algorithms in <xref target="RFC7432" format="default"/> an
target="RFC8584"/>. Therefore the security considerations in <xref d <xref target="RFC8584" format="default"/>. Therefore, the security considerati
target="RFC7432"/> and <xref target="RFC8584"/> apply to this document ons in <xref target="RFC7432" format="default"/> and <xref target="RFC8584" form
too.</t> at="default"/> apply to this document
</section> as well.</t>
<section anchor="sect-6" title="IANA Considerations">
<t>This document solicits:</t>
<t><list style="symbols">
<t>The allocation of two new values in the "DF Alg" registry created
by <xref target="RFC8584"/> as follows:<figure>
<artwork><![CDATA[Alg Name R
eference
2 Highest-Preference Algorithm This document
TBD Lowest-Preference Algorithm This document]]></artwork>
</figure></t>
<t>The allocation of a new value in the "DF Election Capabilities"
registry created by <xref target="RFC8584"/> for the 2-octet Bitmap
field in the DF Election Extended Community (Border gateway Protocol
(BGP) Extended Communities registry), as follows:<figure>
<artwork><![CDATA[Bit Name Ref
erence
0 D (Don't Preempt) Capability This document]]></artwork>
</figure></t>
</list><list style="symbols">
<t>To update the reference of the "DF Election Extended Community"
field, in the EVPN Extended Community Sub-Types registry, as
follows:<figure>
<artwork><![CDATA[Sub-Type Value Name
Reference
0x06 DF Election Extended Community [RFC8584] and This Document
]]></artwork>
</figure> </t>
</list></t>
</section>
<section anchor="sect-7" title="Acknowledgments ">
<t>The authors would like to thank Kishore Tiruveedhula and Sasha
Vainshtein for their review and comments. Also thank you to Luc Andre
Burdet and Stephane Litkowski for their thorough review and suggestions
for a new DF Algorithm for lowest-preference.</t>
</section> </section>
<section anchor="sect-6" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>Per this document, IANA has:</t>
<section anchor="sect-8" title="Contributors "> <ul spacing="normal">
<t>In addition to the authors listed, the following individuals also <li>
contributed to this document:</t> <t>Allocated two new values in the "DF Alg" registry created
by <xref target="RFC8584" format="default"/>, as follows:</t>
<t>Tony Przygienda, Juniper</t>
<t>Satya Mohanty, Cisco</t> <table align="left">
<thead>
<tr>
<th>Alg</th>
<th>Name</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>2</td>
<td>Highest-Preference Algorithm</td>
<td>RFC 9785</td>
</tr>
<tr>
<td>3</td>
<td>Lowest-Preference Algorithm</td>
<td>RFC 9785</td>
</tr>
</tbody>
</table>
</li>
<li>
<t>Allocated a new value in the "DF Election Capabilities"
registry created by <xref target="RFC8584" format="default"/> for the
2-octet Bitmap
field in the DF Election Extended Community (under the "Border
Gateway Protocol (BGP) Extended Communities" registry group), as follo
ws:</t>
<t>Kiran Nagaraj, Nokia</t> <table align="left">
<thead>
<tr>
<th>Bit</th>
<th>Name</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>D (Don't Preempt) Capability</td>
<td>RFC 9785</td>
</tr>
</tbody>
</table>
</li>
<t>Vinod Prabhu, Nokia</t> <li>
<t>Listed this document as an additional reference for the DF Election
Extended Community field in the "EVPN Extended Community Sub-Types" registry, a
s follows:</t>
<t>Selvakumar Sivaraj, Juniper</t> <table align="left">
<thead>
<tr>
<th>Sub-Type Value</th>
<th>Name</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0x06</td>
<td>DF Election Extended Community</td>
<td><xref target="RFC8584"/> and RFC 9785</td>
</tr>
</tbody>
</table>
</li>
</ul>
<t>Sami Boutros, VMWare</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
&RFC7432;
&RFC8584;
&RFC2119;
&RFC8174;
&I-D.ietf-bess-evpn-virtual-eth-segment; <name>References</name>
</references> <references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
432.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
584.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<references title="Informative References"> <!-- draft-ietf-bess-evpn-virtual-eth-segment-19 companion doc RFC 9784. -->
&RFC8214;
&RFC8365; <reference anchor="RFC9784" target="https://www.rfc-editor.org/info/rfc9784">
<front>
<title>EVPN Virtual Ethernet Segment</title>
<author initials="A." surname="Sajassi" fullname="Ali Sajassi">
<organization>Cisco Systems</organization>
</author>
<author initials="P." surname="Brissette" fullname="Patrice Brissette">
<organization>Cisco Systems</organization>
</author>
<author initials="R." surname="Schell" fullname="Rick Schell">
<organization>Verizon</organization>
</author>
<author initials="J." surname="Drake" fullname="John Drake">
<organization>Juniper</organization>
</author>
<author initials="J." surname="Rabadan" fullname="Jorge Rabadan">
<organization>Nokia</organization>
</author>
<date month="May" year="2025" />
</front>
<seriesInfo name="RFC" value="9784"/>
<seriesInfo name="DOI" value="10.17487/9784"/>
</reference>
&RFC7623; </references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
214.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
365.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
623.xml"/>
</references>
</references> </references>
<section anchor="sect-7" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Kishore
Tiruveedhula"/> and <contact fullname="Sasha Vainshtein"/> for their
reviews and comments. Also, thank you to <contact fullname="Luc André
Burdet"/> and <contact fullname="Stephane Litkowski"/> for their
thorough reviews and suggestions for a new
Lowest-Preference Algorithm.</t>
</section>
<section anchor="sect-8" numbered="false" toc="default">
<name>Contributors</name>
<t>In addition to the authors listed, the following individuals also
contributed to this document:</t>
<contact fullname="Tony Przygienda">
<organization>Juniper</organization>
</contact>
<contact fullname="Satya Mohanty">
<organization>Cisco</organization>
</contact>
<contact fullname="Kiran Nagaraj">
<organization>Nokia</organization>
</contact>
<contact fullname="Vinod Prabhu">
<organization>Nokia</organization>
</contact>
<contact fullname="Selvakumar Sivaraj">
<organization>Juniper</organization>
</contact>
<contact fullname="Sami Boutros">
<organization>VMWare</organization>
</contact>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 180 change blocks. 
608 lines changed or deleted 741 lines changed or added

This html diff was produced by rfcdiff 1.48.