<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type='text/xsl' href='rfc7749.xslt' ?> <!-- used by XSLT processors --> <!-- For a complete list and description of processing instructions (PIs), please see http://xml.resource.org/authoring/README.html. --> <!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use. (Here they are set differently than their defaults in xml2rfc v1.32) --> <?rfc strict="yes" ?> <!-- give errors regarding ID-nits and DTD validation --> <!-- control vertical white space (using these PIs as follows is recommended by the RFC Editor) --> <?rfc compact="yes" ?> <!-- do not start each main section on a new page --> <?rfc subcompact="no" ?> <!-- keep one blank line between list items --> <!-- end of list of popular I-D processing instructions --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-bess-evpn-mh-pa-13" number="9786" consensus="true" submissionType="IETF" ipr="trust200902" tocInclude="true" tocDepth="4" symRefs="true"sortRefs="true"> <!-- ***** FRONT MATTER ***** -->sortRefs="true" version="3" xml:lang="en" obsoletes="" updates=""> <front><!-- The abbreviated title is used in the page header - it is only necessary if the full title is longer than 39 characters --><title abbrev="EVPN Port-Active Redundancy Mode">EVPN Port-Active Redundancy Mode</title> <seriesInfoname="Internet-Draft" value="draft-ietf-bess-evpn-mh-pa-13"/>name="RFC" value="9786"/> <author fullname="Patrice Brissette" initials="P." surname="Brissette"> <organization>Cisco Systems</organization> <address> <postal><street/><city>Ottawa</city> <region>ON</region> <country>Canada</country> </postal><phone/><email>pbrisset@cisco.com</email> </address> </author> <author fullname="LucAndreAndré Burdet" initials="LA."role="editor" surname="Burdet">surname="Burdet" role="editor"> <organization>Cisco Systems</organization> <address> <postal><street/> <city/> <region/> <code/><country>Canada</country> </postal> <email>lburdet@cisco.com</email> </address> </author> <author fullname="Bin Wen" initials="B." surname="Wen"> <organization>Comcast</organization> <address> <postal><street/> <city/> <region/> <code/> <country>USA</country><country>United States of America</country> </postal> <email>Bin_Wen@comcast.com</email> </address> </author> <author fullname="Edward Leyton" initials="E." surname="Leyton"> <organization>Verizon Wireless</organization> <address> <postal><street/> <city/> <region/> <code/> <country>USA</country><country>United States of America</country> </postal> <email>edward.leyton@verizonwireless.com</email> </address> </author> <author fullname="Jorge Rabadan" initials="J." surname="Rabadan"> <organization>Nokia</organization> <address> <postal><street/> <city/> <region/> <code/> <country>USA</country><country>United States of America</country> </postal> <email>jorge.rabadan@nokia.com</email> </address> </author> <dateyear="2024"/> <!-- Meta-data Declarations --> <area>General</area> <workgroup>BESS Working Group</workgroup>year="2025" month="May"/> <area>RTG</area> <workgroup>bess</workgroup> <keyword>Port-Active</keyword> <keyword>EVPN</keyword> <keyword>Multi-homing</keyword> <abstract> <t>The Multi-Chassis Link AggregationGroup(MC-LAG) group technology enables establishing a logical link-aggregation connection with a redundant group of independent nodes. The objective of MC-LAG is to enhance both network availability and bandwidth utilization through various modes of trafficload-balancing. RFC7432load balancing. RFC 7432 defines an EVPN-based MC-LAG withSingle-activeSingle-Active andAll-activeAll-Active multi-homing redundancy modes. This document builds on the existing redundancy mechanisms supported by EVPN and introduces a new active/standby redundancy mode, called 'Port-Active'.</t> </abstract> </front> <middle><section title="Introduction"><section> <name>Introduction</name> <t>EVPN <xref target="RFC7432"/> defines the All-Active and Single-Active redundancy modes. All-Active redundancy provides per-flowload-balancingload balancing for multi-homing, while Single-Active redundancy ensures service carving where only one of the Provider Edge (PE) devices in a redundancy relationship is active per service.</t> <t>Although these two multi-homing scenarios are widely utilized in data center and service provider access networks, there are cases where active/standby multi-homing at the interface level is beneficial and necessary. The primary consideration for this new mode ofload-balancingload balancing is the determinism of traffic forwarding through a specificinterface,interface rather than statistical per-flowload-balancingload balancing across multiple PEs providing multi-homing. This determinism is essential for certain QoS features to function correctly. Additionally, this mode ensures fast convergence during failure and recovery, which is expected by customers.</t> <t>This document defines the Port-Active redundancy mode as a new type of multi-homing in EVPN and details how this mode operates and is supported via EVPN.</t> <section anchor="requirements"><!-- anchor is an optional attribute --><name>Requirements Language</name><t>The<t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> <section> <name>Multi-Chassis Link Aggregation (MC-LAG)</name> <t>When aCECustomer Equipment (CE) device is multi-homed to a set of PE nodes using the<xref target="IEEE_802.1AX_2014"/>Link Aggregation Control Protocol(LACP),(LACP) <xref target="IEEE_802.1AX_2014"/>, the PEs must function as a single LACP entity for the Ethernet links to form and operate as a Link Aggregation Group (LAG). To achieve this, the PEs connected to the same multi-homed CE must synchronize LACP configuration and operational data among them. Historically, theInterchassisInter-Chassis Communication Protocol (ICCP) <xref target="RFC7275"/> has been used for this synchronization. EVPN, as described in <xref target="RFC7432"/>, covers the scenario where a CE is multi-homed to multiple PE nodes, using a LAG to simplify the procedure significantly.This simplification, however,However, this simplification comes with certain assumptions:</t> <ul spacing="normal"><li>a<li>A CE device connected to EVPNmulti‑homingmulti-homing PEsMUST<bcp14>MUST</bcp14> have a single LAG with all its links connected to the EVPN multi-homing PEs in a redundancy group.</li><li>identical<li>Identical LACP parametersMUST<bcp14>MUST</bcp14> be configured on peering PEs, including the system ID, port priority, and port key.</li> </ul> <t>This document presumes proper LAG operation as specified in <xref target="RFC7432"/>. Issues resulting from deviations in the aforementioned assumptions, LAG misconfiguration, and miswiring detection across peering PEs are considered outside the scope of this document. </t> <figure anchor="Topology"> <name>MC-LAG Topology</name> <artwork align="left"><![CDATA[ +-----+ | PE3 | +-----+ +-----------+ | MPLS/IP | | CORE | +-----------+ +-----+ +-----+ | PE1 | | PE2 | +-----+ +-----+ I1 I2 \ / \ / \ / +---+ |CE1|+---+ ]]></artwork>+---+]]></artwork> </figure></t><t><xref target="Topology"/> showsaan MC-LAGmulti‑homingmulti-homing topology where PE1 and PE2 are part of the same redundancy group providingmulti‑homingmulti-homing to CE1 via interfaces I1 and I2. Interfaces I1 and I2 are members of a LAG running LACP. The core, shown as IP or MPLS enabled, provides a wide range of L2 and L3 services. MC-LAGmulti‑homingmulti-homing functionality is decoupled from those services in thecorecore, and it focuses on providingmulti‑homingmulti-homing to the CE. In Port-Active redundancy mode, only one of the twointerfacesinterfaces, I1 orI2I2, would be inforwardingforwarding, and the other interfacewillwould be in standby. This also implies that all services on the active interfaceareoperate in active mode and all services on the standby interface operate in standby mode.</t> </section> </section> <section> <name>Port-Active Redundancy Mode</name> <section> <name>Overall Advantages</name> <t>The use of Port-Active redundancy in EVPN networks provides the following benefits:</t> <ol spacing="normal" type="a"><li>Port-Active redundancy<li>It offersopen standards-basedopen-standards-based active/standby redundancy at the interfacelevel,level rather than VLAN granularity <xref target="RFC7432"/>.</li><li>Port-Active redundancy<li>It eliminates the need for ICCP and LDP <xreftarget="RFC5306"/>target="RFC5036"/> (e.g.,VXLANVirtual eXtensible Local Area Network (VXLAN) <xref target="RFC7348"/> orSRv6Segment Routing over IPv6 (SRv6) <xref target="RFC8402"/> may be used in the network).</li> <li>This mode is agnostic of the underlying technology (MPLS, VXLAN, and SRv6) and associated services(L2, L3,(Layer 2 (L2), Layer 3 (L3), Bridging, E-LINE, etc.)</li> <li>It enables deterministic QoS over MC-LAG attachment circuits.</li><li>Port-Active redundancy<li>It is fully compliant with <xref target="RFC7432"/> and does not require any new protocol enhancements to existing EVPN RFCs.</li> <li>It can leverage various Designated Forwarder (DF) election algorithms, such as modulo(<xref target="RFC7432"/>),<xref target="RFC7432"/>, Highest Random Weight(HRW,(HRW) <xreftarget="RFC8584"/>),target="RFC8584"/>, etc.</li> <li><t>Port-Active redundancy<t>It replaces legacy MC-LAG ICCP-based solutions and offers the following additional benefits:</t> <ul spacing="normal"> <li>Efficient support for 1+N redundancy mode (with EVPN using BGP Route Reflector), whereas ICCP requires a full mesh of LDP sessions among PEs in the redundancy group.</li> <li>Fast convergence withmass-withdrawmass withdraw is possible with EVPN, which has no equivalent in ICCP.</li> </ul> </li> </ol> </section><section title="Port-Active<section> <name>Port-Active RedundancyProcedures">Procedures</name> <t>The following steps outline the proposed procedure for supporting Port-Active redundancy mode with EVPN LAG:</t> <ol spacing="normal" type="a"> <li>TheEthernet-SegmentEthernet Segment Identifier (ESI)MUST<bcp14>MUST</bcp14> be assigned per access interface as described in <xref target="RFC7432"/>. The ESI can be auto-derived or manuallyassignedassigned, and the access interfaceMAY<bcp14>MAY</bcp14> bea Layer-2an L2 orLayer-3L3 interface.</li> <li>TheEthernet-SegmentEthernet Segment (ES)MUST<bcp14>MUST</bcp14> be configured in Port-Active redundancy mode on peering PEs for the specified access interface.</li> <li>When ESI is configured ona Layer-3an L3 interface, theEthernet-Segment (ES)ES route (Route Type-4) can be the only route exchanged by PEs in the redundancy group.</li> <li>PEs in the redundancy group leverage the DF election defined in <xref target="RFC8584"/> to determine which PE keeps the port in active mode and whichone(s) keepPE(s) keeps it in standby mode. Although the DF election defined in <xref target="RFC8584"/> is per [ES, Ethernet Tag] granularity, the DF election is performed per [ES] in Port-Active redundancy mode. The details of this algorithm are described in <xref target="df_algo"/>.</li> <li>The DF routerMUST<bcp14>MUST</bcp14> keep the corresponding access interface in an up and forwarding active state for thatEthernet-Segment.</li> <li>Non-DFES.</li> <li> <t>Non-DF routersSHOULD<bcp14>SHOULD</bcp14> implement a bidirectional blocking scheme for all traffic comparable to the Single-Activeblocking schemeredundancy mode described in <xref target="RFC7432"/>, albeit across all VLANs. </t> <ul> <li>Non-DF routersMAY<bcp14>MAY</bcp14> bring and keep the peering access interface attached to them in an operational down state.</li> <li>If the interface is running the LACP protocol, the non-DF PEMAY<bcp14>MAY</bcp14> set the LACP state toOOS (OutOut ofSync)Sync (OOS) instead of setting the interface to a down state. This approach allows for better convergence during the transition from standby to active mode.</li> </ul> </li> <li>The primary/backup bits of the EVPN Layer 2 Attributes (L2-Attr) Extended Community <xref target="RFC8214"/>SHOULD<bcp14>SHOULD</bcp14> be used to achieve better convergence, as described in <xref target="es_ead_pb"/>.</li> </ol> </section> </section> <section anchor="df_algo"> <name>Designated Forwarder Algorithm to Elect per Port-Active PE</name> <t>TheEthernet-Segment (ES)ES routes operating in Port-Active redundancy mode are advertised with the new Port Mode Load-Balancing capability bit in the DF Election Extended Community as defined in <xref target="RFC8584"/>. Additionally, the ES associated with the port utilizes the existing Single-Active procedure and signals the Single-ActiveMultihomedmulti-homed site redundancy mode along with theEthernet-ADEthernet A-D per-ES route (refer to<relref<xref target="RFC7432" section="7.5"/>). Finally, The ESI label-basedsplit&nbhy;horizonsplit-horizon procedures specified in<relref<xref target="RFC7432" section="8.3"/>SHOULD<bcp14>SHOULD</bcp14> be employed to prevent transient echo packets whenLayer-2L2 circuits are involved.</t> <t>Various algorithms for DFElectionelection are detailed in Sections <xref target="modulo" format="counter"/> to <xref target="ac_df" format="counter"/> for comprehensive understanding, although the choice of algorithm in this solution does not significantly impact complexity or performance compared to other redundancy modes.</t> <sectionanchor="cap_flag" title="Capability Flag">anchor="cap_flag"> <name>Capability Flag</name> <t> <xref target="RFC8584"/> defines a DF Electionextended community,Extended Community and aBitmapbitmap (2 octets) field to encode "DF Election Capabilities" to use with the DF election algorithm in the DF algorithm field: </t> <dl newline="false" spacing="normal" indent="10"> <dt>Bit 0:</dt> <dd>D bit or 'Don'tPre-empt'Preempt' bit, asexplaineddescribed in <xreftarget="I-D.ietf-bess-evpn-pref-df"/>.</dd>target="RFC9785"/>.</dd> <dt>Bit 1:</dt> <dd>AC-Influenced DF (AC-DF) election, asexplaineddescribed in <xref target="RFC8584"/>.</dd> <dt>Bit 3:</dt> <dd>Time Synchronization, as described in <xref target="RFC9722"/>.</dd> </dl> <figureanchor="Bitmap">anchor="bitmap"> <name>Amended DF Election Capabilities in the DF Election Extended Community</name> <artwork align="left"><![CDATA[ 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D|A| |T| |P| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> </figure> <t>This document defines the following value and extends the DF Election Capabilities bitmap field:</t> <dl newline="false" spacing="normal" indent="10"> <dt>Bit 5:</dt> <dd>Port Mode Designated Forwarder Election. This bit determines that theDF ElectionDF election algorithmSHOULD<bcp14>SHOULD</bcp14> be modified to consider the port ES only and not the Ethernet Tags.</dd> </dl> </section> <sectionanchor="modulo" title="Modulo-based Algorithm">anchor="modulo"> <name>Modulo-Based Algorithm</name> <t>The default DFElectionelection algorithm, or modulo-based algorithm, as described in <xref target="RFC7432"/> and updated by <xref target="RFC8584"/>, is applied here at the granularity of ES only. Given that the ES-Import Route Target extended community may be auto-derived and directly inherits its auto-derived value from ESI bytes 1-6, many operators differentiate ESIs primarily within these bytes. Consequently, bytes 3-6 are utilized to determine the designated forwarder using the modulo-based DF assignment, achieving good entropy during modulo calculation across ESIs.</t> <t>Assuming a redundancy group of N PE nodes, the PE with ordinal i is designated as the DF for an <ES> when (Es mod N) = i, where Es represents bytes 3-6 of that ESI.</t> </section> <sectionanchor="hrw" title="Highestanchor="hrw"> <name>Highest Random WeightAlgorithm">Algorithm</name> <t> An application of Highest Random Weight (HRW) to EVPN DFElectionelection is defined in <xreftarget="RFC8584"/>target="RFC8584"/>, andMAY alsoit <bcp14>MAY</bcp14> be used and signaled. ForPort-ActivePort-Active, this is modified to operate at the granularity of <ES> rather than per <ES, VLAN>.</t><t><relref<t><xref target="RFC8584" section="3.2"/> describes computing a 32-bitCRCCyclic Redundancy Check (CRC) over the concatenation of Ethernet Tag (V) and ESI (Es). For Port-Active redundancy mode, the Ethernet Tag is omitted from the CRC computation and all references to (V, Es) are replaced by (Es).</t> <t>The algorithm used todeteminedetermine the DFElectedandBackup-DF ElectedBackup Designated Forwarder (BDF)at <relrefper <xref target="RFC8584" section="3.2"/> is repeated and summarized below using only (Es) in the computation:</t> <ol> <li>DF(Es) = Si| Weight(Es, Si)>=>= Weight(Es, Sj), for all j. In the case of a tie, choose the PE whose IP address is numerically the least. Note that 0 <= i,j < number of PEs in the redundancy group.</li> <li>BDF(Es) = Sk| Weight(Es, Si) >= Weight(Es, Sk), and Weight(Es, Sk) >= Weight(Es, Sj). In the case of a tie, choose the PE whose IP address is numerically the least.</li> </ol> <t>Where:</t> <ul> <li>DF(Es) is defined to be the address Si (index i) for which Weight(Es, Si) is the highest; 0 <= i < N-1.</li> <li>BDF(Es) is defined as that PE with address Sk for which the computed Weight is the next highest after the Weight of the DF. j is the running index from 0 to N-1; i and k are selected values.</li> </ul> </section> <sectionanchor="pref_df" title="Preference-basedanchor="pref_df"> <name>Preference-Based DFElection">Election</name> <t> When the new capability 'Port Mode' is signaled, the preference-basedDF ElectionDF election algorithmin<xreftarget="I-D.ietf-bess-evpn-pref-df"/>target="RFC9785"/> is modified to consider the port only and not any associatedEthernet Tags.Ethernet Tags. The Port Mode capability is compatible with the 'Don'tPre-empt'Preempt' bit and both may be signaled. When an interface recovers, a peering PE signaling the D bit enables non-revertive behavior at the port level. </t> </section> <section anchor="ac_df"> <name>AC-Influenced DF Election</name> <t>The AC-DF bit defined in <xref target="RFC8584"/>MUST<bcp14>MUST</bcp14> be set to 0 when advertising Port Mode Designated Forwarder Election capability (P=1). When an AC (sub-interface) goes down, any resulting Ethernet A-D per EVI withdrawal does not influence theDF Election.</t>DF election.</t> <t>Upon receiving the AC-DF bit set (A=1) from a remote PE, itMUST<bcp14>MUST</bcp14> be ignored when performing Port ModeDF Election.</t>Designated Forwarder Election.</t> </section> </section><section title="Convergence considerations"><section> <name>Convergence Considerations</name> <t>To enhance convergence during failure and recovery when the Port-Active redundancy mode is employed, prior synchronization between peering PEs may be beneficial.</t> <t>The Port-Active mode poses a challenge to synchronization since the "standby" port may be in a down state. Transitioning a "standby" port to an up state and stabilizing the network requires time. For Integrated Routing and Bridging (IRB) andLayer 3L3 services, prior synchronization of ARP /NDNeighbor Discovery (ND) caches is recommended. Additionally, associatedVRFVirtual Routing and Forwarding (VRF) tables may need to be synchronized. ForLayer 2L2 services, synchronization of MAC tables may be considered.</t> <t>Moreover, for members of a LAG running LACP, the ability to set the "standby" port to an "out-of-sync" state, also known as "warm-standby," can be utilized to improve convergence times.</t> <sectionanchor="es_ead_pb" title="Primary / Backupanchor="es_ead_pb"> <name>Primary/Backup Bits perEthernet-Segment">Ethernet Segment</name> <t>The EVPNLayer 2 AttributesL2-Attr Extended Community("L2-Attr")defined in <xref target="RFC8214"/>SHOULD<bcp14>SHOULD</bcp14> be advertised in the Ethernet A-D per ES route to enable fast convergence.</t> <t>Only the P and B bits of the Control Flags field in the L2-Attr Extended Community are relevant to this document, specifically in the context of Ethernet A-D per ES routes:</t> <ul> <li>When advertised, the L2-Attr Extended CommunitySHALL<bcp14>SHALL</bcp14> have only the P or B bits set in the Control Flags field, and all other bits and fieldsMUST<bcp14>MUST</bcp14> be zero.</li> <li>A remote PE receiving the optional L2-Attr Extended Community in Ethernet A-D per ES routesSHALL<bcp14>SHALL</bcp14> consider only the P and B bits and ignore other values.</li> </ul> <t>For the L2-Attr Extended Community sent and received in Ethernet A-Dper EVIper EVI routes used in <xref target="RFC8214"/>, <xreftarget="RFC7432"/>target="RFC7432"/>, and <xreftarget="I-D.ietf-bess-evpn-vpws-fxc"/>:</t>target="RFC9744"/>:</t> <ul> <li>P and B bits receivedSHOULD<bcp14>SHOULD</bcp14> be considered overridden by "parent" bits when advertised in the Ethernet A-D per ES.</li> <li>Other fields and bits of the extended community are used according to the procedures outlined in the referenced documents.</li> </ul> <t>By adhering to these procedures, the network ensures proper handling of the L2-Attr Extended Community to maintain robust and efficient convergence across Ethernet Segments.</t> </section><section title="Backward Compatibility"><section> <name>Backward Compatibility</name> <t>Implementations that comply with <xref target="RFC7432"/> or <xref target="RFC8214"/> only (i.e., implementations that predate this specification)whichand that receive an L2-Attr Extended Community in Ethernet A-D per ES routes will ignore it and continue to use the default path resolution algorithms of the two specifications above:</t> <ul> <li>The L2-Attr Extended Community in Ethernet A-D per ES route isignored</li>ignored.</li> <li>The remote ESI Label Extended Community(<xref target="RFC7432"/>)<xref target="RFC7432"/> signals the Single-Active redundancy mode (<xreftarget="df_algo"/>)</li> <li>thetarget="df_algo"/>).</li> <li>The remoteMACMedia Access Control (MAC) and/or Ethernet A-D per EVI routes areunchanged,unchanged; the P and B bits in the L2-Attr Extended Community in Ethernet A-D per EVI routes are used.</li> </ul> </section> </section><section title="Applicability"><section> <name>Applicability</name> <t>A prevalent deployment scenario involves providing L2 or L3 services on PE devices that offer multi-homing capabilities. The services may include any L2 EVPN solutions such as EVPNVPWSVirtual Private Wire Service (VPWS) or standard EVPN as defined in <xref target="RFC7432"/>. Additionally, L3 services may be provided within a VPN context, as specified in <xref target="RFC4364"/>, or within a global routing context. When a PE provides first-hop routing, EVPN IRB may also be deployed on the PEs. The mechanism outlined in this document applies to PEs providing L2 and/or L3 services where active/standby redundancy at the interface level is required.</t> <t>An alternative solution to the one described in this document isMulti-Chassis Link Aggregation Group (MC-LAG)MC-LAG with ICCPactive-standbyactive/standby redundancy, as detailed in <xref target="RFC7275"/>. However, ICCP requires LDP to be enabled as a transport for ICCP messages. There are numerous scenarios where LDP is not necessary, such as deployments utilizing VXLAN or SRv6. The solution using EVPN, as described in thisdocument using EVPNdocument, does not mandate the use of LDP or ICCP and remains independent of the underlay encapsulation.</t> </section> <sectionanchor="IANA" title="IANA Considerations"> <t>This document solicits the allocation ofanchor="IANA"> <name>IANA Considerations</name> <t>Per this document, IANA has added the followingvalues fromentry to the "DF Election Capabilities" registry under the"BGP"Border Gateway Protocol (BGP) Extended Communities" registrygroup :</t> <ul spacing="normal"> <li>Bit 5 in the <xref target="RFC8584"/> DF Election Capabilities registry, "Portgroup:</t> <table anchor="iana_table"> <thead> <tr> <th>Bit</th> <th>Name</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>5</td> <td>Port Mode Designated ForwarderElection".</li> </ul>Election</td> <td>RFC 9786</td> </tr> </tbody> </table> </section><section title="Security Considerations"><section> <name>Security Considerations</name> <t>TheSecurity Considerationssecurity considerations described in <xref target="RFC7432"/> and <xref target="RFC8584"/> are applicable to this document.</t> <t>Introducing a new capability necessitates unanimity among PEs. Without consensus on the new DFElectionelection procedures and Port Mode, theDF ElectionDF election algorithm defaults to the procedures outlined in <xref target="RFC8584"/> and <xref target="RFC7432"/>.This fallback behavior could be exploited by an attacker who modifies the configuration of one PE within theEthernet Segment (ES).ES. Such manipulation could force all PEs in the ES to revert to the defaultDF ElectionDF election algorithm and capabilities. In this scenario, the PEs may be subject to unfair load balancing, service disruption, and potential issues such asblack-holingtraffic loss or duplicate traffic, as mentioned in the security sections of those documents.</t> </section><section></middle> <back> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8214.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8584.xml"/> <!-- [RFC9722] draft-ietf-bess-evpn-fast-df-recovery-12 companion doc RFC9722; in RFC Editor Queue as of xx/yy/zz. Updated the title to match the doc --> <reference anchor="RFC9722" target="https://www.rfc-editor.org/info/rfc9722"> <front> <title>Fast Recovery for EVPN Designated Forwarder Election</title> <author fullname="Patrice Brissette" initials="P." surname="Brissette"> <organization>Cisco</organization> </author> <author fullname="Ali Sajassi" initials="A." surname="Sajassi"> <organization>Cisco</organization> </author> <author fullname="Luc André Burdet" initials="LA." surname="Burdet" role="editor"> <organization>Cisco</organization> </author> <author fullname="John Drake" initials="J." surname="Drake"> <organization>Independent</organization> </author> <author fullname="Jorge Rabadan" initials="J." surname="Rabadan"> <organization>Nokia</organization> </author> <date month="May" year="2025"/> </front> <seriesInfo name="RFC" value="RFC9722"/> </reference> <!-- [RFC9785] draft-ietf-bess-evpn-pref-df-13 companion doc RFC9785; in RFC Editor Queue as of 04/24/25. Updated the title to match the doc --> <reference anchor="RFC9785" target="https://www.rfc-editor.org/info/rfc9785"> <front> <title>Preference-Based EVPN Designated Forwarder (DF) Election</title> <author fullname="Jorge Rabadan" initials="J." surname="Rabadan" role="editor"> <organization>Nokia</organization> </author> <author fullname="Senthil Sathappan" initials="S." surname="Sathappan"> <organization>Nokia</organization> </author> <author fullname="Wen Lin" initials="W." surname="Lin"> <organization>Juniper Networks</organization> </author> <author fullname="John Drake" initials="J." surname="Drake"> <organization>Independent</organization> </author> <author fullname="Ali Sajassi" initials="A." surname="Sajassi"> <organization>Cisco Systems</organization> </author> <date month="May" year="2025"/> </front> <seriesInfo name="RFC" value="RFC9785"/> <seriesInfo name="DOI" value="10.17487/RFC9785"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml6/reference.R.IEEE.802.1AX-2014.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5036.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7275.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7348.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/> <!--I-D.ietf-bess-evpn-vpws-fxc is now RFC 9744 --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9744.xml"/> </references> </references> <section numbered="false"> <name>Acknowledgements</name> <t>The authors thankAnoop Ghanwani<contact fullname="Anoop Ghanwani"/> for his comments and suggestions andStephane Litkowski and Gunter van<contact fullname="Stephane Litkowski"/> and <contact fullname="Gunter Van deVeldeVelde"/> for their careful reviews.</t> </section> <sectiontitle="Contributors">numbered="false"> <name>Contributors</name> <t>In addition to the authors listed on the front page, the following people have also contributed to this document:</t> <author fullname="Ali Sajassi" initials="A." surname="Sajassi"> <organization>Cisco Systems</organization> <address> <postal><street/> <city/> <region/> <code/> <country>USA</country><country>United States of America</country> </postal> <email>sajassi@cisco.com</email> </address> </author> <author fullname="Samir Thoria" initials="S." surname="Thoria"> <organization>Cisco Systems</organization> <address> <postal><street/> <city/> <region/> <code/> <country>USA</country><country>United States of America</country> </postal> <email>sthoria@cisco.com</email> </address> </author> </section></middle> <!-- *****BACK MATTER ***** --> <back> <!-- References split into informative and normative --> <references title="Normative References"> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7432.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8214.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8584.xml"/> <?rfc include='reference.I-D.draft-ietf-bess-evpn-pref-df-13.xml' ?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml6/reference.R.IEEE.802.1AX-2014.xml"/> </references> <references title="Informative References"> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4364.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5306.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7275.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7348.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8402.xml"/> <?rfc include='reference.I-D.draft-ietf-bess-evpn-vpws-fxc-10.xml' ?> </references></back> </rfc>