<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"> nbsp    "&#160;">
  <!ENTITY RFC8214 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8214.xml"> zwsp   "&#8203;">
  <!ENTITY RFC7623 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7623.xml"> nbhy   "&#8209;">
  <!ENTITY RFC8365 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8365.xml">
<!ENTITY RFC8584 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8584.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.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"> wj     "&#8288;">
]>
<?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 xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-bess-evpn-pref-df-13" number="9785" ipr="trust200902" submissionType="IETF" updates="8584">
  <!--Generated by id2xml 1.5.0 on 2019-12-17T09:50:28Z updates="8584" obsoletes="" xml:lang="en" consensus="true"  tocInclude="true" tocDepth="3" symRefs="true" sortRefs="false" version="3">

<!--[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.

Original:
   Preference-based EVPN DF Election

Current:
   Preference-Based EVPN Designated Forwarder (DF) Election
-->

  <?rfc strict="yes"?>

  <?rfc compact="yes"?>

  <?rfc subcompact="no"?>

  <?rfc symrefs="yes"?>

  <?rfc sortrefs="no"?>

  <?rfc text-list-symbols="o-*+"?>

  <?rfc toc="yes"?>

  <front>
    <title>Preference-based
    <title abbrev="Preference-Based EVPN DF Election">Preference-Based EVPN Designated Forwarder (DF) Election</title>
    <seriesInfo name="RFC" value="9785"/>
    <author fullname="J. fullname="Jorge Rabadan" initials="J." role="editor" surname="Rabadan">
      <organization>Nokia</organization>
      <address>
        <postal>
          <street>520 Almanor Avenue</street>
          <city>Sunnyvale</city>
          <region>CA</region>
          <code>94085</code>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>jorge.rabadan@nokia.com</email>
      </address>
    </author>
    <author fullname="S. fullname="Senthil Sathappan" initials="S." surname="Sathappan">
      <organization>Nokia</organization>
      <address>
        <email>senthil.sathappan@nokia.com</email>
      </address>
    </author>
    <author fullname="W. fullname="Wen Lin" initials="W." surname="Lin">
      <organization>Juniper Networks</organization>
      <address>
        <email>wlin@juniper.net</email>
      </address>
    </author>
    <author fullname="J. fullname="John Drake" initials="J." surname="Drake">
      <organization>Independent</organization>
      <address>
        <email>je_drake@yahoo.com</email>
      </address>
    </author>
    <author fullname="A. fullname="Ali Sajassi" initials="A." surname="Sajassi">
      <organization>Cisco Systems</organization>
      <address>
        <email>sajassi@cisco.com</email>
      </address>
    </author>
    <date day="9" month="October" year="2023"/>

    <workgroup>BESS Workgroup</workgroup> month="May" year="2025"/>
    <area>RTG</area>
    <workgroup>bess</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

    <abstract>
      <t>The Designated Forwarder (DF) in Ethernet Virtual Private Networks
      (EVPN)
      (EVPNs) is defined as the Provider Edge (PE) router responsible for
      sending Broadcast, Unknown unicast Unicast, and Multicast traffic (BUM) traffic to a
      multi-homed device/network in the case of an all-active All-Active multi-homing
      Ethernet Segment (ES), (ES) or BUM and unicast in the case of single-active Single-Active
      multi-homing. The Designated Forwarder is selected out of a candidate
      list of PEs that advertise the same Ethernet Segment Identifier (ESI) to
      the EVPN network, according to the Default Designated Forwarder Election
      algorithm. While the Default Algorithm provides 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 'deterministic' "deterministic" and user-controlled method is required. At the same
      time, Network Operators require an easy way to force an on-demand
      Designated Forwarder switchover in order to carry out some maintenance
      tasks on the existing Designated Forwarder or control whether a new
      active PE can preempt the existing Designated Forwarder PE.</t>
      <t>This document proposes use of a Designated Forwarder Election algorithm that
      meets the requirements of determinism and operation control. This
      document updates RFC8584 RFC 8584 by modifying the definition of the DF Election
      Extended Community. </t>
    </abstract>
  </front>
  <middle>
    <section anchor="sect-1" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <section anchor="sect-1.1" title="Problem Statement"> numbered="true" toc="default">
        <name>Problem Statement</name>
        <t><xref target="RFC7432"/> target="RFC7432" format="default"/> defines the Designated Forwarder (DF) in
        EVPN networks as the PE responsible for sending Broadcast, Unknown
        unicast
        Unicast, and Multicast traffic (BUM) traffic to a multi-homed device/network in
        the case of an all-active All-Active multi-homing Ethernet Segment or BUM and
        unicast traffic to a multi-homed device or network in the case of
        single-active
        Single-Active multi-homing. The Designated Forwarder is selected out
        of a candidate list of PEs that advertise the Ethernet Segment
        Identifier (ESI) to the EVPN network and according to the Designated
        Forwarder Election Algorithm, Algorithm or to DF Alg as per <xref
        target="RFC8584"/>.</t> target="RFC8584" 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?

Original:
   While the Default Designated Forwarder Algorithm [RFC7432] or the
   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="RFC7432"/> target="RFC7432" format="default"/> or the Highest Random Weight algorithm (HRW) algorithm <xref
        target="RFC8584"/> target="RFC8584" format="default"/> provide an efficient and automated way of selecting
        the Designated Forwarder across different Ethernet Tags in the
        Ethernet Segment, there are some use-cases use cases where a more
        user-controlled method is required. At the same time, Network
        Operators require an easy way to force an on-demand Designated
        Forwarder switchover in order to carry out some maintenance tasks on
        the existing Designated Forwarder or control whether a new active PE
        can preempt the existing Designated Forwarder PE.</t>
      </section>
      <section anchor="sect-1.2" title="Solution Requirements"> numbered="true" toc="default">

        <name>Solution Requirements</name>
        <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
            that the user can control in what order the candidate PEs may
            become the Designated Forwarder, assuming they are all operationally
            ready to take over as the Designated Forwarder. The operator can
            determine whether the Highest-Preference or Lowest-Preference PE
            among the PEs in the Ethernet Segment will be elected as
            the Designated Forwarder, based on the DF Algorithms described in this
            document.</t>
          </li>
          <li>
            <t>The extensions described in this document work for <xref
            target="RFC7432"/> Ethernet Segments <xref target="RFC7432" format="default"/> and virtual Ethernet
            Segments,
            Segments as defined in <xref
            target="I-D.ietf-bess-evpn-virtual-eth-segment"/>.</t> target="RFC9784" format="default"/>.</t>
          </li>
          <li>
            <t>The user may force a PE to preempt the existing Designated
            Forwarder for a given Ethernet Tag without re-configuring reconfiguring all the
            PEs in the Ethernet Segment, by simply modifying the existing
            administrative preference in that PE.</t>
          </li>
          <li anchor="DP-capability">
            <t>The solution allows an option to NOT preempt the current
            Designated Forwarder ("Don't (the "Don't Preempt" capability), even if the
            former Designated Forwarder PE comes back up after a failure. This
            is also known as "non-revertive" behavior, as opposed to the <xref
            target="RFC7432"/> Designated Forwarder election procedures <xref target="RFC7432" format="default"/> that
            are always revertive (because the winner PE of the default
            Designated Forwarder election algorithm always takes over as the
            operational Designated Forwarder).</t>
          </li>
          <li>
            <t>The procedures described in this document support single-active Single-Active
            and all-active All-Active multi-homing Ethernet Segments.</t>
          </list></t>
          </li>
        </ol>
      </section>
      <section anchor="sect-1.3" title="Solution Overview"> numbered="true" toc="default">
        <name>Solution Overview</name>
        <t>To provide a solution that satisfies the above requirements, we
        introduce two new DF Algorithms that can be advertised in the DF
        Election Extended Community <xref target="sect-3"/>. (<xref target="sect-3" format="default"/>). Carried with the
        new DF Election Extended Community variants are is a DF election
        preference advertised for each PE, PE that influences which PE will
        become the DF <xref target="sect-4.1"/>. (<xref target="sect-4.1" format="default"/>). The advertised DF election
        preference can dynamically vary from the administratively configured
        preference to provide non-revertive behavior (<xref target="sect-4.3" format="default"/>). In <xref
        target="sect-4.3"/>. An target="sect-4.2" format="default"/>, an optional solution is discussed in <xref
        target="sect-4.2"/>, for use in Ethernet segments Segments that support supports large numbers of Ethernet Tags and therefore need needs to balance load among
        multiple DFs. </t>
      </section>
    </section>
    <section anchor="sect-2" title="Requirements numbered="true" toc="default">
      <name>Requirements Language and Terminology">
      <t>The Terminology</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</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
      "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t>

      <t><list style="symbols">
          <t>AC - Attachment here.
        </t>

      <dl spacing="normal" newline="false">
        <dt>AC:</dt><dd>Attachment Circuit. An AC has an Ethernet Tag
        associated to
          it.</t>

          <t>CE - Customer it.</dd>
        <dt>CE:</dt><dd>Customer Equipment router.</t>

          <t>DF - Designated Forwarder.</t>

          <t>DF Alg - refers router</dd>
        <dt>DF:</dt><dd>Designated Forwarder</dd>
        <dt>DF Alg:</dt><dd>Refers to the Designated Forwarder Election Algorithm. This
        Algorithm, which is sometimes shortened to &ldquo;Alg&rdquo; "Alg" in this document.</t>

          <t>DP - refers document.</dd>

<!--[rfced] DP vs. D

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?

Current:
   DP: Refers to the "Don't Preempt" (me) capability in the
   Designated Forwarder Election extended community.</t>

          <t>ENNI - Ethernet Network community.

Perhaps:
   DP: Refers to Network Interface.</t>

          <t>ES the "Don't Preempt" capability in the
   DF Election Extended Community.

b) Section 2 says "DP" refers to the "Don't Preempt" capability, but
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 vES "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.

Current (in the running text):

  "Don't Preempt" capability vs.
  'Don't Preempt' bit vs.
  DP capability vs.
  DP bit vs.
  D bit

In the DF Election Capabilities Registry:

   Bit   Name                             Reference
   - Ethernet -   - - - - - - - - - - - - - - -    - - - - - -
   0     D (Don't Preempt) Capability     RFC XXXX
-->

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

          <t>Ethernet Segment.</dd>

<!--[rfced] Should "route type 1" be "Route Type (1 octet)"
per RFC 7432 or as "Route Type 1" per the description of
"Ethernet A-D per EVI route" in RFC 8584 (which updates RFC 7432)?

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 <xref target="RFC7432"/> [RFC7432] route type 1 or
   Auto-Discovery per EVPN Instance route.</t>

          <t>EVC - route.

Perhaps:
   Ethernet Virtual Circuit.</t>

          <t>EVI - A-D per EVI route: Refers to Route Type 1 or
      Auto-Discovery per the EVPN Instance.</t>

          <t>Ethernet Tag - used 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 broadcast domain that is
        configured on a given Ethernet Segment for the purpose of Designated
        Forwarder election. Note that any of the following may be used to
        represent a Broadcast Domain: VIDs broadcast domain: VLAN IDs (VIDs) (including Q-in-Q tags), configured
        IDs, VNI (VXLAN VXLAN Network Identifiers), Identifiers (VNIs), normalized VID,
          I-SIDs (Service VIDs, Service
        Instance Identifiers), Identifiers (I-SIDs), 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
        <bcp14>MUST NOT</bcp14> be zero.</t>

          <t>HRW - Highest zero.</dd>
        <dt>HRW:</dt><dd>Highest Random Weight, as per <xref target="RFC8584"/>.</t>

          <t>OAM - refers to Operations And Maintenance protocols.</t>
        </list></t> target="RFC8584"
        format="default"/>.</dd>
        <dt>OAM:</dt><dd>Operations, Administration, and Maintenance.</dd>
      </dl>

    </section>
    <section anchor="sect-3" title="EVPN numbered="true" toc="default">
      <name>EVPN BGP Attributes Extensions"> Attribute Extensions</name>

      <t>This solution reuses and extends the Designated Forwarder DF Election
      Extended Community defined in <xref target="RFC8584"/> target="RFC8584" format="default"/> that is
      advertised along with the Ethernet Segment route. It does so by
      replacing the last two reserved octets of the DF Election Extended
      Community when the DF Algorithm is set to Highest-Preference or
      Lowest-Preference. This document also defines a new capability referred
      to as the "Don't Preempt" capability, that MAY which <bcp14>MAY</bcp14> be used with
      Highest-Preference or Lowest-Preference DF Algorithms. The format of the
      DF Election Extended Community that is used in this document is as
      follows:</t>
      <figure anchor="df-election-extended-community"
              title="DF anchor="df-election-extended-community">
        <name>DF Election Extended Community">
        <artwork><![CDATA[ Community</name>
        <artwork name="" type="" align="left" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06     | Sub-Type(0x06)| RSV |  DF Alg |    Bitmap     ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~     Bitmap    |   Reserved    |   DF Preference (2 octets)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
      <t>Where the above fields are defined as follows:</t>

      <t><list style="symbols">
          <t>DF
      <ul spacing="normal">
        <li><t>The DF Algorithm can have the following values:<list style="symbols">
              <t>Alg values:</t>
        <ul spacing="normal">

<!--[rfced] Is it correct that the default DF algorithm is the same
as the "modulus-based algorithm as per [RFC7432]"? If so,
even though this text currently matches RFC 8584, would it be
more clear to use  "i.e.," or another phrase to indicate that
these are equivalent (rather than alternatives)?

Original:
   Alg 0 - Default Designated Forwarder Election algorithm, or
            modulus-based algorithm as per [RFC7432].

Perhaps:
   Alg 0 - Default Designated Forwarder Election algorithm, i.e.,
           the modulus-based algorithm as per [RFC7432].

For comparison, from RFC 8584:
      -  Type 0: Default DF election algorithm, or modulus-based
         algorithm as defined in [RFC7432].
-->

            <li>Alg 0 - Default Designated Forwarder Election algorithm, or
            modulus-based algorithm as per <xref target="RFC7432"/>.</t>

              <t>Alg target="RFC7432"
            format="default"/>.</li>
            <li>Alg 1 - HRW algorithm as per <xref target="RFC8584"/>.</t>

              <t>Alg target="RFC8584" format="default"/>.</li>
            <li>Alg 2 - Highest-Preference algorithm (this document <xref
              target="sect-4.1"/>).</t>

              <t>Alg TBD Algorithm (<xref target="sect-4.1" format="default"/>).</li>
            <li>Alg 3 - Lowest-Preference algorithm (this document <xref
              target="sect-4.1"/>). TBD will be replaced by the allocated
              value at the time of publication.</t>
            </list></t>
        </list><list style="symbols">
          <t>Bitmap Algorithm (<xref
            target="sect-4.1" format="default"/>).</li>
          </ul>
        </li>
        <li><t>Bitmap (2 octets) encodes "capabilities" <xref
          target="RFC8584"/>, where 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>
        </list></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"
              title="Bitmap field anchor="bitmap-field-in-the-df-election-extended-community">
        <name>Bitmap Field in the DF Election Extended Community">
        <artwork><![CDATA[ Community</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                       1 1 1 1 1 1
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |D|A|                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>

      <t><list style="empty">
          <t><list style="symbols">
              <t>Bit
          <ul spacing="normal">
            <li>Bit 0 (corresponds to Bit 24 of the Designated Forwarder DF
            Election Extended Community Community, and it is defined by this document):
              the
            The D bit bit, or 'Don't Preempt' bit (DP ("DP" hereafter), determines if the
            PE advertising the Ethernet Segment route requests the remote PEs
            in the Ethernet Segment not 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"/>. 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"/>.</t>

              <t>Bit 1: AC-DF or AC-Influenced target="sect-4.1" format="default"/>.</li>

<!--[rfced] FYI: We removed "described by this document" in the
following entry (in Section 3) to avoid redundancy as the
description points to Section 4.1 of this document. Please
let us know of any objections.

Original:
   *  Designated Forwarder Election (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
      Section 4.1.

Current:
   *  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 Section 4.1.
-->

            <li>Bit 1: AC-Influenced DF (AC-DF) election is
            described in <xref target="RFC8584"/>. target="RFC8584" format="default"/>. When set
            to 1, it indicates the desire to use AC-Influenced Designated Forwarder
              Election AC-DF with the rest of the PEs
	    in the Ethernet
            Segment. The AC-DF capability bit MAY <bcp14>MAY</bcp14> be set along
            with the DP capability and
              the Highest-Preference or
            Lowest-Preference DF Algorithms.</t>
            </list></t>
        </list><list style="symbols">
          <t>Designated Algorithms.</li>
          </ul>
        </li>
        <li>Designated Forwarder (DF) Preference (described in this
          document): defines 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"/>.
        target="sect-4.1" format="default"/>. The allowed values are within
        the range 0-65535, and the default value MUST <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"/>. target="sect-4.1" format="default"/>.

<!--[rfced] Is "DF Algorithms" intended to be singular possessive
(option A) or plural (option B)? Please let us know how we may
update this text for clarity.

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 two 2
        octets can be encoded differently.</t>

          <t>RSV differently.</li>
        <li>RSV and Reserved fields (from bit 16 to bit 18, and from bit 40 to
        47): when When the DF Algorithm is set to Highest-Preference or
          Lowest-Preference algorithm,
        Lowest-Preference, the values are set to zero when
        advertising the Ethernet Segment route, and they are ignored when
        receiving the Ethernet Segment route.</t>
        </list></t> route.</li>
      </ul>
    </section>
    <section anchor="sect-4" title="Solution description"> numbered="true" toc="default">
      <name>Solution Description</name>
      <t><xref target="es-and-deterministic-df-election"/> target="es-and-deterministic-df-election" format="default"/> illustrates an
      example that will be used in the description of the solution.</t>
      <figure anchor="es-and-deterministic-df-election"
              title="Preference-based anchor="es-and-deterministic-df-election">
        <name>Preference-Based DF Election">
        <artwork><![CDATA[ Election</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
              EVPN network Network
         +-------------------+
         |                +-------+  ENNI    Aggregation
         |   <---ESI1,500 |  PE1  |   /\  +----Network---+
         | <-----ESI2,100 |       |===||===              |
         |                |       |===||== \      vES1   |  +----+
     +-----+              |       |   \/  |\----------------+CE1 |
CE3--+ PE4 |              +-------+       | \   ------------+    |
     +-----+                 |            |  \ /         |  +----+
         |                   |            |   X          |
         |   <---ESI1,255  +-----+============ \         |
         | <-----ESI2,200  | PE2 |==========    \ vES2   | +----+
         |                 +-----+        | \    ----------+CE2 |
         |                   |            |  --------------+    |
         |                 +-----+   ----------------------+    |
         | <-----ESI2,300  | PE3 +--/     |              | +----+
         |                 +-----+        +--------------+
         --------------------+]]></artwork>
      </figure>
      <t><xref target="es-and-deterministic-df-election"/> target="es-and-deterministic-df-election" format="default"/> shows three PEs
      that are connecting EVCs coming from the Aggregation Network to their
      EVIs in the EVPN network. CE1 is connected to vES1 - that vES1, which spans PE1 and
      PE2 -
      PE2, and CE2 is connected to vES2, that which is attached to PE1, PE2 PE2, and
      PE3.</t>
      <t>If the algorithm chosen for vES1 and vES2 is DF Algorithm the
      Highest-Preference or Lowest-Preference, Lowest-Preference DF Algorithm, the PEs may become the Designated
      Forwarder irrespective of their IP address and based on the
      administrative Preference value. The following sections provide some
      examples of the procedures and how they are applied in the use-case use case of
      <xref target="es-and-deterministic-df-election"/>.</t> target="es-and-deterministic-df-election" format="default"/>.</t>
      <section anchor="sect-4.1"
               title="Use numbered="true" toc="default">
        <name>Use of the Highest-Preference and Lowest Preference Algorithm"> Lowest-Preference Algorithm</name>

        <t>Assuming the operator wants to control - -- in a flexible way - -- what
        PE becomes the Designated Forwarder for a given virtual Ethernet
        Segment and the order in which the PEs become a Designated Forwarder in
        case of multiple failures, the Highest-Preference or Lowest-Preference
        algorithms
        Algorithms can be used. Using Per the example in <xref
        target="es-and-deterministic-df-election"/>, target="es-and-deterministic-df-election" format="default"/>, these
	algorithms are used
        as follows:</t>

        <t><list style="letters">
            <t>vES1
        <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.

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
            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 as (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.</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
            Ethernet Segment, including the three parameters indicated in 'a' (a)
            above, in the Designated Forwarder DF Election Extended Community
            (encoded as described in <xref target="sect-3"/>).</t> target="sect-3" format="default"/>).</t>
          </li>
          <li>
            <t>According to <xref target="RFC8584"/>, target="RFC8584" format="default"/>, each PE will run the
            Designated Forwarder election algorithm upon expiration of the DF
            Wait timer. Each PE runs the Highest-Preference or
            Lowest-Preference DF Algorithm for each Ethernet Segment as
            follows: <list style="symbols"> </t>
            <ul spacing="normal">
              <li>
                <t>The PE will check the DF Algorithm value in each Ethernet
                Segment route, and assuming all the Ethernet Segment routes
                (including the local route) are consistent in this DF
                Algorithm (that is, all are configured for Highest-Preference
                or Lowest-Preference, but not a mix), the PE runs the
                procedure in this section. Otherwise, the procedure falls back
                to <xref target="RFC7432"/> the Default Algorithm. Algorithm <xref target="RFC7432" format="default"/>.
                The Highest-Preference and Lowest-Preference Algorithms are
                different Algorithms, therefore algorithms; therefore, if two PEs configured for
                Highest-Preference and Lowest-Preference Lowest-Preference, respectively, are
                attached to the same Ethernet Segment, the operational
                Designated Forwarder Election Algorithm will fall back to the
                Default Algorithm.</t>
              </li>
              <li>
                <t>If all the PEs attached to the Ethernet Segment advertise
                the Highest-Preference Algorithm, each PE builds a list of
                candidate PEs, ordered by Preference value from the
                numerically highest value to lowest value. E.g., For example, PE1 builds a
                list of candidate PEs for vES1 ordered by the Preference, from
                high to low: &lt;PE1, PE2&gt; (since PE1's preference is more
                preferred than PE2's). Hence, PE1 becomes the Designated
                Forwarder for vES1. In the same way, PE3 becomes the
                Designated Forwarder for vES2.</t>
              </li>
              <li>
                <t>If all the PEs attached to the Ethernet Segment advertise
                the Lowest-Preference Algorithm, then the candidate list is
                ordered from the numerically lowest Preference value to the
                highest Preference value. E.g., For example, PE1's ordered list for vES1 is
                &lt;PE2, PE1&gt;. Hence, PE2 becomes the Designated Forwarder
                for vES1. In the same way, PE1 becomes the Designated
                Forwarder for vES2.</t>
              </list></t>
              </li>
            </ul>
          </li>
          <li>
            <t>Assuming some maintenance tasks had to be executed on a PE PE, the
            operator may want to make sure the PE is not the Designated
            Forwarder for the Ethernet Segment so that the impact on the
            service is minimized. E.g., For example, if PE3 is going on maintenance and the
            DF Algorithm is Highest-Preference, the operator could change
            vES2's Preference on PE3 from 300 to to, e.g., 50 (hence, the Ethernet
            Segment route from PE3 is updated with the new preference value) value),
            so that PE2 is forced to take over as Designated Forwarder for
            vES2 (irrespective of the DP capability). Once the maintenance
            task on PE3 is over, the operator could decide to leave the latest
            configured preference value or configure the initial preference
            value back. A similar procedure can be used for the
            Lowest-Preference DF Algorithm
            Lowest-Preference too, that is, too. For example, suppose the algorithm for vES2 is
            Lowest-Preference, and PE1 (the DF) goes on maintenance mode. The
            operator could change vES2's Preference on PE1 from 100 to to, e.g.,
            250, so that PE2 is forced to take over as the Designated Forwarder
            for vES2.</t>
          </li>
          <li>
            <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
            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 target="sect-4.3" format="default"/>. If
            more than one PE is advertising itself as the preferred Designated
            Forwarder, an implementation MUST <bcp14>MUST</bcp14> first select the PE advertising
            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
            PE's IP address is the address used in the candidate list list, and it
            is derived from the Originating Router's IP address of the
            Ethernet Segment route. In case PEs use the Originating Router's
            IP address of different families, an IPv4 address is always
            considered numerically lower than an IPv6 address. Some examples
            of the use of using the DP bit and IP address tiebreakers follow: <list
                style="symbols"> </t>
            <ul spacing="normal">
              <li>
                <t>If vES1 parameters were (500,0,Highest-Preference) in PE1
                and (500,1,Highest-Preference) in PE2, PE2 would be elected
                due to the DP bit. The same example applies if PE1 and PE2
                advertise the Lowest-Preference DF Algorithm instead.</t>
              </li>
              <li>
                <t>If vES1 parameters were (500,0,Highest-Preference) in PE1
                and (500,0,Highest-Preference) in PE2, PE1 would be elected,
                if PE1's IP address is lower than PE2's. Or PE2 would be
                elected if PE2's IP address is lower than PE1's. The same
                example applies if PE1 and PE2 advertise the Lowest-Preference DF
                Algorithm instead.</t>
              </list></t>
              </li>
            </ul>
          </li>
          <li>
            <t>The Preference is an administrative option that MUST <bcp14>MUST</bcp14> be
            configured on a per-Ethernet Segment per-Ethernet-Segment basis, and it is normally
            configured from the management plane. The Preference value MAY <bcp14>MAY</bcp14>
            also be dynamically changed based on the use of local policies
            that react to events on the PE. The following examples illustrate
            the use of local policy to change the Preference value in a
            dynamic way.<list style="empty">
                <t>E.g., on way.</t>
            <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
                the bandwidth on the ENNI port is decreased by 50% (that could
                happen if if, e.g., the 2-port Link Aggregation Group between PE1
                and the Aggregation Network loses one port).</t>
              </li>
              <li>
                <t>Local policy MAY <bcp14>MAY</bcp14> also trigger dynamic Preference changes
                based on the PE's bandwidth availability in the core, specific
                ports going operationally down, etc.</t>
              </li>
              <li>
                <t>The definition of the actual local policies is out of scope
                of this document.</t>
              </list></t>
          </list></t>

        <t>The Highest-Preference
              </li>
            </ul>
          </li>
        </ol>

        <t>Highest-Preference and Lowest-Preference Algorithms MAY <bcp14>MAY</bcp14> be used
        along with the AC-DF capability. Assuming all the PEs in the Ethernet
        Segment are configured consistently with the Highest-Preference or
        Lowest-Preference Algorithm and AC-DF capability, a given PE in the
        Ethernet Segment is not considered as a candidate for Designated
        Forwarder Election until its corresponding Ethernet A-D per ES and
        Ethernet A-D per EVI routes are received, as described in <xref
        target="RFC8584"/>.</t>

        <t>The Highest-Preference target="RFC8584" format="default"/>.</t>
        <t>Highest-Preference and Lowest-Preference DF Algorithms can be
        used in different virtual Ethernet Segments on the same PE. For
        instance, PE1 and PE2 can use Highest-Preference for vES1 and PE1, and PE2
        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
        flexibility and full control to the operator.</t>

        <t>The procedures in this document can be used in <xref
        target="RFC7432"/>-based an Ethernet Segment as defined in <xref target="RFC7432" format="default"/> or a virtual Ethernet Segment
        as in per <xref target="I-D.ietf-bess-evpn-virtual-eth-segment"/>, target="RFC9784" format="default"/> and
        also in EVPN networks as described in <xref target="RFC8214"/>, target="RFC8214" format="default"/>, <xref
        target="RFC7623"/> target="RFC7623" format="default"/>, or <xref target="RFC8365"/>.</t> target="RFC8365" format="default"/>.</t>
      </section>

      <section anchor="sect-4.2"
               title="Use

<!--[rfced] FYI: We removed the citation from the title of Section 4.2
as RFC 7432 is cited within the first sentence.

Original:
   4.2.  Use of the Highest-Preference or Lowest-Preference algorithm
         in [RFC7432] Ethernet Segments"> 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 Ethernet Segments</name>
        <t>While the Highest-Preference or Lowest-Preference DF Algorithm
        described in <xref target="sect-4.1"/> target="sect-4.1" format="default"/> is typically used in virtual
        Ethernet Segment scenarios where there is normally an individual
        Ethernet Tag per virtual Ethernet Segment, the existing <xref
        target="RFC7432"/> definition of an Ethernet Segment <xref target="RFC7432" format="default"/> allows
        potentially up to thousands of Ethernet Tags on the same Ethernet
        Segment. If this is the case, and if the Highest-Preference or
        Lowest-Preference Algorithm is configured in all the PEs of the
        Ethernet Segment, the same PE will be the elected Designated Forwarder
        for all the Ethernet Tags of the Ethernet Segment. A potential way to
        achieve a more granular load balancing is described below.</t>
        <t>The Ethernet Segment is configured with an administrative
        Preference value and an administrative DF Algorithm, i.e.,
        Highest-Preference or Lowest-Preference Algorithm. However, the
        administrative DF Algorithm (which is used to signal the DF Algorithm
        for the Ethernet Segment) MAY <bcp14>MAY</bcp14> be overridden to a different operational
        DF Algorithm for a range of Ethernet Tags. With this option, the PE
        builds a list of candidate PEs ordered by Preference, however Preference; however, the
        Designated Forwarder for a given Ethernet Tag will be determined by
        the locally overridden DF Algorithm.</t>
        <t>For instance:</t>

        <t><list style="symbols">
        <ul spacing="normal">
          <li>
            <t>Assuming ES3 is defined in PE1 and PE2, PE1 may be configured
            as (500,0,Highest-Preference) for ES3 and PE2 as
            (100,0,Highest-Preference). (100,0,Highest-Preference) for ES3.
           Both PEs will advertise the Ethernet
            Segment routes for ES3 with the indicated parameters in the DF
            Election Extended Community.</t>
          </li>
          <li>

<!--[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,
            both PE1 and PE2 may be configured with (Ethernet
            Tag-range,Lowest-Preference),
            Tag-range, Lowest-Preference), e.g., (2001-4000, Lowest-Preference).</t>
          </li>
          <li>
            <t>This will result in PE1 being the Designated Forwarder for Ethernet
            Tags 1-2000 (since they use the default Highest-Preference
            Algorithm) and PE2 being the Designated Forwarder for Ethernet Tags
            2001-4000, due to the local policy overriding the
            Highest-Preference Algorithm.</t>
          </list></t>
          </li>
        </ul>
        <t>While the above logic provides a perfect load balancing load-balancing
        distribution of Ethernet Tags per Designated Forwarder when there are
        only two PEs, for Ethernet Segments attached to three or more PEs,
        there would be only two Designated Forwarder PEs for all the Ethernet
        Tags. Any other logic that provides a fair distribution of the
        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
        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 Ethernet Segment, this local policy MUST <bcp14>MUST</bcp14> be consistent in all the
        PEs of the Ethernet Segment. If the local policy is inconsistent for a
        given Ethernet Tag in the Ethernet Segment, packet drops or packet
        duplication may occur on that Ethernet Tag. For all these reasons reasons, the
        use of virtual Ethernet Segments is RECOMMENDED <bcp14>RECOMMENDED</bcp14> for cases where more
        than two PEs per Ethernet Segment exist and a good load balancing load-balancing
        distribution per Ethernet Tag of the Designated Forwarder function is
        desired. </t>
      </section>
      <section anchor="sect-4.3" title="The numbered="true" toc="default">
        <name>The Non-Revertive Capability"> Capability</name>
        <t>As discussed in <xref target="sect-1.2"/> (d), target="DP-capability" format="none">item d</xref> of <xref target="sect-1.2" format="default"/>, a capability to NOT
        preempt the existing Designated Forwarder (for all the Ethernet Tags
        in the Ethernet Segment) is required and therefore added to the
        Designated Forwarder
        DF Election extended community. Extended Community. This option allows a
        non-revertive behavior in the Designated Forwarder election.</t>
        <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
        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
        when a former Designated Forwarder comes back up without any
        controlled maintenance operation, and the non-revertive option is
        desired in order to avoid service impact.</t>
        <t>In <xref target="es-and-deterministic-df-election"/>, target="es-and-deterministic-df-election" format="default"/>, we assume
        that based on the Highest-Preference Algorithm, PE3 is the Designated
        Forwarder for ESI2.</t>
        <t>If PE3 has a link, EVC EVC, or node failure, PE2 would take over as the
        Designated Forwarder. If/when PE3 comes back up again, PE3 will take
        over, causing some unnecessary packet loss in the Ethernet
        Segment.</t>
        <t>The following procedure avoids preemption upon failure recovery
        (please refer to
        (see <xref target="es-and-deterministic-df-election"/>). target="es-and-deterministic-df-election" format="default"/>).
        The procedure supports a non-revertive mode that can be used along
        with: <list style="symbols"> </t>
        <ul spacing="normal">
          <li>
            <t>Highest-Preference Algorithm</t>
          </li>
          <li>
            <t>Lowest-Preference Algorithm</t>
          </li>
          <li>
            <t>Highest-Preference or Lowest-Preference Algorithm, where a
            local policy overrides the Highest/Lowest-Preference Highest-/Lowest-Preference tiebreaker
            for a range of Ethernet Tags <xref target="sect-4.2"/></t>
          </list>The (<xref target="sect-4.2" format="default"/>)</t>
          </li>
        </ul>
        <t>The procedure is described described, assuming the Highest-Preference
        Algorithm in the Ethernet Segment, where local policy overrides the
        tiebreaker for a given Ethernet Tag. The other cases above are a
        sub-set
        subset of this one one, and the differences are explained.</t>

        <t><list style="numbers">
        <ol spacing="normal" type="1"><li>
            <t>A "Don't Preempt" capability is defined on a
            per-PE/per-Ethernet Segment
            per-PE / per-Ethernet-Segment basis, as described in <xref
            target="sect-3"/>. target="sect-3" format="default"/>. If "Don't Preempt" is disabled (default
            behavior), the PE sets DP to zero and advertises it in an Ethernet
            Segment route. If "Don't Preempt" is enabled, the Ethernet Segment
            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
            Segment should be consistent in their configuration of the DP
            capability,
            capability; however, this document does not enforce the
            consistency across all the PEs. In case of inconsistency in the
            support of the DP capability in the PEs of the same Ethernet
            Segment, non-revertive behavior is not guaranteed. However, PEs
            supporting this capability still attempt this procedure.</t>

            <t>We assume
          </li>
          <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
            Preempt" capability. In this example, we assume ESI2 is configured
            as 'DP=enabled' in the three PEs.</t>
          </li>
          <li>
            <t>We also assume vES2 is attached to Ethernet Tag-1 and Ethernet
            Tag-2.
	    vES2 uses Highest-Preference as the DF Algorithm Algorithm, and a local
            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
            will exchange the Ethernet Segment routes and select PE3 as
            the Designated Forwarder for Ethernet Tag-1 (due to the
            Highest-Preference),
            Highest-Preference) and PE1 as the Designated Forwarder for Ethernet
            Tag-2 (due to the Lowest-Preference).</t>
          </li>
          <li>
            <t>If PE3's vES2 goes down (due to an EVC failure - (as detected by OAM,
            or OAM protocols),
            a port failure failure, or a node failure), PE2 will become the Designated
            Forwarder for Ethernet Tag-1. No changes will occur for Ethernet
            Tag-2.</t>
          </li>
          <li>
            <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
            timer will allow some time for PE3 to receive the Ethernet Segment
            routes from PE1 and PE2. This timer is applied between the INIT
            and the DF_WAIT states in the Designated Forwarder Election Finite
            State Machine described in <xref target="RFC8584"/>. target="RFC8584" format="default"/>. PE3 will
            then:</t>

<!--[rfced] In Section 4.3, item (5) lists the steps PE3 will
            then:<list style="symbols">
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
                in the virtual Ethernet Segment. If the Ethernet Segment uses
                the Highest-Preference algorithm, Algorithm, select a "Highest-PE". If it
                uses the Lowest-Preference algorithm, Algorithm, select a "Lowest-PE". If
                a local policy is in use, to override the
                Highest/Lowest-Preference
                Highest-/Lowest-Preference for a range of Ethernet Tags (as
                discussed in <xref target="sect-4.2"/>), target="sect-4.2" format="default"/>), it is necessary to
                select both a Highest-PE and a Lowest-PE. They are selected as
                follows: <list style="symbols"> </t>
                <ul spacing="normal">
                  <li>
                    <t>The Highest-PE is the PE with higher Preference, using
                    the DP bit first (with DP=1 being better) and, after that,
                    the lower PE-IP address as tiebreakers. </t>
                  </li>
                  <li>
                    <t>The Lowest-PE is the PE with lower Preference, using
                    the DP bit first (with DP=1 being better) and, after that,
                    the lower PE-IP address as tiebreakers. </t>
                  </li>
                  <li>
                    <t>In our example, the Highest-Preference algorithm Algorithm is
                    used, with a local policy to override it to use
                    Lowest-Preference for a range of Ethernet Tags. Therefore Therefore,
                    PE3 selects a Highest-PE and a Lowest-PE. PE3 will select
                    PE2 as the Highest-PE over PE1, since, 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, since because
                    (100,1,PE1-IP) wins over (200,1,PE2-IP). Note that if
                    there were only one remote PE in the Ethernet Segment,
                    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
                one of the Highest-PE and Lowest-PE that have the DP
                capability set in their Ethernet Segment routes. Depending on
                this comparison comparison, PE3 sends the Ethernet Segment route with a
                (Pref,DP) that may be different from its administrative
                (Pref,DP):<list style="symbols">
                (Pref,DP):</t>
                <ul spacing="normal">
                  <li>
                    <t>If PE3's Pref value is higher than or equal than to the
                    Highest-PE's, PE3 will send the Ethernet Segment route
                    with an 'in-use' operational Pref equal to the
                    Highest-PE's and DP=0.</t>
                  </li>
                  <li>
                    <t>If PE3's Pref value is lower than or equal than to the
                    Lowest-PE's, PE3 will send the Ethernet Segment route with
                    an 'in-use' operational Preference equal to the
                    Lowest-PE's and DP=0.</t>
                  </li>
                  <li>
                    <t>If PE3's Pref value is not higher than or equal than to the
                    Highest-PE's and is not lower than or equal than to the
                    Lowest-PE's, PE3 will send the Ethernet Segment route with
                    its administrative (Pref,DP)=(300,1).</t>
                  </li>
                  <li>
                    <t>In this example, PE3's administrative Pref=300 is
                    higher than the Highest-PE with DP=1, that is, PE2
                    (Pref=200). Hence, PE3 will inherit PE2's preference and
                    send the Ethernet Segment route with an operational
                    'in-use' (Pref,DP)=(200,0).</t>
                  </list></t>
                  </li>
                </ul>
              </li>
              <li>
                <t>Note that, 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).</t>
              </li>
              <li>
                <t>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 the
                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.</t>
              </list></t>
              </li>
            </ul>
          </li>
          <li>
            <t>For any subsequent received update/withdraw in the Ethernet
            Segment, the PEs will go through the process described in (5) to
            select Highest the Highest-PEs and Lowest-PEs, now considering themselves as
            candidates. For instance, if PE2 fails, fails upon receiving PE2's
            Ethernet Segment route withdrawal, PE3 and PE1 will go through the
            selection of the new Highest Highest-PEs and Lowest-PEs (considering their own
            active Ethernet Segment route) route), and then they will run the
            Designated Forwarder Election.<list style="symbols"> Election.</t>
            <ul spacing="normal">
              <li>
                <t>If a PE selects itself as the new Highest Highest-PE or Lowest-PE and it
                was not before, the PE will then compare its operational
                'in-use' Pref with its administrative Pref. If different, the
                PE will send an Ethernet Segment route update with its
                administrative Pref and DP values. In the example, PE3 will be
                the new Highest-PE, therefore Highest-PE; therefore, it will send an Ethernet Segment
                route update with (Pref,DP)=(300,1).</t>
              </li>
              <li>
                <t>After running the Designated Forwarder Election, PE3 will
                become the new Designated Forwarder for Ethernet Tag-1. No
                changes will occur for Ethernet Tag-2.</t>
              </list></t>
          </list></t>
              </li>
            </ul>
          </li>
        </ol>
        <t>Note that, irrespective of the DP bit, when a PE or Ethernet
        Segment comes back and the PE advertises a Designated Forwarder
        Election Algorithm different from the one configured in the rest of
        the PEs in the Ethernet Segment, all the PEs in the Ethernet Segment
        MUST
        <bcp14>MUST</bcp14> fall back to the Default <xref target="RFC7432"/> target="RFC7432" format="default"/> Algorithm.</t>

        <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"/> target="RFC8214" format="default"/> advertised by the
        PEs in the Ethernet Segment after running the Designated Forwarder
        Election, irrespective of the revertive or non-revertive behavior in
        the PE.</t>
      </section>
    </section>
    <section anchor="sect-5" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document describes a Designated Forwarder Election Algorithm
      that provides absolute control (by configuration) over what PE is the
      Designated Forwarder for a given Ethernet Tag. While this control is
      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
      the network. In other DF Algorithms such as HRW, the Designated
      Forwarder Election is more automated and cannot be determined by
      configuration.

<!--[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 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.</t>
      <t>The non-revertive capability described in this document may be seen
      as a security improvement over the regular EVPN revertive Designated
      Forwarder Election: an intentional link (or node) "flapping" on a PE
      will only cause service disruption once, when the PE goes 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
      disable the non-revertive behavior, by advertising a conflicting DF
      election algorithm and thereby forcing fallback to the Default
      algorithm. </t>
      <t>The document also describes how a local policy can override the
      Highest-Preference or Lowest-Preference algorithms Algorithms for a range of
      Ethernet Tags in the Ethernet Segment. If the local policy is not
      consistent across all PEs in the Ethernet Segment and there is an
      Ethernet Tag that ends up with an inconsistent use of Highest-Preference
      or Lowest-Preference in different PEs, packet drop or packet duplication
      may occur for that Ethernet Tag.</t>
      <t>Finally, the two Designated Forwarder Election Algorithms specified
      in this document (Highest-Preference and Lowest-Preference) do not
      change the way the PEs share their Ethernet Segment information,
      compared to the algorithms in <xref target="RFC7432"/> target="RFC7432" format="default"/> and <xref
      target="RFC8584"/>. Therefore target="RFC8584" format="default"/>. Therefore, the security considerations in <xref
      target="RFC7432"/> target="RFC7432" format="default"/> and <xref target="RFC8584"/> target="RFC8584" format="default"/> apply to this document
      too.</t>
      as well.</t>
    </section>
    <section anchor="sect-6" title="IANA Considerations">
      <t>This document solicits:</t>

      <t><list style="symbols">
          <t>The allocation of numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>Per this document, IANA has:</t>

      <ul spacing="normal">
        <li>
          <t>Allocated two new values in the "DF Alg" registry created
          by <xref target="RFC8584"/> target="RFC8584" format="default"/>, as follows:<figure>
              <artwork><![CDATA[Alg         Name                               Reference
----        -----------------------------      -------------
2           Highest-Preference Algorithm       This document
TBD         Lowest-Preference Algorithm        This document]]></artwork>
            </figure></t>

          <t>The allocation of follows:</t>

	  <table align="left">
	    <thead>
	      <tr>
		<th>Alg</th>
		<th>Name</th>
                <th>Reference</th>
	      </tr>
	    </thead>
	    <tbody>
	      <tr>
		<td>2</td>
		<td>Highest-Preference Algorithm</td>
		<td>RFC 9785</td>
	      </tr>
	      <tr>
		<td>3</td>
		<td>Lowest-Preference Algorithm</td>
		<td>RFC 9785</td>
	      </tr>
	    </tbody>
	  </table>
        </li>
        <li>
          <t>Allocated a new value in the "DF Election Capabilities"
          registry created by <xref target="RFC8584"/> target="RFC8584" format="default"/> for the 2-octet Bitmap
          field in the DF Election Extended Community (Border gateway (under the "Border
          Gateway Protocol (BGP) Extended Communities registry), Communities" registry group), as follows:<figure>
              <artwork><![CDATA[Bit         Name                             Reference
----        -----------------------------    -------------
0           D follows:</t>

	  <table align="left">
	    <thead>
	      <tr>
		<th>Bit</th>
		<th>Name</th>
                <th>Reference</th>
	      </tr>
	    </thead>
	    <tbody>
	      <tr>
		<td>0</td>
		<td>D (Don't Preempt) Capability     This document]]></artwork>
            </figure></t>
        </list><list style="symbols">
          <t>To update the Capability</td>
		<td>RFC 9785</td>
	      </tr>
	    </tbody>
	  </table>
        </li>

        <li>
          <t>Listed this document as an additional reference of for the "DF DF Election Extended Community"
          field, Community field in the EVPN "EVPN Extended Community Sub-Types Sub-Types" registry, as
          follows:<figure>
              <artwork><![CDATA[Sub-Type Value     Name                              Reference
--------------     ------------------------------    ---------------------------
0x06               DF 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    [RFC8584] Community</td>
		<td><xref target="RFC8584"/> and This Document]]></artwork>
            </figure> </t>
        </list></t> RFC 9785</td>
	      </tr>
	    </tbody>
	  </table>
        </li>
      </ul>

    </section>
  </middle>
  <back>
    <references>

<!-- [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.7432.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8584.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.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.8214.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8365.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7623.xml"/>
      </references>
    </references>
     <section anchor="sect-7" title="Acknowledgments "> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to thank Kishore Tiruveedhula and Sasha
      Vainshtein <contact fullname="Kishore
      Tiruveedhula"/> and <contact fullname="Sasha Vainshtein"/> for their review
      reviews and comments. Also Also, thank you to Luc Andre
      Burdet and Stephane Litkowski <contact fullname="Luc André
      Burdet"/> and <contact fullname="Stephane Litkowski"/> for their
      thorough review reviews and suggestions for a new
      Lowest-Preference DF Algorithm for lowest-preference.</t> Algorithm.</t>
    </section>
    <section anchor="sect-8" title="Contributors "> numbered="false" toc="default">
      <name>Contributors</name>
      <t>In addition to the authors listed, the following individuals also
      contributed to this document:</t>

      <t>Tony Przygienda, Juniper</t>

      <t>Satya Mohanty, Cisco</t>

      <t>Kiran Nagaraj, Nokia</t>

      <t>Vinod Prabhu, Nokia</t>

      <t>Selvakumar Sivaraj, Juniper</t>

      <t>Sami Boutros, VMWare</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>
  </middle>

  <back>
    <references title="Normative References">
      &RFC7432;

      &RFC8584;

      &RFC2119;

      &RFC8174;

      &I-D.ietf-bess-evpn-virtual-eth-segment;
    </references>

    <references title="Informative References">
      &RFC8214;

      &RFC8365;

      &RFC7623;
    </references>
  </back>

<!-- [rfced] Terminology

a) May we update the following terms to the form on the right for
consistency within the document and Cluster 492 (C492)?

  Designated Forwarder Election vs.
   Designated Forwarder election -> DF election

  Designated Forwarder Election Algorithm vs.
   Designated Forwarder Election algorithm vs.
   Designated Forwarder election algorithm -> DF election algorithm

  Default Designated Forwarder Election Algorithm vs.
   Default Designated Forwarder Election algorithm vs.
   default Designated Forwarder election algorithm
   -> default DF election algorithm (per RFC 8584)

b) Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how they
may be made consistent.

 Default DF Algorithm vs. Default Algorithm vs. Default algorithm
   [Note: Should "Default" perhaps be lowercase? Should "DF" be
   removed or added for consistency (also see (c) below)?
   Perhaps: "default DF algorithm" (per RFC 8584)

 Preference value vs. preference value

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

Per the "DF Alg" registry <https://www.iana.org/assignments/bgp-extended-communities>,
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?

Per the "DF Alg" registry:
   2   Highest-Preference Algorithm
   3   Lowest-Preference Algorithm

A few examples that vary in the text (see the document for more examples):

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

</rfc>