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"?> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<?rfc symrefs="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="false" version="3">
<?rfc sortrefs="no"?> <!--[rfced] Please note that the title has been updated as follows.
The abbreviation has been expanded per Section 3.6 of RFC 7322
("RFC Style Guide"). Please review.
<?rfc text-list-symbols="o-*+"?> Original:
Preference-based EVPN DF Election
<?rfc toc="yes"?> Current:
Preference-Based EVPN Designated Forwarder (DF) Election
-->
<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"/>
<area>RTG</area>
<workgroup>bess</workgroup>
<date day="9" month="October" year="2023"/> <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<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 multi-homed device/network in the case of an All-Active multi-homing
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 multi-homing. 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 Designated Forwarder 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 Designated Forwarder Election algorithm
<t>This document proposes a Designated Forwarder Election algorithm that 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 multi-homed device/network in
the case of an all-active multi-homing Ethernet Segment or BUM and the case of an All-Active multi-homing Ethernet Segment or BUM and
unicast traffic to a multi-homed device or network in the case of unicast traffic to a multi-homed device or network in the case of
single-active multi-homing. The Designated Forwarder is selected out Single-Active multi-homing. 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 Designated
Forwarder Election Algorithm, or DF Alg as per <xref Forwarder Election Algorithm or to DF Alg as per <xref target="RFC8584"
target="RFC8584"/>.</t> format="default"/>.</t>
<!-- [rfced] We note that the term "Default Designated Forwarder
Algorithm" does not appear in RFC 7432 (it does use "Designated
Forwarder"). Is an update needed to the term, reference, or
placement of the citation?
<t>While the Default Designated Forwarder Algorithm <xref Original:
target="RFC7432"/> or the Highest Random Weight algorithm (HRW) <xref While the Default Designated Forwarder Algorithm [RFC7432] or the
target="RFC8584"/> provide an efficient and automated way of selecting Highest Random Weight algorithm (HRW) [RFC8584] provide an efficient
and automated way of selecting the Designated Forwarder across
different Ethernet Tags in the Ethernet Segment, there are some
use-cases where a more user-controlled method is required.
-->
<t>While the Default Designated Forwarder Algorithm <xref target="RFC743
2" format="default"/> or the Highest Random Weight (HRW) algorithm <xref target=
"RFC8584" format="default"/> provide an efficient and automated 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
Forwarder switchover in order to carry out some maintenance tasks on Forwarder 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 Designa
target="RFC7432"/> Designated Forwarder election procedures that ted Forwarder election 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 Designated Forwarder 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 multi-homing 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 Designated Forwarder Election
Algorithm, which is sometimes shortened to "Alg" in this document.</dd>
<t><list style="symbols"> <!--[rfced] DP vs. D
<t>AC - Attachment Circuit. An AC has an Ethernet Tag associated to
it.</t>
<t>CE - Customer Equipment router.</t> a) In Section 2, we note that the description for "DP" includes "(me)";
however, "(me)" is not used elsewhere in the document or in the
"DF Election Capabilities" registry
<https://www.iana.org/assignments/bgp-extended-communities>.
Should it be removed?
<t>DF - Designated Forwarder.</t> Current:
DP: Refers to the "Don't Preempt" (me) capability in the
Designated Forwarder Election extended community.
<t>DF Alg - refers to Designated Forwarder Election Algorithm. This Perhaps:
is sometimes shortened to &ldquo;Alg&rdquo; in this document.</t> DP: Refers to the "Don't Preempt" capability in the
DF Election Extended Community.
<t>DP - refers to the "Don't Preempt" (me) capability in the b) Section 2 says "DP" refers to the "Don't Preempt" capability, but
Designated Forwarder Election extended community.</t> Section 3 says "DP" refers to the "D bit" or "'Don't Preempt' bit".
There are also 11 instances of "DP bit" and "DP capability". Are the
'Don't Preempt' bit and "Don't Preempt" capability the same or
different? Please let us know if/how we can make these consistent
within the text and IANA registry.
<t>ENNI - Ethernet Network to Network Interface.</t> Current (in the running text):
<t>ES and vES - Ethernet Segment and virtual Ethernet Segment.</t> "Don't Preempt" capability vs.
'Don't Preempt' bit vs.
DP capability vs.
DP bit vs.
D bit
<t>Ethernet A-D per EVI route - refers to <xref target="RFC7432"/> In the DF Election Capabilities Registry:
route type 1 or Auto-Discovery per EVPN Instance route.</t>
<t>EVC - Ethernet Virtual Circuit.</t> Bit Name Reference
- - - - - - - - - - - - - - - - - - - - - - -
0 D (Don't Preempt) Capability RFC XXXX
-->
<t>EVI - EVPN Instance.</t> <dt>DP:</dt><dd>Refers to the "Don't Preempt" (me) capability in the
DF Election Extended Community.</dd>
<dt>ENNI:</dt><dd>External Network-Network Interface</dd>
<dt>ES and vES:</dt><dd>Ethernet Segment and virtual Ethernet Segment.</
dd>
<t>Ethernet Tag - used to represent a Broadcast Domain that is <!--[rfced] Should "route type 1" be "Route Type (1 octet)"
configured on a given Ethernet Segment for the purpose of Designated per RFC 7432 or as "Route Type 1" per the description of
Forwarder election. Note that any of the following may be used to "Ethernet A-D per EVI route" in RFC 8584 (which updates RFC 7432)?
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> Also, may we move the citation to the end of the sentence as we note that
it refers to both "Route Type 1" and "Auto-Discovery".
Original:
Ethernet A-D per EVI route - refers to [RFC7432] route type 1 or
Auto-Discovery per EVPN Instance route.
Perhaps:
Ethernet A-D per EVI route: Refers to Route Type 1 or
Auto-Discovery per the EVPN Instance route [RFC7432].
-->
<dt>Ethernet A-D per EVI route:</dt><dd>Refers to <xref target="RFC7432"
format="default"/> route type 1 or Auto-Discovery per
EVPN Instance route.</dd>
<dt>EVC:</dt><dd>Ethernet Virtual Circuit</dd>
<dt>EVI:</dt><dd>EVPN Instance</dd>
<dt>Ethernet Tag:</dt><dd>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: VLAN IDs (VIDs) (including Q-in-Q tags), c
onfigured
IDs, VXLAN Network Identifiers (VNIs), normalized VIDs, Service
Instance Identifiers (I-SIDs), etc., as long as the representation of th
e
broadcast domains is configured consistently across the multi-homed
PEs attached to that Ethernet Segment. The Ethernet Tag value
<bcp14>MUST NOT</bcp14> be zero.</dd>
<dt>HRW:</dt><dd>Highest Random Weight, as per <xref target="RFC8584"
format="default"/>.</dd>
<dt>OAM:</dt><dd>Operations, Administration, and Maintenance.</dd>
</dl>
<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 h
Highest-Preference or Lowest-Preference DF Algorithms. The format of the Highest-Preference or Lowest-Preference DF Algorithms. The format of the
DF Election Extended Community that is used in this document 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">
<li><t>The DF Algorithm can have the following values:</t>
<ul spacing="normal">
<t><list style="symbols"> <!--[rfced] Is it correct that the default DF algorithm is the same
<t>DF Algorithm can have the following values:<list style="symbols"> as the "modulus-based algorithm as per [RFC7432]"? If so,
<t>Alg 0 - Default Designated Forwarder Election algorithm, or even though this text currently matches RFC 8584, would it be
modulus-based algorithm as per <xref target="RFC7432"/>.</t> more clear to use "i.e.," or another phrase to indicate that
these are equivalent (rather than alternatives)?
<t>Alg 1 - HRW algorithm as per <xref target="RFC8584"/>.</t> Original:
Alg 0 - Default Designated Forwarder Election algorithm, or
modulus-based algorithm as per [RFC7432].
<t>Alg 2 - Highest-Preference algorithm (this document <xref Perhaps:
target="sect-4.1"/>).</t> Alg 0 - Default Designated Forwarder Election algorithm, i.e.,
the modulus-based algorithm as per [RFC7432].
<t>Alg TBD - Lowest-Preference algorithm (this document <xref For comparison, from RFC 8584:
target="sect-4.1"/>). TBD will be replaced by the allocated - Type 0: Default DF election algorithm, or modulus-based
value at the time of publication.</t> algorithm as defined in [RFC7432].
</list></t> -->
</list><list style="symbols">
<t>Bitmap (2 octets) encodes "capabilities" <xref
target="RFC8584"/>, where this document defines the "Don't Preempt"
capability, used to indicate if a PE supports a non-revertive
behavior:</t>
</list></t>
<figure anchor="bitmap-field-in-the-df-election-extended-community" <li>Alg 0 - Default Designated Forwarder Election algorithm, or
title="Bitmap field in the DF Election Extended Community"> modulus-based algorithm as per <xref target="RFC7432"
<artwork><![CDATA[ format="default"/>.</li>
<li>Alg 1 - HRW algorithm as per <xref target="RFC8584" format="defa
ult"/>.</li>
<li>Alg 2 - Highest-Preference Algorithm (<xref target="sect-4.1" fo
rmat="default"/>).</li>
<li>Alg 3 - Lowest-Preference Algorithm (<xref
target="sect-4.1" format="default"/>).</li>
</ul>
</li>
<li><t>Bitmap (2 octets) encodes "capabilities" <xref target="RFC8584"
format="default"/>, whereas this document defines the "Don't Preempt"
capability, which is used to indicate if a PE supports a non-revertive
behavior:</t>
<!--[rfced] Should Figure 2 be updated to show the T bit as
defined in RFC-to-be 9722 (draft-ietf-bess-evpn-fast-df-recovery-12),
which also update RFC 8584 and is currently in AUTH48 state? If so,
should any text be added to mention that document?
Current:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Perhaps:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|A| |T| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-->
<figure anchor="bitmap-field-in-the-df-election-extended-community">
<name>Bitmap Field in the DF Election Extended Community</name>
<artwork name="" type="" align="left" alt=""><![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">
<li>Bit 0 (corresponds to Bit 24 of the DF
Election Extended Community, and it is defined by this document):
The D bit, or 'Don't Preempt' bit ("DP" hereafter), determines if th
e
PE advertising the Ethernet Segment route requests the remote PEs
in the Ethernet Segment to not preempt it as the Designated
Forwarder. The default value is DP=0, which is compatible with the
'preempt' or 'revertive' behavior in the Default DF Algorithm
<xref target="RFC7432" format="default"/>. The DP capability is
supported by the Highest-Preference or Lowest-Preference DF
Algorithms. The procedures of the "Don't Preempt" capability for
other DF Algorithms are out of the scope of this document. The
procedures of the "Don't Preempt" capability for the
Highest-Preference and Lowest-Preference DF Algorithms are
described in <xref target="sect-4.1" format="default"/>.</li>
<t><list style="empty"> <!--[rfced] FYI: We removed "described by this document" in the
<t><list style="symbols"> following entry (in Section 3) to avoid redundancy as the
<t>Bit 0 (corresponds to Bit 24 of the Designated Forwarder description points to Section 4.1 of this document. Please
Election Extended Community and it is defined by this document): let us know of any objections.
the D bit or 'Don't Preempt' bit (DP hereafter), determines if
the PE advertising the Ethernet Segment route requests the
remote PEs in the Ethernet Segment not to preempt it as
Designated Forwarder. The default value is DP=0, which is
compatible with the 'preempt' or 'revertive' behavior in the
Default DF Algorithm <xref target="RFC7432"/>. The DP capability
is supported by the Highest-Preference or Lowest-Preference DF
Algorithms. The procedures of the "Don't Preempt" capability for
other DF Algorithms are out of the scope of this document. The
procedures of the "Don't Preempt" capability for the
Highest-Preference and Lowest-Preference DF Algorithms are
described in <xref target="sect-4.1"/>.</t>
<t>Bit 1: AC-DF or AC-Influenced Designated Forwarder Election Original:
is described in <xref target="RFC8584"/>. When set to 1, it * Designated Forwarder (DF) Preference (described in this document):
indicates the desire to use AC-Influenced Designated Forwarder defines a 2-octet value that indicates the PE preference to become
Election with the rest of the PEs in the Ethernet Segment. The the Designated Forwarder in the Ethernet Segment, as described in
AC-DF capability bit MAY be set along with the DP capability and Section 4.1.
the Highest-Preference or Lowest-Preference DF Algorithms.</t>
</list></t>
</list><list style="symbols">
<t>Designated Forwarder (DF) Preference (described in this
document): defines a 2-octet value that indicates the PE preference
to become the Designated Forwarder in the Ethernet Segment, as
described in <xref target="sect-4.1"/>. The allowed values are
within the range 0-65535, and the default value MUST be 32767. This
value is the midpoint in the allowed Preference range of values,
which gives the operator the flexibility of choosing a significant
number of values, above or below the default Preference. A
numerically higher or lower value of this field is more preferred
for Designated Forwarder election depending on the DF Algorithm
being used, as explained in <xref target="sect-4.1"/>. The
Designated Forwarder Preference field is specific to DF Algorithms
Highest-Preference and Lowest-Preference, and this document does not
define any meaning for other algorithms. If the DF Algorithm is
different from Highest-Preference or Lowest-Preference, these two
octets can be encoded differently.</t>
<t>RSV and Reserved fields (from bit 16 to bit 18, and from bit 40 Current:
to 47): when DF Algorithm is set to Highest-Preference or * Designated Forwarder (DF) Preference: Defines a 2-octet value that
Lowest-Preference algorithm, the values are set to zero when indicates the PE preference to become the Designated Forwarder in
advertising the Ethernet Segment route, and they are ignored when the Ethernet Segment, as described in Section 4.1.
receiving the Ethernet Segment route.</t> -->
</list></t>
</section>
<section anchor="sect-4" title="Solution description"> <li>Bit 1: AC-Influenced DF (AC-DF) election is
<t><xref target="es-and-deterministic-df-election"/> illustrates an described in <xref target="RFC8584" format="default"/>. When set
example that will be used in the description of the solution.</t> to 1, it indicates the desire to use AC-DF with the rest of the PEs
in the Ethernet
Segment. The AC-DF capability bit <bcp14>MAY</bcp14> be set along
with the DP capability and Highest-Preference or
Lowest-Preference DF Algorithms.</li>
</ul>
</li>
<li>Designated Forwarder (DF) Preference:
Defines a 2-octet value that indicates the PE preference to become the
Designated Forwarder in the Ethernet Segment, as described in <xref
target="sect-4.1" format="default"/>. The allowed values are within
the range 0-65535, and the default value <bcp14>MUST</bcp14> be
32767. This value is the midpoint in the allowed Preference range of
values, which gives the operator the flexibility of choosing a
significant number of values, above or below the default Preference. A
numerically higher or lower value of this field is more preferred for
Designated Forwarder election depending on the DF Algorithm being
used, as explained in <xref target="sect-4.1" format="default"/>.
<figure anchor="es-and-deterministic-df-election" <!--[rfced] Is "DF Algorithms" intended to be singular possessive
title="Preference-based DF Election"> (option A) or plural (option B)? Please let us know how we may
<artwork><![CDATA[ update this text for clarity.
EVPN network
Original:
The Designated Forwarder Preference field is specific
to DF Algorithms Highest-Preference and Lowest-Preference,
and this document does not define any meaning for other
algorithms.
Perhaps A:
The Designated Forwarder Preference field is specific
to a DF Algorithm's Highest-Preference and Lowest-Preference,
and this document does not define any meaning for other
algorithms.
Perhaps B:
The Designated Forwarder Preference field is specific
to Highest-Preference and Lowest-Preference DF Algorithms,
and this document does not define any meaning for other
algorithms.
-->
The
Designated Forwarder Preference field is specific to DF Algorithms
Highest-Preference and Lowest-Preference, and this document does not
define any meaning for other algorithms. If the DF Algorithm is
different from Highest-Preference or Lowest-Preference, these 2
octets can be encoded differently.</li>
<li>RSV and Reserved fields (from bit 16 to bit 18, and from bit 40 to
47): When the DF Algorithm is set to Highest-Preference or
Lowest-Preference, the values are set to zero when
advertising the Ethernet Segment route, and they are ignored when
receiving the Ethernet Segment route.</li>
</ul>
</section>
<section anchor="sect-4" numbered="true" toc="default">
<name>Solution Description</name>
<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>
<figure anchor="es-and-deterministic-df-election">
<name>Preference-Based DF Election</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
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 DF Algorithm, the PEs may become t
Highest-Preference or Lowest-Preference, the PEs may become Designated he 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"><li>
<!--[rfced] Section 4.1: For readability, may spaces be added after
commas in the parameter lists (as shown in Option A)? If so, other
instances will be updated accordingly; one sample is below.
<t><list style="letters"> In addition, would you like to format the examples as lists (Option B)?
Original:
a. vES1 and vES2 are now configurable with three optional parameters
that are signaled in the Designated Forwarder Election extended
community. These parameters are the Preference, Preemption
option (or "Don't Preempt" option) and DF Algorithm. We will
represent these parameters as (Pref,DP,Alg). For instance, vES1
(Pref,DP,Alg) is configured as (500,0,Highest-Preference) in PE1,
and (255,0,Highest-Preference) in PE2. vES2 is configured as
(100,0,Highest-Preference), (200,0,Highest-Preference) and
(300,0,Highest-Preference) in PE1, PE2 and PE3 respectively.
Option A:
a. vES1 and vES2 are now configurable with three optional parameters
that are signaled in the DF Election Extended Community. These
parameters are the Preference, Preemption (or "Don't Preempt")
option, and DF Algorithm. We will represent these parameters as
(Pref, DP, Alg). For instance, vES1 (Pref, DP, Alg) is
configured as (500, 0, Highest-Preference) in PE1, and (255, 0,
Highest-Preference) in PE2. vES2 is configured as (100, 0,
Highest-Preference), (200, 0, Highest-Preference) and (300, 0,
Highest-Preference) in PE1, PE2, and PE3, respectively.
Option B:
a. vES1 and vES2 are now configurable with three optional parameters
that are signaled in the DF Election Extended Community. These
parameters are the Preference, Preemption (or "Don't Preempt")
option, and DF Algorithm. We will represent these parameters as
(Pref, DP, Alg). For instance, vES1 (Pref, DP, Alg) is
configured as:
(500, 0, Highest-Preference) in PE1,
(255, 0, Highest-Preference) in PE2.
vES2 is configured as
(100, 0, Highest-Preference) in PE1,
(200, 0, Highest-Preference) in PE2, and
(300, 0, Highest-Preference) in PE3.
Sample from Section 4.3 if the space is added:
PE3 will select PE2 as the
Highest-PE over PE1, because when comparing (Pref, DP,
PE-IP), (200, 1, PE2-IP) wins over (100, 1, PE1-IP). PE3 will
select PE1 as the Lowest-PE over PE2, because
(100, 1, PE1-IP) wins over (200, 1, PE2-IP).
-->
<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 Designated Forwarder Election parameters that are signaled in the DF Election
extended community. These parameters are the Preference, Extended Community. These parameters are the Preference,
Preemption option (or "Don't Preempt" option) and DF Algorithm. We Preemption (or "Don't Preempt") option, and DF Algorithm. We
will represent these parameters as (Pref,DP,Alg). For instance, will represent these parameters as (Pref,DP,Alg). For instance,
vES1 (Pref,DP,Alg) is configured as (500,0,Highest-Preference) in vES1 (Pref,DP,Alg) is configured as (500,0,Highest-Preference) in
PE1, and (255,0,Highest-Preference) in PE2. vES2 is configured as PE1 and as (255,0,Highest-Preference) in PE2. vES2 is configured as
(100,0,Highest-Preference), (200,0,Highest-Preference) and (100,0,Highest-Preference), (200,0,Highest-Preference), and
(300,0,Highest-Preference) in PE1, PE2 and PE3 respectively.</t> (300,0,Highest-Preference) in PE1, PE2, and PE3, respectively.</t>
</li>
<!-- If Option B is selected, here's the XML.
<li><t>vES1 and vES2 are now configurable with three optional
parameters that are signaled in the DF Election
Extended Community. These parameters are the Preference,
Preemption (or "Don't Preempt") option, and DF Algorithm. We will
represent these parameters as (Pref, DP, Alg). For instance, vES1
(Pref, DP, Alg) is configured as:</t>
<ul empty="true" spacing="compact">
<li>(500, 0, Highest-Preference) in PE1,</li>
<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>
<li>
<t>According to <xref target="RFC8584" format="default"/>, each PE w
ill run the
Designated Forwarder election algorithm upon expiration of the DF Designated Forwarder 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 DF Algorithm for each Ethernet Segment as
follows: <list style="symbols"> follows: </t>
<ul spacing="normal">
<li>
<t>The PE will check the DF Algorithm value in each Ethernet <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 Algorithm <xref target="RFC7432" format="default"
Highest-Preference and Lowest-Preference Algorithms are />.
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 Designated Forwarder Election Algorithm will fall back to the
Default Algorithm.</t> Default 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 d the
DF Algorithm is Highest-Preference, the operator could change DF Algorithm is Highest-Preference, the operator could change
vES2's Preference on PE3 from 300 to e.g., 50 (hence, the Ethernet 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) 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 DP capability). Once the maintenance
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 DF Algorithm too. For example, suppose the algorit
hm 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 DP bit and the numerically lowest IP 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 DP bit are specified in <xref target="sect-4.3" format="d efault"/>. 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 advertising
the DP bit set, and then select the PE with the lowest IP address the DP bit set, and then select the PE with the lowest IP address
(if the DP bit selection does not yield a unique candidate). The (if the DP bit selection does not yield a unique candidate). The
PE's IP address is the address used in the candidate list and it 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 DP bit and IP address tiebreakers follow: </t>
style="symbols"> <ul spacing="normal">
<li>
<t>If vES1 parameters were (500,0,Highest-Preference) in PE1 <t>If vES1 parameters were (500,0,Highest-Preference) in PE1
and (500,1,Highest-Preference) in PE2, PE2 would be elected and (500,1,Highest-Preference) in PE2, PE2 would be elected
due to the DP bit. The same example applies if PE1 and PE2 due to the DP bit. The same example applies if PE1 and PE2
advertise Lowest-Preference DF Algorithm instead.</t> advertise the Lowest-Preference DF Algorithm instead.</t>
</li>
<li>
<t>If vES1 parameters were (500,0,Highest-Preference) in PE1 <t>If vES1 parameters were (500,0,Highest-Preference) in PE1
and (500,0,Highest-Preference) in PE2, PE1 would be elected, 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 D F
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">
<li>
<t>On PE1, if the DF Algorithm is Highest-Preference,
ES1's Preference value can be lowered from 500 to 100 in case 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 Designated
Forwarder Election until its corresponding Ethernet A-D per ES and Forwarder Election until 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 DF 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" <!--[rfced] FYI: We removed the citation from the title of Section 4.2
title="Use of the Highest-Preference or Lowest-Preference algorit as RFC 7432 is cited within the first sentence.
hm in [RFC7432] Ethernet Segments">
Original:
4.2. Use of the Highest-Preference or Lowest-Preference algorithm
in [RFC7432] Ethernet Segments
Current:
4.2. Use of the Highest-Preference or Lowest-Preference Algorithm
in Ethernet Segments
-->
<section anchor="sect-4.2" numbered="true" toc="default">
<name>Use of the Highest-Preference or Lowest-Preference Algorithm in Et
hernet Segments</name>
<t>While the Highest-Preference or Lowest-Preference DF Algorithm <t>While the Highest-Preference or Lowest-Preference DF Algorithm
described in <xref target="sect-4.1"/> is typically used in virtual described in <xref target="sect-4.1" format="default"/> is typically use 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 t operational
DF Algorithm for a range of Ethernet Tags. With this option, the PE DF Algorithm for a range of Ethernet Tags. With this option, the PE
builds a list of candidate PEs ordered by Preference, however the 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-Preference)
(100,0,Highest-Preference). Both PEs will advertise the Ethernet 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>
<li>
<t>In addition, assuming VLAN-based service interfaces and that <!--[rfced] FYI, we added a space after the comma
after "Ethernet Tag-range" for consistency with the example
in this sentence. Please let us know if you prefer otherwise.
Original:
* In addition, assuming VLAN-based service interfaces and that the
PEs are attached to all Ethernet Tags in the range 1-4000, both
PE1 and PE2 may be configured with (Ethernet Tag-range,Lowest-
Preference), e.g., (2001-4000, Lowest-Preference).
Current:
* In addition, assuming VLAN-based service interfaces and that the
PEs are attached to all Ethernet Tags in the range 1-4000, both
PE1 and PE2 may be configured with (Ethernet Tag-range, Lowest-
Preference), e.g., (2001-4000, Lowest-Preference).
-->
<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 Designated Forwarder 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 DP bit 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 per-PE / per-Ethernet-Segment basis, as described in <xref target="s
target="sect-3"/>. If "Don't Preempt" is disabled (default ect-3" format="default"/>. 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 DP
capability, however, this document does not enforce the 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 DP capability in the PEs of the same Ethernet
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 Designated Forwarder 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>
<!--[rfced] In Section 4.3, item (5) lists the steps PE3 will
take. The first two bullet points work off of the introductory
sentence; however, the 3rd and 4th bullet points do not. To
make the list parallel, may we rephrase the 3rd and 4th
bullet points as shown below?
Original:
PE3 will then:
[...]
* Note that, a PE will always send its DP capability set to zero
as long as the advertised Pref is the 'in-use' operational
Pref (as opposed to the 'administrative' Pref).
* This Ethernet Segment route update sent by PE3, with
(200,0,PE3-IP), will not cause any Designated Forwarder
switchover for any Ethernet Tag. PE2 will continue being
Designated Forwarder for Ethernet Tag-1. This is because
the DP bit will be used as a tiebreaker in the Designated
Forwarder election. That is, if a PE has two candidate PEs
with the same Pref, it will pick the one with DP=1. There are
no Designated Forwarder changes for Ethernet Tag-2 either.
Perhaps:
PE3 will then:
[...]
* Send its DP capability set to zero, as long as the advertised
Pref is the 'in-use' operational Pref (as opposed to the
'administrative' Pref).
* Continue to be the Designated Forwarder for Ethernet Tag-1.
The Ethernet Segment route update sent by PE3, with
(200,0,PE3-IP), will not cause any Designated Forwarder
switchover for any Ethernet Tag. This is because the
DP bit will be used as a tiebreaker in the Designated
Forwarder election. That is, if a PE has two candidate PEs
with the same Pref, it will pick the one with DP=1. There
are no Designated Forwarder changes for Ethernet Tag-2 either.
-->
<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 DP bit 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 DP bit 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-IP).
PE3 will select PE1 as Lowest-PE over PE2, since PE3 will select PE1 as the Lowest-PE over PE2, because
(100,1,PE1-IP) wins over (200,1,PE2-IP). Note that if (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 DP
capability set in their Ethernet Segment routes. Depending on capability set in their Ethernet Segment routes. Depending on
this comparison PE3 sends the Ethernet Segment route with a this comparison, PE3 sends the Ethernet Segment route with a
(Pref,DP) that may be different from its administrative (Pref,DP) that may be different from its administrative
(Pref,DP):<list style="symbols"> (Pref,DP):</t>
<t>If PE3's Pref value is higher or equal than the <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>
<li>
<t>Note that a PE will always send its DP capability set to
zero as long as the advertised Pref is the 'in-use' 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>
<li>
<t>This Ethernet Segment route update sent by PE3, with <t>This Ethernet Segment route update sent by PE3, with
(200,0,PE3-IP), will not cause any Designated Forwarder (200,0,PE3-IP), will not cause any Designated Forwarder
switchover for any Ethernet Tag. PE2 will continue being switchover for any Ethernet Tag. PE2 will continue being the
Designated Forwarder for Ethernet Tag-1. This is because the Designated Forwarder for Ethernet Tag-1. This is because the
DP bit will be used as a tiebreaker in the Designated DP bit will be used as a tiebreaker in the Designated
Forwarder election. That is, if a PE has two candidate PEs Forwarder 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 Designated Forwarder 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>
<li>
<t>After running the Designated Forwarder Election, PE3 will <t>After running the Designated Forwarder 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>
</ol>
<t>Note that, irrespective of the DP bit, when a PE or Ethernet <t>Note that, irrespective of the DP bit, when a PE or Ethernet
Segment comes back and the PE advertises a Designated Forwarder Segment comes back and the PE advertises a Designated Forwarder
Election Algorithm different from the one configured in the rest of 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 <xref target="RFC7432" form at="default"/> Algorithm.</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 vertised by the
PEs in the Ethernet Segment after running the Designated Forwarder PEs in the Ethernet Segment after running the Designated Forwarder
Election, irrespective of the revertive or non-revertive behavior in 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 Designated Forwarder 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 Designated
Forwarder Election is more automated and cannot be determined by Forwarder Election is more automated 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
value on a PE and Ethernet Segment, and impact the traffic going through
that PE and Ethernet Segment.</t>
<!--[rfced] FYI, this sentence was updated for readability (rephrased
the opening clause; changed "and impact" to "to impact"). Please
review whether it conveys the intended meaning.
Original:
With Highest-Preference or Lowest-Preference as DF Algorithm,
an attacker may change the configuration of the Preference
value on a PE and Ethernet Segment, and impact the traffic
going through that PE and Ethernet Segment.
Current:
When the DF Algorithm is Highest-Preference or Lowest-Preference,
an attacker 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.
-->
If the DF Algorithm is Highest-Preference or Lowest-Preference, an attacke
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>
<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 Designated
Forwarder Election: an intentional link (or node) "flapping" on a PE Forwarder Election: an 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
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 Designated Forwarder 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
as well.</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-6" title="IANA Considerations"> <ul spacing="normal">
<t>This document solicits:</t> <li>
<t>Allocated two new values in the "DF Alg" registry created
by <xref target="RFC8584" format="default"/>, as follows:</t>
<t><list style="symbols"> <table align="left">
<t>The allocation of two new values in the "DF Alg" registry created <thead>
by <xref target="RFC8584"/> as follows:<figure> <tr>
<artwork><![CDATA[Alg Name R <th>Alg</th>
eference <th>Name</th>
2 Highest-Preference Algorithm This document <th>Reference</th>
TBD Lowest-Preference Algorithm This document]]></artwork> </tr>
</figure></t> </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>The allocation of a new value in the "DF Election Capabilities" <table align="left">
registry created by <xref target="RFC8584"/> for the 2-octet Bitmap <thead>
field in the DF Election Extended Community (Border gateway Protocol <tr>
(BGP) Extended Communities registry), as follows:<figure> <th>Bit</th>
<artwork><![CDATA[Bit Name Ref <th>Name</th>
erence <th>Reference</th>
0 D (Don't Preempt) Capability This document]]></artwork> </tr>
</figure></t> </thead>
</list><list style="symbols"> <tbody>
<t>To update the reference of the "DF Election Extended Community" <tr>
field, in the EVPN Extended Community Sub-Types registry, as <td>0</td>
follows:<figure> <td>D (Don't Preempt) Capability</td>
<artwork><![CDATA[Sub-Type Value Name <td>RFC 9785</td>
Reference </tr>
0x06 DF Election Extended Community [RFC8584] and This Document </tbody>
]]></artwork> </table>
</figure> </t> </li>
</list></t>
</section> <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>
<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>
<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>
</middle>
<back>
<references>
<section anchor="sect-8" title="Contributors "> <!-- [rfced] Would you like the references to be alphabetized
or left in their current order?
-->
<name>References</name>
<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"/>
<!-- draft-ietf-bess-evpn-virtual-eth-segment-19 companion doc RFC 9784. -->
<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>
</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>
<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 DF 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 <t>In addition to the authors listed, the following individuals also
contributed to this document:</t> 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>
<t>Tony Przygienda, Juniper</t> <!-- [rfced] Terminology
<t>Satya Mohanty, Cisco</t> a) May we update the following terms to the form on the right for
consistency within the document and Cluster 492 (C492)?
<t>Kiran Nagaraj, Nokia</t> Designated Forwarder Election vs.
Designated Forwarder election -> DF election
<t>Vinod Prabhu, Nokia</t> Designated Forwarder Election Algorithm vs.
Designated Forwarder Election algorithm vs.
Designated Forwarder election algorithm -> DF election algorithm
<t>Selvakumar Sivaraj, Juniper</t> Default Designated Forwarder Election Algorithm vs.
Default Designated Forwarder Election algorithm vs.
default Designated Forwarder election algorithm
-> default DF election algorithm (per RFC 8584)
<t>Sami Boutros, VMWare</t> b) Throughout the text, the following terminology appears to be used
</section> inconsistently. Please review these occurrences and let us know if/how they
</middle> may be made consistent.
<back> Default DF Algorithm vs. Default Algorithm vs. Default algorithm
<references title="Normative References"> [Note: Should "Default" perhaps be lowercase? Should "DF" be
&RFC7432; removed or added for consistency (also see (c) below)?
Perhaps: "default DF algorithm" (per RFC 8584)
&RFC8584; Preference value vs. preference value
&RFC2119; c) We note "Highest-Preference and/or Lowest-Preference DF Algorithm(s)" (with "
DF")
vs. "Highest-Preference and/or Lowest-Preference Algorithm(s)" (without "DF").
&RFC8174; Per the "DF Alg" registry <https://www.iana.org/assignments/bgp-extended-communi
ties>,
these terms appear without "DF". Should "DF" be removed from these
terms in the document or should "DF" be added to the terms in this
document and in the registry for consistency?
&I-D.ietf-bess-evpn-virtual-eth-segment; Per the "DF Alg" registry:
</references> 2 Highest-Preference Algorithm
3 Lowest-Preference Algorithm
<references title="Informative References"> A few examples that vary in the text (see the document for more examples):
&RFC8214;
&RFC8365; The DP capability is supported by the Highest-Preference or
Lowest-Preference DF Algorithms.
The procedures of the "Don't Preempt" capability for the
Highest-Preference and Lowest-Preference DF Algorithms are
described in Section 4.1.
The Highest-Preference and Lowest-Preference Algorithms MAY be used
along with the AC-DF capability.
The document also describes how a local policy can override the
Highest-Preference or Lowest-Preference Algorithms for a range of
Ethernet Tags in the Ethernet Segment.
d) We made the following changes for consistency (the document now uses the
form on the right). Please let us know if any further changes are needed.
Acknowledgments -> Acknowledgements (for consistency with C492)
all-active -> All-Active (for consistency with C492)
Broadcast Domain -> broadcast domain (for consistency with C492)
Designated Forwarder Election Extended Community and
Designated Forwarder Election extended community ->
DF Election Extended Community (per IANA, RFC 8584, and C492)
Ethernet segment -> Ethernet Segment
Highest-Preference algorithm -> Highest-Preference Algorithm (per IANA)
Lowest-Preference algorithm -> Lowest-Preference Algorithm (per IANA)
single-active -> Single-Active (for consistency with C492)
-->
<!-- [rfced] Abbreviations
a) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
- Operations, Administration, and Maintenance (OAM)
- VLAN ID (VID)
b) For consistency (within the RFC series and C492), we
updated the document to use the forms on the right.
Please let us know if you prefer otherwise.
AC-Influenced Designated Forwarder Election (AC-DF) ->
AC-Influenced DF (AC-DF) election (per RFC 8584)
ENNI: Ethernet Network to Network Interface ->
ENNI: External Network-Network Interface
(to match usage in RFC-to-be 9784)
-->
<!--[rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
&RFC7623;
</references>
</back>
</rfc> </rfc>
 End of changes. 217 change blocks. 
495 lines changed or deleted 1043 lines changed or added

This html diff was produced by rfcdiff 1.48.