Preference-based EVPN DF Election
draft-ietf-bess-evpn-pref-df-10

BESS Workgroup                                           J. Rabadan, Ed.
Internet-Draft                                              S. Sathappan
Intended status: Standards Track                                   Nokia
Expires: 6 March 2023                                             W. Lin
                                                                J. Drake
                                                        Juniper Networks
                                                              A. Sajassi
                                                           Cisco Systems
                                                        2 September 2022

                   Preference-based EVPN DF Election
                    draft-ietf-bess-evpn-pref-df-10

Abstract

   The Designated Forwarder (DF) in Ethernet Virtual Private Networks
   (EVPN) is defined as the PE responsible for sending Broadcast,
   Unknown unicast and Broadcast traffic (BUM) to a 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 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' and user-controlled method is required.  At
   the same time, Service Providers 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.

   This document proposes a Designated Forwarder Election algorithm that
   meets the requirements of determinism and operation control.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

Rabadan, et al.           Expires 6 March 2023                  [Page 1]
Internet-Draft      Preference-based EVPN DF Election     September 2022

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 6 March 2023.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Solution requirements . . . . . . . . . . . . . . . . . .   3
   2.  Requirements Language and Terminology . . . . . . . . . . . .   4
   3.  EVPN BGP Attributes Extensions  . . . . . . . . . . . . . . .   5
   4.  Solution description  . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Use of the Highest-Preference and Lowest Preference
           Algorithm . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.2.  Use of the Highest-Preference algorithm in [RFC7432]
           Ethernet Segments . . . . . . . . . . . . . . . . . . . .  12
     4.3.  The Non-Revertive Capability  . . . . . . . . . . . . . .  13
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  17
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  18
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

Rabadan, et al.           Expires 6 March 2023                  [Page 2]
Internet-Draft      Preference-based EVPN DF Election     September 2022

1.1.  Problem Statement

   [RFC7432] defines the Designated Forwarder (DF) in EVPN networks as
   the PE responsible for sending Broadcast, Multicast and Unknown
   unicast traffic (BUM) to a multi-homed device/network in the case of
   an all-active multi-homing Ethernet Segment or BUM and unicast
   traffic to a multi-homed device or network in case of 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, or DF Alg as per [RFC8584].

   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 'deterministic' and user-controlled method is
   required.  At the same time, Service Providers 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.

   This document proposes two new DF Algs (Highest-Preference and
   Lowest-Preference) which provide the deterministic Designated
   Forwarder method required, as well as the "Don't Preempt" capability
   to address the need to control whether a PE can take over an existing
   Designated Forwarder PE.

1.2.  Solution requirements

   The procedures described in this document meet the following
   requirements:

   a.  The solution provides an administrative preference option so that
       the user can control in what order the candidate PEs may become
       Designated Forwarder, assuming they are all operationally ready
       to take over as 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 Designated
       Forwarder, based on the DF Algs described in this document.

   b.  The extensions in this document work for [RFC7432] Ethernet
       Segments and virtual Ethernet Segments, as defined in
       [I-D.ietf-bess-evpn-virtual-eth-segment].

Rabadan, et al.           Expires 6 March 2023                  [Page 3]
Internet-Draft      Preference-based EVPN DF Election     September 2022

   c.  The user may force a PE to preempt the existing Designated
       Forwarder for a given Ethernet Tag without re-configuring all the
       PEs in the Ethernet Segment, by simply modifying the existing
       administrative preference in that PE.

   d.  The solution allows an option to NOT preempt the current
       Designated Forwarder ("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
       [RFC7432] Designated Forwarder election procedures that are
       always revertive (because the winner PE of the default Designated
       Forwarder election algorithm always takes over as the operational
       Designated Forwarder).

   e.  The procedures described in this document support single-active
       and all-active multi-homing Ethernet Segments.

2.  Requirements Language and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   *  AC - Attachment Circuit.  An AC has an Ethernet Tag associated to
      it.

   *  BUM - refers to the Broadcast, Unknown unicast and Multicast
      traffic.

   *  DF, NDF and BDF - Designated Forwarder, Non-Designated Forwarder
      and Backup Designated Forwarder.

   *  DF Alg - refers to Designated Forwarder Election Algorithm.  This
      is sometimes shortened to "Alg" in this document.

   *  HRW - Highest Random Weight, as per [RFC8584].

   *  ES, vES and ESI - Ethernet Segment, virtual Ethernet Segment and
      Ethernet Segment Identifier.

   *  EVI - EVPN Instance.

   *  ISID - refers to Service Instance Identifiers in Provider Backbone
      Bridging (PBB) networks.

Rabadan, et al.           Expires 6 March 2023                  [Page 4]
Internet-Draft      Preference-based EVPN DF Election     September 2022

   *  MAC-VRF - A Virtual Routing and Forwarding table for Media Access
      Control (MAC) addresses on a PE.

   *  BD - Broadcast Domain.  An EVI may be comprised of one (VLAN-Based
      or VLAN Bundle services) or multiple (VLAN-Aware Bundle services)
      Broadcast Domains.

   *  EVC - Ethernet Virtual Circuit.

   *  DP - refers to the "Don't Preempt me" capability in the Designated
      Forwarder Election extended community.

   *  OAM - refers to Operations And Maintenance protocols.

   *  Ethernet A-D per ES route - refers to [RFC7432] route type 1 or
      Auto-Discovery per Ethernet Segment route.

   *  Ethernet A-D per EVI route - refers to [RFC7432] route type 1 or
      Auto-Discovery per EVPN Instance route.

   *  Ethernet Tag - used to represent a Broadcast Domain that is
      configured on a given Ethernet Segment for the purpose of
      Designated Forwarder election.  Note that any of the following may
      be used to represent a Broadcast Domain: VIDs (including Q-in-Q
      tags), configured IDs, VNI (VXLAN Network Identifiers), normalized
      VID, I-SIDs (Service Instance Identifiers), etc., as long as the
      representation of the broadcast domains is configured consistently
      across the multi-homed PEs attached to that Ethernet Segment.  The
      Ethernet Tag value MUST be different from zero.

3.  EVPN BGP Attributes Extensions

   This solution reuses and extends the Designated Forwarder Election
   Extended Community defined in [RFC8584] that is advertised along with
   the Ethernet Segment route, by replacing the last two reserved octets
   of the DF Election Extended Community when the DF Alg is set to
   Highest-Preference or Lowest-Preference.  This document also defines
   a new capability referred to as "Don't Preempt" capability, that MAY
   be used with DF Algs Highest-Preference or Lowest-Preference.  The
   format of the DF Election Extended Community that is used in this
   document follows:

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type=0x06     | Sub-Type(0x06)| RSV |  DF Alg |    Bitmap     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~     Bitmap    |   Reserved    |   DF Preference (2 octets)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Rabadan, et al.           Expires 6 March 2023                  [Page 5]
Internet-Draft      Preference-based EVPN DF Election     September 2022

                  Figure 1: DF Election Extended Community

   Where the above fields are defined as follows:

   *  DF Alg can have the following values:

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

      -  Alg 1 - HRW algorithm as per [RFC8584].

      -  Alg 2 - Highest-Preference algorithm (this document
         Section 4.1).

      -  Alg TBD - Lowest-Preference algorithm (this document
         Section 4.1).  TBD will be replaced by the allocated value at
         the time of publication.

   *  Bitmap (2 octets) encodes "capabilities" [RFC8584], where this
      document defines the "Don't Preempt" capability, used to indicate
      if a PE supports a non-revertive behavior:

                          1 1 1 1 1 1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |D|A|                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 2: Bitmap field in the DF Election Extended Community

      -  Bit 0 (corresponds to Bit 24 of the Designated Forwarder
         Election Extended Community and it is defined by this
         document): 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 Alg [RFC7432].  The DP capability is supported by DF
         Algs Highest-Preference or Lowest-Preference, and MAY be used
         with the default DF Alg or HRW [RFC8584].  The procedures of
         the "Don't Preempt" capability for the default DF Alg or HRW
         are out of the scope of this document.  The procedures of the
         "Don't Preempt" capability for DF Algs Highest-Preference and
         Lowest-Preference are described in Section 4.1.

      -  Bit 1: AC-DF or AC-Influenced Designated Forwarder Election is
         described in [RFC8584].  When set to 1, it indicates the desire
         to use AC-Influenced Designated Forwarder Election with the

Rabadan, et al.           Expires 6 March 2023                  [Page 6]
Internet-Draft      Preference-based EVPN DF Election     September 2022

         rest of the PEs in the Ethernet Segment.  The AC-DF capability
         bit MAY be set along with the DP capability and DF Algs
         Highest-Preference or Lowest-Preference.

   *  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
      Section 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 Alg being used, as explained in
      Section 4.1.  The Designated Forwarder Preference field is
      specific to DF Algs Highest-Preference and Lowest-Preference, and
      this document does not define any meaning for other algorithms.
      If the DF Alg is different from Highest-Preference or Lowest-
      Preference, these two octets can be encoded differently.

   *  RSV and Reserved fields (from bit 16 to bit 18, and from bit 40 to
      47): when DF Alg is set to Highest-Preference or Lowest-Preference
      algorithm, the values are set to zero when advertising the
      Ethernet Segment route, and they are ignored when receiving the
      Ethernet Segment route.

4.  Solution description

   Figure 3 illustrates an example that will be used in the description
   of the solution.

Rabadan, et al.           Expires 6 March 2023                  [Page 7]
Internet-Draft      Preference-based EVPN DF Election     September 2022

                 EVPN network
            +-------------------+
            |                +-------+  ENNI    Aggregation
            |   <---ESI1,500 |  PE1  |   /\  +----Network---+
            | <-----ESI2,100 |       |===||===              |
            |                |       |===||== \      vES1   |  +----+
        +-----+              |       |   \/  |\----------------+CE1 |
   CE3--+ PE4 |              +-------+       | \   ------------+    |
        +-----+                 |            |  \ /         |  +----+
            |                   |            |   X          |
            |   <---ESI1,255  +-----+============ \         |
            | <-----ESI2,200  | PE2 |==========    \ vES2   | +----+
            |                 +-----+        | \    ----------+CE2 |
            |                   |            |  --------------+    |
            |                 +-----+   ----------------------+    |
            | <-----ESI2,300  | PE3 +--/     |              | +----+
            |                 +-----+        +--------------+
            --------------------+

                   Figure 3: Preference-based DF Election

   Figure 3 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 spans PE1 and PE2 - and CE2 is connected to
   vES2, that is attached to PE1, PE2 and PE3.

   If the algorithm chosen for vES1 and vES2 is DF Alg Highest-
   Preference or Lowest-Preference, the PEs may become 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
   of Figure 3.

4.1.  Use of the Highest-Preference and Lowest Preference Algorithm

   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 Designated Forwarder in case of
   multiple failures, the following procedure may be used:

Rabadan, et al.           Expires 6 March 2023                  [Page 8]
Internet-Draft      Preference-based EVPN DF Election     September 2022

   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 Alg. 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-Preferance), (200,0,Highest-Preference) and
       (300,0,Highest-Preference) in PE1, PE2 and PE3 respectively.

   b.  The PEs advertise an Ethernet Segment route for each virtual
       Ethernet Segment, including the three parameters indicated in 'a'
       above, in the Designated Forwarder Election Extended Community
       Section 3.

   c.  According to [RFC8584], 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 Alg for each
       Ethernet Segment as follows:

       *  The PE will check the DF Alg value in each Ethernet Segment
          route, and assuming all the Ethernet Segment routes (including
          the local route) are consistent in this DF Alg (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 [RFC7432] Default Alg.
          The Highest-Preference and Lowest-Preference Algs are
          different Algs, therefore if two PEs configured for Highest-
          Preference and Lowest-Preference respectively, are attached to
          the same Ethernet Segment, the operational Designated
          Forwarder Election Alg will fall back to the Default Alg.

       *  If all the PEs attached to the Ethernet Segment advertise
          Highest-Preference Alg, each PE builds a list of candidate
          PEs, ordered by Preference value from the numerically highest
          value to lowest value.  E.g., PE1 builds a list of candidate
          PEs for vES1 ordered by the Preference, from high to low:
          <PE1, PE2> (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.

Rabadan, et al.           Expires 6 March 2023                  [Page 9]
Internet-Draft      Preference-based EVPN DF Election     September 2022

       *  If all the PEs attached to the Ethernet Segment advertise
          Lowest-Preference Alg, then the candidate lits is ordered from
          the numerically lowest Preference value to the highest
          Preference value.  E.g., PE1's ordered list for vES1 is <PE2,
          PE1>.  Hence PE2 becomes the Designated Forwarder for vES1.
          In the same way, PE1 becomes the Designated Forwarder for
          vES2.

   d.  Assuming some maintenance tasks had to be executed on a 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., if PE3 is going on maintenance and
       the DF Alg is Highest-Preference, the operator could change
       vES2's Preference on PE3 from 300 to E.g., 50 (hence the Ethernet
       Segment route from PE3 is updated with the new preference value)
       so that PE2 is forced to take over as Designated Forwarder for
       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 DF
       Alg Lowest-Preference too.

   e.  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 PEs are used as tie-breakers.  If more that one PE is
       advertising itself as the preferred Designated Forwarder, an
       implementation MUST 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 and it is
       derived from the Originating Router's IP address of the Ethernet
       Segment route.  In case PEs use 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 the DP bit and IP address tie-breakers follow:

       *  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.  Same example applies if PE1 and PE2 advertise
          Lowest-Preference DF Alg instead.

       *  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 addres is lower than PE1's.  Same example applies
          if PE1 and PE2 advertise Lowest-Preference DF Alg instead.

Rabadan, et al.           Expires 6 March 2023                 [Page 10]
Internet-Draft      Preference-based EVPN DF Election     September 2022

   f.  The Preference is an administrative option that MUST be
       configured on a per-Ethernet Segment basis, and it is normally
       configured from the management plane.  The Preference value MAY
       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.

          E.g., on PE1, if the DF Alg is Highest-Preference, ES1's
          Preference value can be lowered from 500 to 100 in case the
          bandwidth on the ENNI port is decreased a 50% (that could
          happen if e.g. the 2-port LAG between PE1 and the Aggregation
          Network loses one port).

          Local policy MAY also trigger dynamic Preference changes based
          on the PE's bandwidth availability in the core, specific ports
          going operationally down, etc.

          The definition of the actual local policies is out of scope of
          this document.

   The Highest-Preference and Lowest-Preference Algs MAY be used along
   with the AC-DF capability.  Assuming all the PEs in the Ethernet
   Segment are configured consistently with Highest-Preference or
   Lowest-Preference Alg and AC-DF capability, a given PE in the
   Ethernet Segment is not considered as candidate for Designated
   Forwarder Election until its corresponding Ethernet A-D per ES and
   Ethernet A-D per EVI routes are not received, as described in
   [RFC8584].

   The Highest-Preference and Lowest-Preference DF Algs 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, PE2 and PE3
   Lowest-Preference for vES2.  The use of one DF Alg over the other is
   the operator's choice.  The existence of both provide flexibility and
   full control to the operator.

   The procedures in this document can be used in [RFC7432] based
   Ethernet Segment or virtual Ethernet Segment as in
   [I-D.ietf-bess-evpn-virtual-eth-segment], and including EVPN networks
   as in [RFC8214], [RFC7623] or [RFC8365].

Rabadan, et al.           Expires 6 March 2023                 [Page 11]
Internet-Draft      Preference-based EVPN DF Election     September 2022

4.2.  Use of the Highest-Preference algorithm in [RFC7432] Ethernet
      Segments

   While the Highest-Preference or Lowest-Preference DF Alg described in
   Section 4.1 is typically used in virtual Ethernet Segment scenarios
   where there is normally an individual Ethernet Tag per virtual
   Ethernet Segment, the existing [RFC7432] definition of an Ethernet
   Segment allows potentially up to thousands of Ethernet Tags on the
   same Ethernet Segment.  If this is the case, if Highest-Preference or
   Lowest-Preference Alg 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 achive
   a more granular load balancing is decribed below.

   The Ethernet Segment is configured with an administrative Preference
   value and an administrative DF Alg, i.e., Highest-Preference or
   Lowest-Preference Alg. However, the administrative DF Alg (which is
   used to signal the DF Alg for the Ethernet Segment) MAY be overridden
   to a different operational DF Alg for a range of Ethernet Tags.  With
   this option, the PE builds a list of candidate PEs ordered by
   Preference, however the Designated Forwarder for a given Ethernet Tag
   will be determined by the local overridden DF Alg.

   For instance:

   *  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).  Both PEs will advertise the Ethernet Segment routes
      for ES3 with the indicated parameters in the DF Election Extended
      Community.

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

   *  This will result in PE1 being Designated Forwarder for Ethernet
      Tags 1-2000 (since they use the default Highest-Preference Alg)
      and PE2 being Designated Forwarder for Ethernet Tags 2001-4000,
      due to the local policy overriding the Highest-Preference Alg.

   For Ethernet Segments attached to three or more PEs, any other logic
   that provides a fair distribution of the Designated Forwarder
   function among the 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 be consistent in all the PEs of the Ethernet

Rabadan, et al.           Expires 6 March 2023                 [Page 12]
Internet-Draft      Preference-based EVPN DF Election     September 2022

   Segment.  If the local policy is inconsistent for a given Ethernet
   Tag in the Ethernet Segment, black-holes or packet duplication may
   occur on that Ethernet Tag.

4.3.  The Non-Revertive Capability

   As discussed in Section 1.2 (d), 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 Election extended community.  This option allows a non-
   revertive behavior in the Designated Forwarder election.

   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.

   In Figure 3, we assume that based on the Highest-Preference Alg, PE3
   is the Designated Forwarder for ESI2.

   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
   over, causing some unnecessary packet loss in the Ethernet Segment.

   The following procedure avoids preemption upon failure recovery
   (please refer to Figure 3).  The procedure supports a non-revertive
   mode that can be used along with:

   *  Highest-Preference Alg

   *  Highest-Preference Alg, where a local policy overrides the
      Highest-Preference tie-breaker for a range of Ethernet Tags

   *  Lowest-Preference Alg

   The procedure is described assuming Highest-Preference Alg in the
   Ethernet Segment, where local policy overrides the tie-breaker for a
   given Ethernet Tag, since this is the most complex case.  The other
   two cases above are a sub-set of this one and the differences will be
   explained later.

   1.  A "Don't Preempt" capability is defined on a per-PE/per-Ethernet
       Segment basis, as described in Section 3.  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

Rabadan, et al.           Expires 6 March 2023                 [Page 13]
Internet-Draft      Preference-based EVPN DF Election     September 2022

       Me" is enabled, the Ethernet Segment route from the PE will
       indicate 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,
       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 will still attempt this procedure.

   2.  We assume 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.

   3.  We also assume vES2 is attached to Ethernet Tag-1 and Ethernet
       Tag-2. vES2 uses Highest-Preference as DF Alg 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
       Designated Forwarder for Ethernet Tag-1 (due to the Highest-
       Preference), and PE1 as Designated Forwarder for Ethernet Tag-2
       (due to the Lowest-Preference).

   4.  If PE3's vES2 goes down (due to EVC failure - detected by OAM, or
       port failure or node failure), PE2 will become the Designated
       Forwarder for Ethernet Tag-1.  No changes will occur for Ethernet
       Tag-2.

   5.  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 [RFC8584].  PE3 will
       then:

       *  Select two "reference-PEs" among the Ethernet Segment routes
          in the virtual Ethernet Segment, the "Highest-PE" and the
          "Lowest-PE":

          -  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 tie-breakers.  PE3 will select PE2
             as Highest-PE over PE1, since, when comparing (Pref,DP,PE-
             IP), (200,1,PE2-IP) wins over (100,1,PE1-IP).

Rabadan, et al.           Expires 6 March 2023                 [Page 14]
Internet-Draft      Preference-based EVPN DF Election     September 2022

          -  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 tie-breakers.  PE3 will select PE1
             as Lowest-PE over PE2, since (100,1,PE1-IP) wins over
             (200,1,PE2-IP).

          -  Note that if there were only one remote PE in the Ethernet
             Segment, Lowest and Highest PE would be the same PE.

       *  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 PE3 will send the Ethernet Segment route with a
          (Pref,DP) that may be different from its administrative
          (Pref,DP):

          -  If PE3's Pref value is higher or equal than 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.

          -  If PE3's Pref value is lower or equal than 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.

          -  If PE3's Pref value is not higher or equal than the
             Highest-PE's and is not lower or equal than the Lowest-
             PE's, PE3 will send the Ethernet Segment route with its
             administrative (Pref,DP)=(300,1).

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

       *  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 tie-breaker in the Designated
          Forwarder election.  That is, if a PE has two candidate PEs
          with the same Pref, it will pick up the one with DP=1.  There
          are no Designated Forwarder changes for Ethernet Tag-2 either.

Rabadan, et al.           Expires 6 March 2023                 [Page 15]
Internet-Draft      Preference-based EVPN DF Election     September 2022

   6.  For any subsequent received update/withdraw in the Ethernet
       Segment, the PEs will go through the process described in (5) to
       select Highest and Lowest-PEs, now considering themselves as
       candidates.  For instance, if PE2 fails, upon receiving PE2's
       Ethernet Segment route withdrawal, PE3 and PE1 will go through
       the selection of new Highest and Lowest-PEs (considering their
       own active Ethernet Segment route) and then they will run the
       Designated Forwarder Election.

       *  If a PE selects itself as new Highest 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 it will send an Ethernet Segment route
          update with (Pref,DP)=(300,1).

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

   If the Ethernet Segment uses Highest-Preference Alg (for all the
   Ethernet Tags, no local policy), the PEs only need to select the
   "Highest-PE" as the "reference-PE" (i.e., no need to select the
   "Lowest-PE").  If the Ethernet Segment uses Lowest-Preference Alg for
   all the Ethernet Tags, the PEs only need to select the "Lowest-PE" as
   the "reference-PE".  The rest of the procedure remains the same.

   Note that, irrespective of the DP bit, when a PE or Ethernet Segment
   comes back and the PE advertises a Designated Forwarder Election Alg
   different than the one configured in the rest of the PEs in the
   Ethernet Segment, all the PEs in the Ethernet Segment MUST fall back
   to the Default [RFC7432] Alg.

   This document does not modify the use of the P and B bits in the
   Ethernet A-D per EVI routes [RFC8214] 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.

5.  Security Considerations

   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 Algs such as HRW, the Designated
   Forwarder Election is more automated and cannot be determined by

Rabadan, et al.           Expires 6 March 2023                 [Page 16]
Internet-Draft      Preference-based EVPN DF Election     September 2022

   configuration.  With Highest-Preference or Lowest-Preference as DF
   Alg, 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.

   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.

   The document also describes how a local policy can override the
   Highest-Preference Alg 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, black-holing or packet duplication may occur for that
   Ethernet Tag.

6.  IANA Considerations

   This document solicits:

   *  The allocation of two new values in the "DF Alg" registry created
      by [RFC8584] as follows:

      Alg         Name                               Reference
      ----        -----------------------------      -------------
      2           Highest-Preference Algorithm       This document
      TBD         Lowest-Preference Algorithm        This document

   *  The allocation of a new value in the "DF Election Capabilities"
      registry created by [RFC8584] for the 2-octet Bitmap field in the
      DF Election Extended Community (Border gateway Protocol (BGP)
      Extended Communities registry), as follows:

      Bit         Name                             Reference
      ----        -----------------------------    -------------
      0           D (Don't Preempt) Capability     This document

7.  Acknowledgments

   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 Alg for lowest-preference.

Rabadan, et al.           Expires 6 March 2023                 [Page 17]
Internet-Draft      Preference-based EVPN DF Election     September 2022

8.  Contributors

   In addition to the authors listed, the following individuals also
   contributed to this document:

   Tony Przygienda, Juniper

   Satya Mohanty, Cisco

   Kiran Nagaraj, Nokia

   Vinod Prabhu, Nokia

   Selvakumar Sivaraj, Juniper

   Sami Boutros, VMWare

9.  References

9.1.  Normative References

   [RFC7432]  Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
              Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
              Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
              2015, <https://www.rfc-editor.org/info/rfc7432>.

   [RFC8584]  Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake,
              J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet
              VPN Designated Forwarder Election Extensibility",
              RFC 8584, DOI 10.17487/RFC8584, April 2019,
              <https://www.rfc-editor.org/info/rfc8584>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [I-D.ietf-bess-evpn-virtual-eth-segment]
              Sajassi, A., Brissette, P., Schell, R., Drake, J. E., and
              J. Rabadan, "EVPN Virtual Ethernet Segment", Work in
              Progress, Internet-Draft, draft-ietf-bess-evpn-virtual-
              eth-segment-07, 6 July 2021,
              <https://www.ietf.org/archive/id/draft-ietf-bess-evpn-
              virtual-eth-segment-07.txt>.

Rabadan, et al.           Expires 6 March 2023                 [Page 18]
Internet-Draft      Preference-based EVPN DF Election     September 2022

9.2.  Informative References

   [RFC8214]  Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
              Rabadan, "Virtual Private Wire Service Support in Ethernet
              VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
              <https://www.rfc-editor.org/info/rfc8214>.

   [RFC8365]  Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
              Uttaro, J., and W. Henderickx, "A Network Virtualization
              Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
              DOI 10.17487/RFC8365, March 2018,
              <https://www.rfc-editor.org/info/rfc8365>.

   [RFC7623]  Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W.
              Henderickx, "Provider Backbone Bridging Combined with
              Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623,
              September 2015, <https://www.rfc-editor.org/info/rfc7623>.

Authors' Addresses

   J. Rabadan (editor)
   Nokia
   520 Almanor Avenue
   Sunnyvale, CA 94085
   United States of America
   Email: jorge.rabadan@nokia.com

   S. Sathappan
   Nokia
   Email: senthil.sathappan@nokia.com

   W. Lin
   Juniper Networks
   Email: wlin@juniper.net

   J. Drake
   Juniper Networks
   Email: jdrake@juniper.net

   A. Sajassi
   Cisco Systems
   Email: sajassi@cisco.com

Rabadan, et al.           Expires 6 March 2023                 [Page 19]