<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" docName="draft-ietf-bess-evpn-fast-df-recovery-12" number="9722" updates="8584" obsoletes="" consensus="true" submissionType="IETF" ipr="trust200902" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" xml:lang="en" prepTime="2025-05-31T18:13:17" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery-12" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9722" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Fast Recovery for EVPN DF Election">Fast Recovery for EVPN Designated Forwarder Election</title>
    <seriesInfo name="RFC" value="9722" stream="IETF"/>
    <author fullname="Patrice Brissette" initials="P." surname="Brissette">
      <organization showOnFrontPage="true">Cisco</organization>
      <address>
        <email>pbrisset@cisco.com</email>
      </address>
    </author>
    <author fullname="Ali Sajassi" initials="A." surname="Sajassi">
      <organization showOnFrontPage="true">Cisco</organization>
      <address>
        <email>sajassi@cisco.com</email>
      </address>
    </author>
    <author fullname="Luc André Burdet" initials="LA." surname="Burdet" role="editor">
      <organization showOnFrontPage="true">Cisco</organization>
      <address>
        <email>lburdet@cisco.com</email>
      </address>
    </author>
    <author fullname="John Drake" initials="J." surname="Drake">
      <organization showOnFrontPage="true">Independent</organization>
      <address>
        <email>je_drake@yahoo.com</email>
      </address>
    </author>
    <author fullname="Jorge Rabadan" initials="J." surname="Rabadan">
      <organization showOnFrontPage="true">Nokia</organization>
      <address>
        <email>jorge.rabadan@nokia.com</email>
      </address>
    </author>
    <date month="05" year="2025"/>
    <area>RTG</area>
    <workgroup>bess</workgroup>
    <keyword>EVPN</keyword>
    <keyword>Designated Forwarder</keyword>
    <keyword>Convergence</keyword>
    <keyword>Recovery</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">The Ethernet Virtual Private Network (EVPN) solution in RFC 7432
      provides Designated Forwarder (DF) election procedures for multihomed
      Ethernet Segments. These procedures have been enhanced further by
      applying the Highest Random Weight (HRW) algorithm for DF election to
      avoid unnecessary DF status changes upon a failure.  This document
      improves these procedures by providing a fast DF election upon recovery
      of the failed link or node associated with the multihomed Ethernet
      Segment.  This document updates RFC 8584 by optionally introducing
      delays between some of the events therein.</t>
      <t indent="0" pn="section-abstract-2">The solution is independent of the number of EVPN Instances (EVIs)
      associated with that Ethernet Segment, and it is performed via a simple
      signaling in BGP between the recovered node and each of the other nodes
      in the multihoming group.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9722" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.3">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.3.1"><xref derivedContent="1.3" format="counter" sectionFormat="of" target="section-1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-challenges-with-existing-me">Challenges with Existing Mechanism</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.4">
                <t indent="0" pn="section-toc.1-1.1.2.4.1"><xref derivedContent="1.4" format="counter" sectionFormat="of" target="section-1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-design-principles-for-a-sol">Design Principles for a Solution</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-df-election-synchronization">DF Election Synchronization Solution</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-bgp-encoding">BGP Encoding</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-timestamp-verification">Timestamp Verification</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.3">
                <t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-updates-to-rfc-8584">Updates to RFC 8584</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-synchronization-scenarios">Synchronization Scenarios</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-concurrent-recoveries">Concurrent Recoveries</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-backwards-compatibility">Backwards Compatibility</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="intro" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">The Ethernet Virtual Private Network (EVPN) solution <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/> is
     widely used in data center (DC) applications for Network
     Virtualization Overlay (NVO) and Data Center Interconnect (DCI) services and
     in service provider (SP) applications for next-generation virtual
     private LAN services.</t>
      <t indent="0" pn="section-1-2"><xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/> describes Designated Forwarder (DF) election procedures for
     multihomed Ethernet Segments. These procedures are enhanced further in
     <xref target="RFC8584" format="default" sectionFormat="of" derivedContent="RFC8584"/> by applying the Highest Random Weight (HRW) algorithm for DF
     election in order to avoid unnecessary DF status changes upon a link
     or node failure associated with the multihomed Ethernet Segment.</t>
      <t indent="0" pn="section-1-3">This document makes further improvements to the DF election procedures in
     <xref target="RFC8584" format="default" sectionFormat="of" derivedContent="RFC8584"/> by providing an option for a fast DF election upon
     recovery of the failed link or node associated with the multihomed
     Ethernet Segment. This DF election is achieved independent of the number
     of EVPN Instances (EVIs) associated with that Ethernet Segment, and it is performed via
     straightforward signaling in BGP between the recovered node and each of the other nodes
     in the multihomed Ethernet Segment redundancy group.</t>
      <t indent="0" pn="section-1-4">This document updates the DF Election Finite State Machine (FSM)
     described in <xref target="RFC8584" section="2.1" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8584#section-2.1" derivedContent="RFC8584"/> by optionally
     introducing delays between some events, as further detailed in <xref target="fsm_8584" format="default" sectionFormat="of" derivedContent="Section 2.3"/>.  The solution is based on a simple one-way signaling
     mechanism.</t>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-requirements-language">Requirements Language</name>
        <t indent="0" pn="section-1.1-1">
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
      <section anchor="terminology" numbered="true" removeInRFC="false" toc="include" pn="section-1.2">
        <name slugifiedName="name-terminology">Terminology</name>
        <dl indent="3" newline="false" spacing="normal" pn="section-1.2-1">
          <dt pn="section-1.2-1.1">PE:</dt>
          <dd pn="section-1.2-1.2">Provider Edge</dd>
          <dt pn="section-1.2-1.3">DF:</dt>
          <dd pn="section-1.2-1.4">Designated Forwarder. A PE that is currently forwarding
           (encapsulating/decapsulating) traffic for a given VLAN in and out of
           a site.</dd>
          <dt pn="section-1.2-1.5">NDF:</dt>
          <dd pn="section-1.2-1.6">Non-Designated Forwarder. A PE that is currently blocking traffic (see
           DF above).</dd>
          <dt pn="section-1.2-1.7">EVI:</dt>
          <dd pn="section-1.2-1.8">EVPN Instance. It spans the PE devices participating in that
          EVPN.</dd>
          <dt pn="section-1.2-1.9">HRW:</dt>
          <dd pn="section-1.2-1.10">Highest Random Weight algorithm <xref target="HRW98" format="default" sectionFormat="of" derivedContent="HRW98"/></dd>
          <dt pn="section-1.2-1.11">Service carving:</dt>
          <dd pn="section-1.2-1.12">This refers to DF election, as defined in <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/>.</dd>
          <dt pn="section-1.2-1.13">SCT:</dt>
          <dd pn="section-1.2-1.14">Service Carving Time. Defined in this document as the time at
           which all nodes participating in an Ethernet Segment perform DF Election.</dd>
        </dl>
      </section>
      <section anchor="challenges" numbered="true" removeInRFC="false" toc="include" pn="section-1.3">
        <name slugifiedName="name-challenges-with-existing-me">Challenges with Existing Mechanism</name>
        <t indent="0" pn="section-1.3-1">In EVPN technology, multiple PE devices encapsulate
        and decapsulate data belonging to the same VLAN. Under certain conditions, this
        may cause duplicated Ethernet packets and potential loops if there is a momentary
        overlap in forwarding roles between two or more PE devices, potentially also leading
        to broadcast storms of frames forwarded back into the VLAN.</t>
        <t indent="0" pn="section-1.3-2">EVPN <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/> currently specifies timer-based synchronization among PE
        devices within an Ethernet Segment redundancy group. This approach can lead to duplications and potential
        loops due to multiple DFs if the timer interval is too short
        or can lead to packet drops if the timer interval is too long.</t>
        <t indent="0" pn="section-1.3-3">Split-horizon filtering, as described in <xref target="RFC7432" section="8.3" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc7432#section-8.3" derivedContent="RFC7432"/>,
        can prevent loops but does not address duplicates.
        However, if there are overlapping DFs of two
        different sites simultaneously for the same VLAN, the site identifier will differ when the
        packet re-enters the Ethernet Segment. Consequently, the split-horizon check will fail,
        resulting in Layer 2 loops.</t>
        <t indent="0" pn="section-1.3-4">The updated DF procedures outlined in <xref target="RFC8584" format="default" sectionFormat="of" derivedContent="RFC8584"/>
        use the well-known
        HRW algorithm to prevent the reshuffling of VLANs among
        PE devices within the Ethernet Segment redundancy group during failure or recovery events. This
        approach minimizes the impact on VLANs not assigned to the failed or recovered ports
        and eliminates the occurrence of loops or duplicates during such events.</t>
        <t indent="0" pn="section-1.3-5">However, upon PE insertion or a port being newly added to a multihomed Ethernet Segment,
        the HRW cannot help either, as a transfer of the DF role to the new port must occur
        while the old DF is still active.</t>
        <figure anchor="topology" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-ce1-multihomed-to-pe1-and-p">CE1 Multihomed to PE1 and PE2</name>
          <artwork align="left" pn="section-1.3-6.1">
                                  +---------+
               +-------------+    |         |
               |             |    |         |
             / |    PE1      |----|         |   +-------------+
            /  |             |    |  MPLS/  |   |             |---CE3
           /   +-------------+    |  VxLAN/ |   |     PE3     |
      CE1 -                       |  Cloud  |   |             |
           \   +-------------+    |         |---|             |
            \  |             |    |         |   +-------------+
             \ |     PE2     |----|         |
               |             |    |         |
               +-------------+    |         |
                                  +---------+</artwork>
        </figure>
        <t indent="0" pn="section-1.3-7">In <xref target="topology" format="default" sectionFormat="of" derivedContent="Figure 1"/>, when PE2 is inserted in the Ethernet Segment or its
        CE1-facing interface is recovered, PE1 will transfer
        the DF role of some VLANs to PE2 to achieve load-balancing. However,
        because there is no handshake mechanism between PE1 and PE2,
        overlapping of DF roles for a given VLAN is possible, which leads to duplication of
        traffic as well as Layer 2 loops.</t>
        <t indent="0" pn="section-1.3-8">Current EVPN specifications <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/> and <xref target="RFC8584" format="default" sectionFormat="of" derivedContent="RFC8584"/>
        rely on a timer-based approach for transferring the DF role to the newly inserted device.
        This can cause the following issues:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-1.3-9">
          <li pn="section-1.3-9.1">Loops and duplicates, if the timer value is too short</li>
          <li pn="section-1.3-9.2">Prolonged traffic loss, if the timer value is too long</li>
        </ul>
      </section>
      <section anchor="advantages" numbered="true" removeInRFC="false" toc="include" pn="section-1.4">
        <name slugifiedName="name-design-principles-for-a-sol">Design Principles for a Solution</name>
        <t indent="0" pn="section-1.4-1">The clock-synchronization solution for fast DF recovery presented in this document
        follows several design principles and offers
        multiple advantages, namely:
        </t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-1.4-2">
          <li pn="section-1.4-2.1">Complex handshake signaling mechanisms and state machines are
            avoided in favor of a simple unidirectional signaling approach.</li>
          <li pn="section-1.4-2.2">The fast DF recovery solution maintains backwards compatibility (see <xref target="ntpcompat" format="default" sectionFormat="of" derivedContent="Section 4"/>) by ensuring that PEs reject any unrecognized new BGP EVPN Extended Community.</li>
          <li pn="section-1.4-2.3">Existing DF Election algorithms remain supported.</li>
          <li pn="section-1.4-2.4">The fast DF recovery solution is independent of any BGP delays in propagation of Ethernet Segment
          routes (Route Type 4)</li>
          <li pn="section-1.4-2.5">The fast DF recovery solution is agnostic of the actual time synchronization mechanism
          used; however, an NTP-based representation of time is used for EVPN signaling.</li>
        </ul>
        <t indent="0" pn="section-1.4-3">The solution in this document relies on nodes in the topology, more specifically
        the peering nodes of each Ethernet-Segment, to be clock-synchronized and to advertise the Time
        Synchronization capability.
        When this is not the case, or when clocks are badly desynchronized, network convergence and DF
        Election is no worse than that described in <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/> due to the timestamp range checking (<xref target="timestamp_verification" format="default" sectionFormat="of" derivedContent="Section 2.2"/>).
        </t>
      </section>
    </section>
    <section anchor="sync" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-df-election-synchronization">DF Election Synchronization Solution</name>
      <t indent="0" pn="section-2-1">The fast DF recovery solution relies on the concept of common clock alignment between partner PEs participating
      in a common Ethernet Segment, i.e., PE1 and PE2 in <xref target="topology" format="default" sectionFormat="of" derivedContent="Figure 1"/>. The main idea is to have all peering PEs of that
      Ethernet Segment perform DF election and apply the result at the same previously announced time. </t>
      <t indent="0" pn="section-2-2">The DF Election procedure, as described in <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/> and as optionally
      signaled in <xref target="RFC8584" format="default" sectionFormat="of" derivedContent="RFC8584"/>, is applied.
      All PEs attached to a given Ethernet Segment are clock-synchronized
      using a networking protocol for clock synchronization (e.g., NTP, Precision Time Protocol (PTP)).
      Whenever possible, recovery activities for failed PEs <bcp14>SHOULD NOT</bcp14> be initiated until after the
      underlying clock synchronization protocol has converged to benefit from this document's fast DF recovery
      procedures.  
      When a new PE is inserted in an Ethernet Segment or when a failed PE of the Ethernet
      Segment recovers, that PE communicates to peering partners the current time plus the value of
      the timer for partner discovery from step 2 in <xref target="RFC7432" section="8.5" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc7432#section-8.5" derivedContent="RFC7432"/>.
      This constitutes an "end time" or "absolute time" as seen from the local PE.
      That absolute time is called the Service Carving Time (SCT).</t>
      <t indent="0" pn="section-2-3">A new BGP EVPN Extended Community, the Service Carving Time, is advertised along with
      the Ethernet Segment Route Type 4 (RT-4) and communicates the SCT to other
      partners to ensure an orderly transfer of forwarding duties.</t>
      <t indent="0" pn="section-2-4">Upon receipt of the new BGP EVPN Extended Community, partner PEs can determine the SCT
      of the newly inserted PE. To eliminate any potential for duplicate traffic or loops, the
      concept of "skew" is introduced: a small time offset to ensure a controlled and orderly
      transition when multiple PE devices are involved.

      The previously inserted PE(s) must perform service carving first for NDF to DF transitions.
      The receiving PEs subtract this skew (default = 10 ms) to the Service Carving Time and apply NDF
      to DF transitions first. This is followed shortly by the NDF to DF transitions on both PEs, after the skew delay.
      On the recovering PE, all services are already in NDF state, and no
      skew for DF to NDF transitions is required.</t>
      <t indent="0" pn="section-2-5">This document proposes a default skew value of 10 ms to allow completion of programming the DF
      to NDF transitions, but implementations may make the skew larger (or configurable) taking
      into consideration scale, hardware capabilities, and clock accuracy.</t>
      <t indent="0" pn="section-2-6">To summarize, all peering PEs perform service carving almost
      simultaneously at the time announced by the newly added/recovered
      PE. The newly inserted PE initiates the SCT and triggers service carving
      immediately on its local timer expiry. The previously inserted PE(s)
      receiving Ethernet Segment route (RT-4) with an SCT BGP extended
      community perform service carving shortly before the SCT for DF to NDF
      transitions and at the SCT for NDF to DF transitions.</t>
      <section anchor="ntpencoding" numbered="true" removeInRFC="false" toc="include" pn="section-2.1">
        <name slugifiedName="name-bgp-encoding">BGP Encoding</name>
        <t indent="0" pn="section-2.1-1">A BGP extended community, with Type 0x06 and Sub-Type 0x0F, is defined to communicate the
        SCT for each Ethernet Segment:</t>
        <figure align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-service-carving-time">Service Carving Time</name>
          <artwork align="left" pn="section-2.1-2.1">
                     1                   2                   3
 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(0x0F)|      Timestamp Seconds        ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~  Timestamp Seconds            |      Timestamp Fraction       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
        </figure>
        <t indent="0" pn="section-2.1-3">The timestamp exchanged uses the NTP prime epoch of 0 h 1 January 
   1900 UTC <xref target="RFC5905" format="default" sectionFormat="of" derivedContent="RFC5905"/> and an adapted form of the 64-bit NTP timestamp format.</t>
        <t indent="0" pn="section-2.1-4">The 64-bit NTP timestamp format consists of a 32-bit unsigned seconds
   field and a 32-bit fraction field, which are encoded in the
        Service Carving Time as follows:</t>
        <dl spacing="normal" newline="false" indent="3" pn="section-2.1-5">
          <dt pn="section-2.1-5.1">Timestamp Seconds:</dt>
          <dd pn="section-2.1-5.2">32-bit NTP seconds are encoded in this field.</dd>
          <dt pn="section-2.1-5.3">Timestamp Fraction:</dt>
          <dd pn="section-2.1-5.4">The high-order 16 bits of
          the NTP "Fraction" field are encoded in this field.</dd>
        </dl>
        <t indent="0" pn="section-2.1-6">When rebuilding a 64-bit NTP timestamp format using the values from a received SCT BGP extended community, the lower-order 16 bits of the
        NTP "Fraction" field are set to 0. The use of a 16-bit fractional seconds value yields adequate precision of 15 microseconds
        (2<sup>-16</sup> s).</t>
        <t indent="0" pn="section-2.1-7">The format of the DF Election Extended Community that is used in this document is:</t>
        <figure align="left" suppress-title="false" pn="figure-3">
          <name slugifiedName="name-df-election-extended-commun">DF Election Extended Community (RFC 8584)</name>
          <artwork align="left" pn="section-2.1-8.1">
                     1                   2                   3
 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                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
        </figure>
        <t indent="0" pn="section-2.1-9">The Bitmap field (2 octets) encodes "capabilities" <xref target="RFC8584" format="default" sectionFormat="of" derivedContent="RFC8584"/>, where this
        document introduces a new Time Synchronization capability indicated by "T".</t>
        <figure align="left" suppress-title="false" pn="figure-4">
          <name slugifiedName="name-bitmap-field-in-the-df-elec">Bitmap Field in the DF Election Extended Community</name>
          <artwork align="left" pn="section-2.1-10.1">
                     1         1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |A| |T|                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
        </figure>
        <dl spacing="normal" newline="false" indent="3" pn="section-2.1-11">
          <dt pn="section-2.1-11.1">Bit 3:</dt>
          <dd pn="section-2.1-11.2">Time Synchronization (corresponds to Bit 27 of
          the DF Election Extended Community). When set to 1, it indicates the
          desire to use the Time Synchronization capability with the rest of the
          PEs in the Ethernet Segment.</dd>
        </dl>
        <t indent="0" pn="section-2.1-12">
        This capability is utilized in conjunction with the agreed-upon DF Election Type.
        For instance, if all the PE devices in the Ethernet Segment indicate the desire to use the
        Time Synchronization capability and request the DF Election Type to be the HRW,
        then the HRW algorithm is used in conjunction with this capability. A PE that does not
        support the procedures set out in this document or that receives a route from another PE in
        which the capability is not set <bcp14>MUST NOT</bcp14> delay DF election as this could
        lead to duplicate traffic in some instances (overlapping DFs).</t>
      </section>
      <section anchor="timestamp_verification" numbered="true" removeInRFC="false" toc="include" pn="section-2.2">
        <name slugifiedName="name-timestamp-verification">Timestamp Verification</name>
        <t indent="0" pn="section-2.2-1">The NTP Era value is not exchanged, and participating PEs may consider the timestamps to be in the same Era as their local value.
        A DF Election operation occurring exactly at the next Era transition will be some time on
        February 7, 2036. Implementors and operators may address credible
        cases of rollover ambiguity (adjacent Eras n and n+1) as well as the security issue of unreasonably
        large or unreasonably small NTP timestamps in the following manner.</t>
        <t indent="0" pn="section-2.2-2">The procedures in this document address implicitly what occurs with receiving an SCT value
        in the past. This would be a naturally occurring event with a large BGP propagation delay:
        the receiving PE treats
        the DF Election at the peer as having already occurred and proceeds without starting any
        timer to further delay service carving, effectively falling back on behavior as specified in <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/>.
        A PE that receives an SCT value smaller than its current time <bcp14>MUST</bcp14> discard the Service Carving Time and <bcp14>SHALL</bcp14> treat the DF Election at
   the peer as having occurred already.</t>
        <t indent="0" pn="section-2.2-3">The more problematic scenario is the PE in Era n+1 that receives an SCT advertised by
        the PE still in Era n, with a very large SCT value. To address this Era rollover as well as
        the large values attack vector, implementations <bcp14>MUST</bcp14> validate the received SCT against
        an upper bound.</t>
        <t indent="0" pn="section-2.2-4">It is left to implementations to decide what constitutes an "unreasonably large" SCT value.
        A recommended approach, however, is to compare the received offset to the local peering timer value.
        In practice, peering timer values are configured uniformly across Ethernet Segment peers and
        may be treated as an upper bound on the offset of received SCT values.
        A PE that receives an SCT representing an offset larger than the local peering timer <bcp14>MUST</bcp14>
        discard the SCT and <bcp14>SHALL</bcp14> treat
        the DF Election at the peer as having already occurred, as above.</t>
      </section>
      <section anchor="fsm_8584" numbered="true" removeInRFC="false" toc="include" pn="section-2.3">
        <name slugifiedName="name-updates-to-rfc-8584">Updates to RFC 8584</name>
        <t indent="0" pn="section-2.3-1">This document introduces an additional delay to the events and
        transitions defined for the default DF election algorithm FSM in
        <xref target="RFC8584" section="2.1" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8584#section-2.1" derivedContent="RFC8584"/> without changing the FSM state or event definitions
        themselves.</t>
        <t indent="0" pn="section-2.3-2">Upon receiving an RCVD_ES message, the peering PE's FSM transitions
        from the DF_DONE state (indicating the DF election process was complete) to the DF_CALC state
        (indicating that a new DF calculation is needed). Due to the 
        SCT included in the Ethernet Segment update, the completion of the DF_CALC state and the
        subsequent transition back to the DF_DONE state are delayed. This delay ensures proper
        synchronization and prevents conflicts. Consequently, the accompanying forwarding updates to
        the DF and NDF states are also deferred.</t>
        <t indent="0" pn="section-2.3-3">Item 9 in <xref target="RFC8584" section="2.1" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8584#section-2.1" derivedContent="RFC8584"/>, in the list "Corresponding actions when transitions
are performed or states are entered/exited", is changed as follows:</t>
        <blockquote pn="section-2.3-4">
          <ol start="9" spacing="normal" indent="adaptive" type="1" pn="section-2.3-4.1">
          <li pn="section-2.3-4.1.1" derivedCounter="9.">
              <t indent="0" pn="section-2.3-4.1.1.1">DF_CALC on CALCULATED: Mark the election result for the VLAN
          or VLAN bundle.</t>
              <ol type="9.%d" spacing="normal" indent="adaptive" start="1" pn="section-2.3-4.1.1.2">
            <li pn="section-2.3-4.1.1.2.1" derivedCounter="9.1">If no Service Carving Time is present during the RCVD_ES event of Action 11,
            proceed to step 9.4</li>
                <li pn="section-2.3-4.1.1.2.2" derivedCounter="9.2">If a Service Carving Time is present during the RCVD_ES event of
            Action 11, wait until the time indicated by the SCT minus skew before proceeding to step
            9.3.</li>
                <li pn="section-2.3-4.1.1.2.3" derivedCounter="9.3">Assume the role of NDF for the local PE concerning the VLAN or VLAN bundle.
            Wait the remaining skew time before proceeding to step 9.4.</li>
                <li pn="section-2.3-4.1.1.2.4" derivedCounter="9.4">Assume the election result's role (DF or NDF) for the local PE concerning the VLAN or
            VLAN bundle and transition to the DF_DONE state.</li>
              </ol>
            </li>
          </ol>
        </blockquote>
        <t indent="0" pn="section-2.3-5">This revised approach ensures proper timing and synchronization in the DF election
        process, avoiding conflicts and ensuring accurate forwarding updates.</t>
      </section>
    </section>
    <section anchor="example" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-synchronization-scenarios">Synchronization Scenarios</name>
      <t indent="0" pn="section-3-1">Consider <xref target="topology" format="default" sectionFormat="of" derivedContent="Figure 1"/> as an example, where initially PE2
      has failed and PE1 has taken over.  This scenario illustrates the
      problem with the DF Election mechanism described in <xref target="RFC7432" section="8.5" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc7432#section-8.5" derivedContent="RFC7432"/>, specifically in the context of the
      timer value configured for all PEs on the Ethernet Segment.</t>
      <t indent="0" pn="section-3-2">The following procedure is based on <xref target="RFC7432" section="8.5" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc7432#section-8.5" derivedContent="RFC7432"/> with the default 3-second timer in step 2.  </t>
      <ol spacing="normal" indent="adaptive" start="1" type="1" pn="section-3-3">
        <li pn="section-3-3.1" derivedCounter="1.">Initial state: PE1 is in a steady-state and PE2 is recovering.</li>
        <li pn="section-3-3.2" derivedCounter="2.">Recovery: PE2 recovers at an absolute time of t=99.</li>
        <li pn="section-3-3.3" derivedCounter="3.">Advertisement: PE2 advertises RT-4, sent at t=100, to its partner (PE1).</li>
        <li pn="section-3-3.4" derivedCounter="4.">Timer Start: PE2 starts a 3-second timer to allow the reception of
        RT-4 from other PE nodes.</li>
        <li pn="section-3-3.5" derivedCounter="5.">Immediate carving: PE1 performs service carving immediately upon
        RT-4 reception, i.e., t=100 plus some BGP propagation delay.</li>
        <li pn="section-3-3.6" derivedCounter="6.">Delayed Carving: PE2 performs service carving at time t=103.</li>
      </ol>
      <t indent="0" pn="section-3-4"><xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/> favors traffic drops over duplicate traffic.
      With the above procedure, traffic drops will occur as part of each PE
      recovery sequence since PE1 transitions some VLANs to
      an NDF immediately upon RT-4 reception. The timer value
      (default = 3 seconds) directly affects the duration of the packet
      drops. A shorter (or zero) timer may result in duplicate traffic or
      traffic loops.</t>
      <t indent="0" pn="section-3-5">The following procedure is based on the SCT approach:
      </t>
      <ol spacing="normal" indent="adaptive" start="1" type="1" pn="section-3-6">
        <li pn="section-3-6.1" derivedCounter="1.">Initial state: PE1 is in a steady state, and PE2 is recovering.</li>
        <li pn="section-3-6.2" derivedCounter="2.">Recovery: PE2 recovers at an absolute time of t=99.</li>
        <li pn="section-3-6.3" derivedCounter="3.">Timer Start: PE2 starts at t=100 a 3-second timer to allow the reception of RT-4 from other PE
          nodes.</li>
        <li pn="section-3-6.4" derivedCounter="4.">Advertisement: PE2 advertises RT-4, sent at t=100, with a target SCT value of t=103 to
          its partner (PE1).</li>
        <li pn="section-3-6.5" derivedCounter="5.">Service Carving Timer: PE1 starts the service carving timer, with the remaining time
          until t=103.</li>
        <li pn="section-3-6.6" derivedCounter="6.">Simultaneous Carving: Both PE1 and PE2 carve at an absolute time of t=103.</li>
      </ol>
      <t indent="0" pn="section-3-7">
        To maintain the preference for minimal loss over duplicate traffic, PE1 <bcp14>SHOULD</bcp14> carve
        slightly before PE2 (with skew). The recovering PE2 performs both DF-to-NDF and NDF-to-DF
        transitions per VLAN at the timer's expiry. The original PE1, which received the SCT, applies the following:
      </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-8">
        <li pn="section-3-8.1">DF-to-NDF Transition(s): at t=SCT minus skew, where both PEs are NDF for the skew duration.</li>
        <li pn="section-3-8.2">NDF-to-DF Transition(s): at t=SCT.</li>
      </ul>
      <t indent="0" pn="section-3-9">
        This split behavior ensures a smooth DF role transition with minimal loss.
      </t>
      <t indent="0" pn="section-3-10">The SCT approach mitigates the negative effect of requiring a timer for discovery of
      Ethernet Segment (ES) RT-4 from other PE nodes. Furthermore, the BGP
        transmission delay (from PE2 to PE1) of the ES RT-4 becomes a non-issue. The SCT approach shortens the
        3-second timer window to the order of milliseconds.</t>
      <t indent="0" pn="section-3-11">The peering timer is a configurable value where 3 seconds represents the default.
        Configuring a timer value of 0, or so small as to expire during propagation of the BGP
        routes, is outside the scope of this document.
        In reality, the use of the SCT approach presented in this document encourages the use of
        larger peering timer values to overcome any sort of BGP route propagation delays.</t>
      <section anchor="concurrent" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-concurrent-recoveries">Concurrent Recoveries</name>
        <t indent="0" pn="section-3.1-1">In the eventuality that two or more PEs in a peering Ethernet Segment group are recovering
        concurrently or roughly at the same time, each will advertise a SCT.
        This SCT value would correspond to what each recovering PE considers the "end time" for DF
        Election. A similar situation arises in sequentially recovering PEs, when a second PE
        recovers approximately at the time of the first PE's advertised SCT expiry and with its own
        new SCT-2 outside of the initial SCT window.</t>
        <t indent="0" pn="section-3.1-2">In the case of multiple concurrent DF elections, each initiated by one of the recovering
        PEs, the SCTs must be ordered chronologically. All PEs <bcp14>SHALL</bcp14> execute only a single DF
        Election at the service carving time corresponding to the largest (latest) received timestamp value.
        This DF Election will lead peering PEs into a single coordinated DF Election update.</t>
        <t indent="0" pn="section-3.1-3">Example:
        </t>
        <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-3.1-4">
          <li pn="section-3.1-4.1" derivedCounter="1.">Initial State: PE1 is in a steady state, with services elected at PE1.</li>
          <li pn="section-3.1-4.2" derivedCounter="2.">Recovery of PE2: PE2 recovers at time t=100 and advertises RT-4 with a target SCT
          value of t=103 to its partner (PE1).</li>
          <li pn="section-3.1-4.3" derivedCounter="3.">Timer Initiation by PE2: PE2 starts a 3-second timer to allow the reception of RT-4
          from other PE nodes.</li>
          <li pn="section-3.1-4.4" derivedCounter="4.">Timer Initiation by PE1: PE1 starts the service carving timer, with the remaining time
          until t=103.</li>
          <li pn="section-3.1-4.5" derivedCounter="5.">Recovery of PE3: PE3 recovers at time t=102 and advertises RT-4 with a target SCT
          value of t=105 to its partners (PE1, PE2).</li>
          <li pn="section-3.1-4.6" derivedCounter="6.">Timer Initiation by PE3: PE3 starts a 3-second timer to allow the reception of RT-4
          from other PE nodes.</li>
          <li pn="section-3.1-4.7" derivedCounter="7.">Timer Update by PE2: PE2 cancels the running timer and starts the service carving
          timer with the remaining time until t=105.</li>
          <li pn="section-3.1-4.8" derivedCounter="8.">Timer Update by PE1: PE1 updates its service carving timer, with the remaining time
          until t=105.</li>
          <li pn="section-3.1-4.9" derivedCounter="9.">Service Carving: PE1, PE2, and PE3 perform service carving at the absolute time of t=105.</li>
        </ol>
        <t indent="0" pn="section-3.1-5">In the eventuality that a PE in an Ethernet Segment group recovers during the discovery window
        specified in <xref target="RFC7432" section="8.5" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc7432#section-8.5" derivedContent="RFC7432"/> and does not support or advertise the
        T-bit, all PEs in the current peering sequence <bcp14>SHALL</bcp14> immediately revert to the default
        behavior described in <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/>.</t>
      </section>
    </section>
    <section anchor="ntpcompat" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-backwards-compatibility">Backwards Compatibility</name>
      <t indent="0" pn="section-4-1">For the DF election procedures to achieve global convergence and unanimity within a
          redundancy group, it is essential that all participating PEs agree on the DF election
          algorithm to be employed. However, it is possible that some PEs may continue to use the
          existing modulo-based DF election algorithm from <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/> and not utilize the new 
          SCT BGP extended community. PEs that operate using the baseline DF election mechanism
          will simply discard the new SCT BGP extended community as unrecognized.</t>
      <t indent="0" pn="section-4-2">A PE can indicate its willingness to support clock-synchronized carving by signaling
          the new "T" DF Election Capability and including the new SCT BGP extended community along
          with the Ethernet Segment Route Type 4. If one or more PEs attached to the Ethernet
          Segment do not signal T=1, then all PEs in the Ethernet Segment <bcp14>SHALL</bcp14> revert to the
          timer-based approach as specified in <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/>. This reversion is particularly crucial in
          preventing VLAN shuffling when more than two PEs are involved.</t>
      <t indent="0" pn="section-4-3">In the event a new or extra RT-4 is received without the new "T" DF Election
          Capability in the midst of an ongoing DF Election sequence, all SCT-based delays are
          canceled, and the DF Election is immediately applied as specified in <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/>, as if no SCT had been previously exchanged.</t>
    </section>
    <section anchor="security" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">The mechanisms in this document use the EVPN control plane as defined
      in <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/>. Security considerations described in <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/> are equally applicable.</t>
      <t indent="0" pn="section-5-2">For the new SCT Extended Community, attack vectors may be setting the
      value to zero, to a value in the past, or to large times in the
      future. Handling of this attack vector is addressed in <xref target="timestamp_verification" format="default" sectionFormat="of" derivedContent="Section 2.2"/> alongside NTP Era rollover
      ambiguity.</t>
      <t indent="0" pn="section-5-3">This document uses MPLS- and IP-based tunnel technologies to support
      data plane transport.  Security considerations described in <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/> and <xref target="RFC8365" format="default" sectionFormat="of" derivedContent="RFC8365"/> are equally
      applicable.</t>
    </section>
    <section anchor="IANA" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-6-1">IANA has made the following assignment in the "EVPN Extended
      Community Sub-Types" registry set up by <xref target="RFC7153" format="default" sectionFormat="of" derivedContent="RFC7153"/>.
      </t>
      <table align="center" pn="table-1">
        <name/>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Sub-Type Value</th>
            <th align="left" colspan="1" rowspan="1">Name</th>
            <th align="left" colspan="1" rowspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">0x0F</td>
            <td align="left" colspan="1" rowspan="1">Service Carving Time</td>
            <td align="left" colspan="1" rowspan="1">RFC 9722</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-6-3">IANA has made the following assignment in the "DF Election
      Capabilities" registry set up by <xref target="RFC8584" format="default" sectionFormat="of" derivedContent="RFC8584"/>.</t>
      <table align="center" pn="table-2">
        <name/>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Bit</th>
            <th align="left" colspan="1" rowspan="1">Name</th>
            <th align="left" colspan="1" rowspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">3</td>
            <td align="left" colspan="1" rowspan="1">Time Synchronization</td>
            <td align="left" colspan="1" rowspan="1">RFC 9722</td>
          </tr>
        </tbody>
      </table>
    </section>
  </middle>
  <back>
    <references pn="section-7">
      <name slugifiedName="name-references">References</name>
      <references pn="section-7.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC5905" target="https://www.rfc-editor.org/info/rfc5905" quoteTitle="true" derivedAnchor="RFC5905">
          <front>
            <title>Network Time Protocol Version 4: Protocol and Algorithms Specification</title>
            <author fullname="D. Mills" initials="D." surname="Mills"/>
            <author fullname="J. Martin" initials="J." role="editor" surname="Martin"/>
            <author fullname="J. Burbank" initials="J." surname="Burbank"/>
            <author fullname="W. Kasch" initials="W." surname="Kasch"/>
            <date month="June" year="2010"/>
            <abstract>
              <t indent="0">The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5905"/>
          <seriesInfo name="DOI" value="10.17487/RFC5905"/>
        </reference>
        <reference anchor="RFC7153" target="https://www.rfc-editor.org/info/rfc7153" quoteTitle="true" derivedAnchor="RFC7153">
          <front>
            <title>IANA Registries for BGP Extended Communities</title>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <date month="March" year="2014"/>
            <abstract>
              <t indent="0">This document reorganizes the IANA registries for the type values and sub-type values of the BGP Extended Communities attribute and the BGP IPv6-Address-Specific Extended Communities attribute. This is done in order to remove interdependencies among the registries, thus making it easier for IANA to determine which codepoints are available for assignment in which registries. This document also clarifies the information that must be provided to IANA when requesting an allocation from one or more of these registries. These changes are compatible with the existing allocations and thus do not affect protocol implementations. The changes will, however, impact the "IANA Considerations" sections of future protocol specifications. This document updates RFC 4360 and RFC 5701.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7153"/>
          <seriesInfo name="DOI" value="10.17487/RFC7153"/>
        </reference>
        <reference anchor="RFC7432" target="https://www.rfc-editor.org/info/rfc7432" quoteTitle="true" derivedAnchor="RFC7432">
          <front>
            <title>BGP MPLS-Based Ethernet VPN</title>
            <author fullname="A. Sajassi" initials="A." role="editor" surname="Sajassi"/>
            <author fullname="R. Aggarwal" initials="R." surname="Aggarwal"/>
            <author fullname="N. Bitar" initials="N." surname="Bitar"/>
            <author fullname="A. Isaac" initials="A." surname="Isaac"/>
            <author fullname="J. Uttaro" initials="J." surname="Uttaro"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <date month="February" year="2015"/>
            <abstract>
              <t indent="0">This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)".</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7432"/>
          <seriesInfo name="DOI" value="10.17487/RFC7432"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8365" target="https://www.rfc-editor.org/info/rfc8365" quoteTitle="true" derivedAnchor="RFC8365">
          <front>
            <title>A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)</title>
            <author fullname="A. Sajassi" initials="A." role="editor" surname="Sajassi"/>
            <author fullname="J. Drake" initials="J." role="editor" surname="Drake"/>
            <author fullname="N. Bitar" initials="N." surname="Bitar"/>
            <author fullname="R. Shekhar" initials="R." surname="Shekhar"/>
            <author fullname="J. Uttaro" initials="J." surname="Uttaro"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <date month="March" year="2018"/>
            <abstract>
              <t indent="0">This document specifies how Ethernet VPN (EVPN) can be used as a Network Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on the EVPN control plane and procedures. In particular, the following encapsulation options are analyzed: Virtual Extensible LAN (VXLAN), Network Virtualization using Generic Routing Encapsulation (NVGRE), and MPLS over GRE. This specification is also applicable to Generic Network Virtualization Encapsulation (GENEVE); however, some incremental work is required, which will be covered in a separate document. This document also specifies new multihoming procedures for split-horizon filtering and mass withdrawal. It also specifies EVPN route constructions for VXLAN/NVGRE encapsulations and Autonomous System Border Router (ASBR) procedures for multihoming of Network Virtualization Edge (NVE) devices.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8365"/>
          <seriesInfo name="DOI" value="10.17487/RFC8365"/>
        </reference>
        <reference anchor="RFC8584" target="https://www.rfc-editor.org/info/rfc8584" quoteTitle="true" derivedAnchor="RFC8584">
          <front>
            <title>Framework for Ethernet VPN Designated Forwarder Election Extensibility</title>
            <author fullname="J. Rabadan" initials="J." role="editor" surname="Rabadan"/>
            <author fullname="S. Mohanty" initials="S." role="editor" surname="Mohanty"/>
            <author fullname="A. Sajassi" initials="A." surname="Sajassi"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="K. Nagaraj" initials="K." surname="Nagaraj"/>
            <author fullname="S. Sathappan" initials="S." surname="Sathappan"/>
            <date month="April" year="2019"/>
            <abstract>
              <t indent="0">An alternative to the default Designated Forwarder (DF) selection algorithm in Ethernet VPNs (EVPNs) is defined. The DF is the Provider Edge (PE) router responsible for sending Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a multihomed Customer Edge (CE) device on a given VLAN on a particular Ethernet Segment (ES). In addition, the ability to influence the DF election result for a VLAN based on the state of the associated Attachment Circuit (AC) is specified. This document clarifies the DF election Finite State Machine in EVPN services. Therefore, it updates the EVPN specification (RFC 7432).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8584"/>
          <seriesInfo name="DOI" value="10.17487/RFC8584"/>
        </reference>
      </references>
      <references pn="section-7.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="HRW98" target="https://www.microsoft.com/en-us/research/wp-content/uploads/2017/02/HRW98.pdf" quoteTitle="true" derivedAnchor="HRW98">
          <front>
            <title>Using Name-Based Mappings to Increase Hit Rates</title>
            <author initials="D" surname="Thaler">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C" surname="Ravishankar">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="February" year="1998"/>
          </front>
          <refcontent>IEEE/ACM Transactions on Networking, vol. 6, no. 1</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="acknowledgements" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">Authors would like to acknowledge helpful comments and contributions
      of <contact fullname="Satya Mohanty"/> and <contact fullname="Bharath       Vasudevan"/>.  Also thank you to <contact fullname="Anoop Ghanwani"/>
      and <contact fullname="Gunter van de Velde"/> for their thorough review
      with valuable comments and corrections.</t>
    </section>
    <section anchor="contributors" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-contributors">Contributors</name>
      <t indent="0" pn="section-appendix.b-1">In addition to the authors listed on the front page, the following
      coauthors have also contributed substantially to this document:</t>
      <contact fullname="Gaurav Badoni">
        <organization showOnFrontPage="true">Cisco</organization>
        <address>
          <email>gbadoni@cisco.com</email>
        </address>
      </contact>
      <contact fullname="Dhananjaya Rao">
        <organization showOnFrontPage="true">Cisco</organization>
        <address>
          <email>dhrao@cisco.com</email>
        </address>
      </contact>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Patrice Brissette" initials="P." surname="Brissette">
        <organization showOnFrontPage="true">Cisco</organization>
        <address>
          <email>pbrisset@cisco.com</email>
        </address>
      </author>
      <author fullname="Ali Sajassi" initials="A." surname="Sajassi">
        <organization showOnFrontPage="true">Cisco</organization>
        <address>
          <email>sajassi@cisco.com</email>
        </address>
      </author>
      <author fullname="Luc André Burdet" initials="LA." surname="Burdet" role="editor">
        <organization showOnFrontPage="true">Cisco</organization>
        <address>
          <email>lburdet@cisco.com</email>
        </address>
      </author>
      <author fullname="John Drake" initials="J." surname="Drake">
        <organization showOnFrontPage="true">Independent</organization>
        <address>
          <email>je_drake@yahoo.com</email>
        </address>
      </author>
      <author fullname="Jorge Rabadan" initials="J." surname="Rabadan">
        <organization showOnFrontPage="true">Nokia</organization>
        <address>
          <email>jorge.rabadan@nokia.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
