<?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> <!--[rfced] Luc André, FYI, we updated your name to match how you updated it in RFC 9722 during AUTH48 recently. Please let us know if you prefer otherwise. --> <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<!-- [rfced] FYI, we note that RFC 5306 does not mention "LDP". Apparently the digits were transposed, so we updated the reference from [RFC5306] to [RFC5036], titled "LDP Specification". Please let us know if this is not accurate. Original: b. Port-Active redundancy eliminates the need for ICCP and LDP<xref target="RFC5306"/>[RFC5306] (e.g., VXLAN [RFC7348] or SRv6 [RFC8402] may be used in the network). Current: b. It eliminates the need for ICCP and LDP [RFC5036] (e.g., Virtual eXtensible Local Area Network (VXLAN) [RFC7348] or Segment Routing over IPv6 (SRv6) [RFC8402] may be used in the network). --> <li>It eliminates the need for ICCP and LDP <xref target="RFC5036"/> (e.g., Virtual 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> <!--[rfced] The text states that one or more PEs keep the port in standby mode. Do one or more PEs keep the port in active mode as shown below? Original: PEs in the redundancy group leverage the DF election defined in [RFC8584] to determine which PE keeps the port in active mode and which one(s) keep it in standby mode. Perhaps: PEs in the redundancy group leverage the DF election defined in [RFC8584] to determine which PE(s) keeps the port in active mode and which PE(s) keeps it in standby mode. --> <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 which one(s) keep 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> <!-- [rfced] [RFC7432] does not mention a "Single-Active blocking scheme", but it does mention "Single-Active redundancy mode". Is an update perhaps needed to the text below? Original: Non-DF routers SHOULD implement a bidirectional blocking scheme for all traffic comparable to the Single-Active blocking scheme described in [RFC7432], albeit across all VLANs. --> <t>Non-DF routers <bcp14>SHOULD</bcp14> implement a bidirectional blocking scheme for all traffic comparable to the Single-Active blocking scheme 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 a Bitmap (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> </dl> <figure anchor="Bitmap"> <name>Amended DF Election Capabilities in the DF Election Extended Community</name> <!--[rfced] Should Figure 2 be updated to show the T bit as defined in RFC-to-be 9722 (draft-ietf-bess-evpn-fast-df-recovery-12), which is currently in AUTH48 state? If so, should any text be added to mention that document? (This question also appears in RFC-to-be 9785.) Original: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D|A| |P| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Perhaps: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D|A| |T| |P| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --> <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| |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<!--[rfced] How may we rephrase this sentence for clarity? We note that "DF Elected" is not used elsewhere in the document or in the normative references; should "Elected" perhaps be removed (option A), or should "election" perhaps be used instead (option B)? Also note that RFC 8584 expands "BDF" as "Backup Designated Forwarder" (rather than "Back-up DF Elected"); may we update this expansion accordingly? Original: The algorithm to detemine the DF Elected and Backup-DF Elected (BDF) at<relrefSection 3.2 of [RFC8584] is repeated and summarized below using only (Es) in the computation: Perhaps A: The algorithm used to determine the DF and Backup Designated Forwarder (BDF) per Section 3.2 of [RFC8584] is repeated and summarized below using only (Es) in the computation: or Perhaps B: The algorithm used to determine the DF and Backup Designated Forwarder (BDF) elections per Section 3.2 of [RFC8584] is repeated and summarized below using only (Es) in the computation: --> <t>The algorithm to determine the DF Elected and Backup-DF Elected (BDF) at <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="Primaryanchor="es_ead_pb"> <!--[rfced] In the title of Section 4.1, we added "Bits" as the "P and B bits" are described in this section. Please let us know if this update is not correct. Original: 4.1. Primary / Backup perEthernet-Segment">Ethernet-Segment Current: 4.1. Primary/Backup Bits per Ethernet Segment --> <name>Primary/Backup Bits per 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> <li>Theignored.</li> <!--[rfced] Does the remote ESI label extended community signal a Single-Active "procedure" or perhaps "redundancy mode"? Please clarify. Original: * The remote ESI Label Extended Community(<xref target="RFC7432"/>)([RFC7432]) signals Single-Active (Section 3) Perhaps: * The remote ESI label extended community [RFC7432] signals the Single-Active redundancy mode (Section 3). --> <li>The remote ESI label extended community <xref target="RFC7432"/> signals Single-Active (<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"BGP"DF Election Capabilities" registry under the "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 as black-holing 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"/> <!-- [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 *****[rfced] Terminology a) Throughout the text, the following terminology appears to be used inconsistently. Please review these occurrences and let us know if/how they may be made consistent. Bitmap field vs. bitmap field [Are these different? For example, "a Bitmap (2 octets) field" vs. "DF Election Capabilities bitmap field"] b) We updated the text to use the form on the right for consistency within this document and Cluster 492 (C492). Please let us know of any objections. active-standby -> active/standby All-active -> All-Active DF Election -> DF election (for general use, per RFC 8584) DF Election extended community -> DF Election Extended Community (per RFC 8584) 'Don't Pre-empt' -> 'Don't Preempt' (per companion doc and IANA registry) ESI Label Extended Community -> ESI label extended community (per RFC 7432) Ethernet-AD per-ES -> Ethernet A-D per ES (per RFC 8584) Port Mode DF Election -> Port Mode Designated Forwarder Election (per IANA) Single-active -> Single-Active --><back><!--References split into informative[rfced] Abbreviations a) FYI: We have added expansions for the following abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Customer Equipment (CE) Cyclic Redundancy Check (CRC) Media Access Control (MAC) Neighbor Discovery (ND) Segment Routing over IPv6 (SRv6) Virtual Routing andnormativeForwarding (VRF) Virtual Private Wire Service (VPWS) Virtual eXtensible Local Area Network (VXLAN) b) For consistency within the RFC series and C492, we updated the document to use the form on the right. Please review. AC-Influenced Designated Forwarder Election (AC-DF) -> AC-Influenced DF (AC-DF) election (per RFC 8584) Interchassis Communication Protocol (ICCP) -> Inter-Chassis Communication Protocol (ICCP) Multi-Chassis Link Aggregation Group (MC-LAG) -> Multi-Chassis Link Aggregation (MC-LAG) group --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. For example, please consider whether the following should be updated: - black-holing --><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>