rfc9786xml2.original.xml   rfc9786.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?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 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
(using these PIs as follows is recommended by the RFC Editor) --> tf-bess-evpn-mh-pa-13" number="9786" consensus="true" submissionType="IETF" ipr=
<?rfc compact="yes" ?> "trust200902" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" vers
<!-- do not start each main section on a new page --> ion="3" xml:lang="en" obsoletes="" updates="">
<?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"
consensus="true"
submissionType="IETF"
ipr="trust200902"
tocInclude="true"
tocDepth="4"
symRefs="true"
sortRefs="true">
<!-- ***** FRONT MATTER ***** -->
<front> <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> <title abbrev="EVPN Port-Active Redundancy Mode">EVPN Port-Active Redundancy Mode</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-bess-evpn-mh-pa-13"/> <seriesInfo name="RFC" value="9786"/>
<author fullname="Patrice Brissette" initials="P." surname="Brissette">
<author fullname="Patrice Brissette" initials="P." surname="Brissette">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/>
<city>Ottawa</city> <city>Ottawa</city>
<region>ON</region> <region>ON</region>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<phone/>
<email>pbrisset@cisco.com</email> <email>pbrisset@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Luc Andre Burdet" initials="LA." role="editor" surname="Bu <!--[rfced] Luc André, FYI, we updated your name to match
rdet"> how you updated it in RFC 9722 during AUTH48 recently.
Please let us know if you prefer otherwise.
-->
<author fullname="Luc André Burdet" initials="LA." surname="Burdet" role="ed
itor">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/>
<city/>
<region/>
<code/>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>lburdet@cisco.com</email> <email>lburdet@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Bin Wen" initials="B." surname="Wen"> <author fullname="Bin Wen" initials="B." surname="Wen">
<organization>Comcast</organization> <organization>Comcast</organization>
<address> <address>
<postal> <postal>
<street/> <country>United States of America</country>
<city/>
<region/>
<code/>
<country>USA</country>
</postal> </postal>
<email>Bin_Wen@comcast.com</email> <email>Bin_Wen@comcast.com</email>
</address> </address>
</author> </author>
<author fullname="Edward Leyton" initials="E." surname="Leyton"> <author fullname="Edward Leyton" initials="E." surname="Leyton">
<organization>Verizon Wireless</organization> <organization>Verizon Wireless</organization>
<address> <address>
<postal> <postal>
<street/> <country>United States of America</country>
<city/>
<region/>
<code/>
<country>USA</country>
</postal> </postal>
<email>edward.leyton@verizonwireless.com</email> <email>edward.leyton@verizonwireless.com</email>
</address> </address>
</author> </author>
<author fullname="Jorge Rabadan" initials="J." surname="Rabadan"> <author fullname="Jorge Rabadan" initials="J." surname="Rabadan">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street/> <country>United States of America</country>
<city/>
<region/>
<code/>
<country>USA</country>
</postal> </postal>
<email>jorge.rabadan@nokia.com</email> <email>jorge.rabadan@nokia.com</email>
</address> </address>
</author> </author>
<date year="2025" month="May"/>
<date year="2024"/> <area>RTG</area>
<workgroup>bess</workgroup>
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>BESS Working Group</workgroup>
<keyword>Port-Active</keyword> <keyword>Port-Active</keyword>
<keyword>EVPN</keyword> <keyword>EVPN</keyword>
<keyword>Multi-homing</keyword> <keyword>Multi-homing</keyword>
<abstract> <abstract>
<t>The Multi-Chassis Link Aggregation Group (MC-LAG) technology enables <t>The Multi-Chassis Link Aggregation (MC-LAG) group technology enables
establishing a logical link-aggregation connection with a establishing a logical link-aggregation connection with a
redundant group of independent nodes. The objective of MC-LAG is to enhance b oth network redundant group of independent nodes. The objective of MC-LAG is to enhance b oth network
availability and bandwidth utilization through various modes of traffic load- availability and bandwidth utilization through various modes of traffic load
balancing. RFC7432 balancing. RFC 7432
defines EVPN-based MC-LAG with Single-active and All-active multi-homing redu defines an EVPN-based MC-LAG with Single-Active and All-Active multi-homing r
ndancy modes. edundancy modes.
This document builds on the existing redundancy mechanisms supported by EVPN and introduces This document builds on the existing redundancy mechanisms supported by EVPN and introduces
a new active/standby redundancy mode, called 'Port-Active'.</t> a new active/standby redundancy mode, called 'Port-Active'.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section>
<name>Introduction</name>
<t>EVPN <xref target="RFC7432"/> defines the All-Active and Single-Active redundancy modes. <t>EVPN <xref target="RFC7432"/> defines the All-Active and Single-Active redundancy modes.
All-Active redundancy provides per-flow load-balancing for multi-homing, w hile Single-Active All-Active redundancy provides per-flow load balancing for multi-homing, w hile Single-Active
redundancy ensures service carving where only one of the Provider Edge (PE ) devices in a redundancy relationship is redundancy ensures service carving where only one of the Provider Edge (PE ) devices in a redundancy relationship is
active per service.</t> active per service.</t>
<t>Although these two multi-homing scenarios are widely utilized in data c enter and service provider <t>Although these two multi-homing scenarios are widely utilized in data c enter and service provider
access networks, there are cases where active/standby multi-homing at the interface level is 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 of l beneficial and necessary. The primary consideration for this new mode of l
oad-balancing is the oad balancing is the
determinism of traffic forwarding through a specific interface, rather tha determinism of traffic forwarding through a specific interface rather than
n statistical per-flow statistical per-flow
load-balancing across multiple PEs providing multi-homing. This determinis load balancing across multiple PEs providing multi-homing. This determinis
m is essential for certain m is essential for certain
QoS features to function correctly. Additionally, this mode ensures fast c onvergence during failure QoS features to function correctly. Additionally, this mode ensures fast c onvergence during failure
and recovery, which is expected by customers.</t> 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 <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> and details how this mode operates and is supported via EVPN.</t>
<section anchor="requirements"> <section anchor="requirements">
<!-- anchor is an optional attribute -->
<name>Requirements Language</name> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", <t>
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
interpreted as described in BCP 14 <xref target="RFC2119"/> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
<xref target="RFC8174"/> when, and only when, they appear in RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section>
<section> <name>Multi-Chassis Link Aggregation (MC-LAG)</name>
<name>Multi-Chassis Link Aggregation (MC-LAG)</name> <t>When a Customer Equipment (CE) device is multi-homed to a set of PE n
<t>When a CE device is multi-homed to a set of PE nodes using the <xref ta odes using the
rget="IEEE_802.1AX_2014"/> Link Aggregation Control Protocol (LACP) <xref target="IEEE_802.1AX_2014"/>,
Link Aggregation Control Protocol (LACP), the PEs must function as a single L the PEs must function as a single LACP entity for the
ACP entity for the
Ethernet links to form and operate as a Link Aggregation Group (LAG). To achi eve this, the PEs Ethernet links to form and operate as a Link Aggregation Group (LAG). To achi eve this, the PEs
connected to the same multi-homed CE must synchronize LACP configuration and operational data connected to the same multi-homed CE must synchronize LACP configuration and operational data
among them. Historically, the Interchassis Communication Protocol (ICCP) <xre f target="RFC7275"/> among them. Historically, the Inter-Chassis Communication Protocol (ICCP) <xr ef target="RFC7275"/>
has been used for this synchronization. has been used for this synchronization.
EVPN, as described in <xref target="RFC7432"/>, covers the scenario where a C E is multi-homed to EVPN, as described in <xref target="RFC7432"/>, covers the scenario where a C E is multi-homed to
multiple PE nodes, using a LAG to simplify the procedure significantly. This multiple PE nodes, using a LAG to simplify the procedure significantly. Howev
simplification, er, this simplification
however, comes with certain assumptions:</t> comes with certain assumptions:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>a CE device connected to EVPN multi‑homing PEs MUST have a single LA <li>A CE device connected to EVPN multi-homing PEs <bcp14>MUST</bcp14>
G with all its links have a single LAG with all its links
connected to the EVPN multi-homing PEs in a redundancy group.</li> connected to the EVPN multi-homing PEs in a redundancy group.</li>
<li>identical LACP parameters MUST be configured on peering PEs, includi <li>Identical LACP parameters <bcp14>MUST</bcp14> be configured on pee
ng system ID, port priority, and port key.</li> ring PEs, including the system ID, port priority, and port key.</li>
</ul> </ul>
<t>This document presumes proper LAG operation as specified in <xref targe <t>This document presumes proper LAG operation as specified in <xref tar
t="RFC7432"/>. get="RFC7432"/>.
Issues resulting from deviations in the aforementioned assumptions, LAG mi sconfiguration, and Issues resulting from deviations in the aforementioned assumptions, LAG mi sconfiguration, and
miswiring detection across peering PEs are considered outside the scope of this document. miswiring detection across peering PEs are considered outside the scope of this document.
<figure anchor="Topology"> </t>
<name>MC-LAG Topology</name> <figure anchor="Topology">
<artwork align="left"><![CDATA[ <name>MC-LAG Topology</name>
<artwork align="left"><![CDATA[
+-----+ +-----+
| PE3 | | PE3 |
+-----+ +-----+
+-----------+ +-----------+
| MPLS/IP | | MPLS/IP |
| CORE | | CORE |
+-----------+ +-----------+
+-----+ +-----+ +-----+ +-----+
| PE1 | | PE2 | | PE1 | | PE2 |
+-----+ +-----+ +-----+ +-----+
I1 I2 I1 I2
\ / \ /
\ / \ /
\ / \ /
+---+ +---+
|CE1| |CE1|
+---+ +---+]]></artwork>
]]></artwork> </figure>
</figure> <t><xref target="Topology"/> shows an MC-LAG multi-homing topology where
</t> PE1 and PE2 are
<t><xref target="Topology"/> shows a MC-LAG multi‑homing topology where PE part of the same redundancy group providing multi-homing to CE1 via
1 and PE2 are
part of the same redundancy group providing multi‑homing to CE1 via
interfaces I1 and I2. Interfaces I1 and I2 are members of a LAG running LAC P. The core, shown as IP or MPLS interfaces I1 and I2. Interfaces I1 and I2 are members of a LAG running LAC P. The core, shown as IP or MPLS
enabled, provides a wide range of L2 and L3 services. MC-LAG multi‑homing enabled, provides a wide range of L2 and L3 services. MC-LAG multi-homing
functionality is decoupled from those services in the core and functionality is decoupled from those services in the core, and
it focuses on providing multi‑homing to the CE. In Port-Active redundancy m it focuses on providing multi-homing to the CE. In Port-Active redundancy m
ode, only one of the ode, only one of the
two interfaces I1 or I2 two interfaces, I1 or I2,
would be in forwarding and the other interface will be in standby. This would be in forwarding, and the other interface would be in standby. This
also implies that all services on the active interface are in active also implies that all services on the active interface operate in active
mode and all services on the standby interface operate in standby mode and all services on the standby interface operate in standby
mode.</t> mode.</t>
</section>
</section> </section>
</section>
<section> <section>
<name>Port-Active Redundancy Mode</name> <name>Port-Active Redundancy Mode</name>
<section>
<name>Overall Advantages</name>
<t>The use of Port-Active redundancy in EVPN networks provides the follo
wing benefits:</t>
<ol spacing="normal" type="a">
<li>It offers open-standards-based
active/standby redundancy at the interface level rather than VLAN granular
ity <xref target="RFC7432"/>.</li>
<section> <!-- [rfced] FYI, we note that RFC 5306 does not mention "LDP".
<name>Overall Advantages</name> Apparently the digits were transposed, so we updated the reference
<t>The use of Port-Active redundancy in EVPN networks provides the followi from [RFC5306] to [RFC5036], titled "LDP Specification".
ng benefits:</t> Please let us know if this is not accurate.
<ol spacing="normal" type="a">
<li>Port-Active redundancy offers open standards-based Original:
active/standby redundancy at the interface level, rather than VLAN granula b. Port-Active redundancy eliminates the need for ICCP and LDP
rity <xref [RFC5306] (e.g., VXLAN [RFC7348] or SRv6 [RFC8402] may be used in
target="RFC7432"/>.</li> the network).
<li>Port-Active redundancy eliminates the need for ICCP and LDP <xref t
arget="RFC5306"/> (e.g., Current:
VXLAN <xref b. It eliminates the need for ICCP and LDP [RFC5036] (e.g., Virtual
target="RFC7348"/> or SRv6 <xref target="RFC8402"/> may be used in the n eXtensible Local Area Network (VXLAN) [RFC7348] or Segment
etwork).</li> Routing over IPv6 (SRv6) [RFC8402] may be used in the network).
<li>This mode is agnostic of the underlying technology (MPLS, VXLAN, SRv -->
6) and associated services (L2, L3, Bridging, E-LINE, etc.)</li>
<li>It enables deterministic QoS over MC-LAG attachment circuits.</li> <li>It eliminates the need for ICCP and LDP <xref target="RFC5036"/>
<li>Port-Active redundancy is fully compliant with <xref target="RFC7432 (e.g.,
"/> and does not Virtual eXtensible Local Area Network (VXLAN) <xref target="RFC7348"/> or
Segment Routing over IPv6 (SRv6) <xref target="RFC8402"/> may be used in the net
work).</li>
<li>This mode is agnostic of the underlying technology (MPLS, VXLAN, a
nd SRv6) and associated services (Layer 2 (L2), Layer 3 (L3), Bridging, E-LINE,
etc.)</li>
<li>It enables deterministic QoS over MC-LAG attachment circuits.</li>
<li>It is fully compliant with <xref target="RFC7432"/> and does not
require any new protocol enhancements to existing EVPN RFCs.</li> require any new protocol enhancements to existing EVPN RFCs.</li>
<li>It can leverage various Designated Forwarder (DF) election algorithm <li>It can leverage various Designated Forwarder (DF) election algorit
s, such as modulo hms, such as modulo
(<xref target="RFC7432"/>), Highest Random Weight (HRW, <xref target="RF <xref target="RFC7432"/>, Highest Random Weight (HRW) <xref target="RFC8
C8584"/>), etc.</li> 584"/>, etc.</li>
<li> <li>
<t>Port-Active redundancy replaces legacy MC-LAG ICCP-based solutions <t>It replaces legacy MC-LAG ICCP-based solutions and offers the
and offers the
following additional benefits:</t> following additional benefits:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Efficient support for 1+N redundancy mode (with EVPN using BGP R <li>Efficient support for 1+N redundancy mode (with EVPN using BGP
oute Reflector), whereas ICCP Route Reflector), whereas ICCP
requires a full mesh of LDP sessions among PEs in the redundancy gro up.</li> requires a full mesh of LDP sessions among PEs in the redundancy gro up.</li>
<li>Fast convergence with mass-withdraw is possible with EVPN, which has no equivalent <li>Fast convergence with mass withdraw is possible with EVPN, whi ch has no equivalent
in ICCP.</li> in ICCP.</li>
</ul> </ul>
</li> </li>
</ol> </ol>
</section> </section>
<section>
<section title="Port-Active Redundancy Procedures"> <name>Port-Active Redundancy Procedures</name>
<t>The following steps outline the proposed procedure for supporting Por t-Active redundancy <t>The following steps outline the proposed procedure for supporting Por t-Active redundancy
mode with EVPN LAG:</t> mode with EVPN LAG:</t>
<ol spacing="normal" type="a">
<li>The Ethernet Segment Identifier (ESI) <bcp14>MUST</bcp14> be assigne
d per access interface as described
in <xref target="RFC7432"/>. The ESI can be auto-derived or manually ass
igned, and the access
interface <bcp14>MAY</bcp14> be an L2 or L3 interface.</li>
<li>The Ethernet Segment (ES) <bcp14>MUST</bcp14> be configured in Por
t-Active redundancy mode on peering
PEs for the specified access interface.</li>
<li>When ESI is configured on an L3 interface, the ES route (Route
Type-4) can be the only route exchanged by PEs in the redundancy group
.</li>
<ol spacing="normal" type="a"> <!--[rfced] The text states that one or more PEs keep the port in
<li>The Ethernet-Segment Identifier (ESI) MUST be assigned per access in standby mode. Do one or more PEs keep the port in active mode
terface as described as shown below?
in <xref target="RFC7432"/>. The ESI can be auto-derived or manually ass
igned and the access
interface MAY be a Layer-2 or Layer-3 interface.</li>
<li>The Ethernet-Segment (ES) MUST be configured in Port-Active redundan Original:
cy mode on peering PEs in the redundancy group leverage the DF election defined in
PEs for the specified access interface.</li> [RFC8584] to determine which PE keeps the port in active mode and
which one(s) keep it in standby mode.
<li>When ESI is configured on a Layer-3 interface, the Ethernet-Segment Perhaps:
(ES) route (Route PEs in the redundancy group leverage the DF election defined in
Type-4) can be the only route exchanged by PEs in the redundancy group.< [RFC8584] to determine which PE(s) keeps the port in active mode
/li> and which PE(s) keeps it in standby mode.
-->
<li>PEs in the redundancy group leverage the DF election defined in <xre f target="RFC8584"/> <li>PEs in the redundancy group leverage the DF election defined in <x ref target="RFC8584"/>
to determine which PE keeps the port in active mode and which one(s) kee p it in standby to determine which PE keeps the port in active mode and which one(s) kee p it in standby
mode. Although the DF election defined in <xref target="RFC8584"/> is pe r [ES, Ethernet Tag] mode. Although the DF election defined in <xref target="RFC8584"/> is pe r [ES, Ethernet Tag]
granularity, the DF election is performed per [ES] in Port-Active redund ancy mode. The granularity, the DF election is performed per [ES] in Port-Active redund ancy mode. The
details of this algorithm are described in <xref target="df_algo"/>.</li > details of this algorithm are described in <xref target="df_algo"/>.</li >
<li>The DF router <bcp14>MUST</bcp14> keep the corresponding access in
terface in an up and forwarding
active state for that ES.</li>
<li>
<li>The DF router MUST keep the corresponding access interface in an up <!-- [rfced] [RFC7432] does not mention a "Single-Active blocking
and forwarding scheme", but it does mention "Single-Active redundancy mode". Is
active state for that Ethernet-Segment.</li> an update perhaps needed to the text below?
<li>Non-DF routers SHOULD implement a bidirectional blocking scheme for Original:
all traffic 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 bl
ocking scheme for all traffic
comparable to the Single-Active blocking scheme described in <xref targe t="RFC7432"/>, comparable to the Single-Active blocking scheme described in <xref targe t="RFC7432"/>,
albeit across all VLANs. albeit across all VLANs.
</t>
<ul> <ul>
<li>Non-DF routers MAY bring and keep the peering access interface a ttached to them in <li>Non-DF routers <bcp14>MAY</bcp14> bring and keep the peering a ccess interface attached to them in
an operational down state.</li> an operational down state.</li>
<li>If the interface is running the LACP protocol, the non-DF PE MAY <li>If the interface is running the LACP protocol, the non-DF PE <
set the LACP state bcp14>MAY</bcp14> set the LACP state
to OOS (Out of Sync) instead of setting the interface to a down stat to Out of Sync (OOS) instead of setting the interface to a down stat
e. This approach e. This approach
allows for better convergence during the transition from standby to active mode.</li> allows for better convergence during the transition from standby to active mode.</li>
</ul> </ul>
</li> </li>
<li>The primary/backup bits of the EVPN Layer 2 Attributes (L2-Attr) E
<li>The primary/backup bits of the EVPN Layer 2 Attributes Extended Comm xtended Community <xref target="RFC8214"/> <bcp14>SHOULD</bcp14> be used to achi
unity <xref target="RFC8214"/> SHOULD be used to achieve better convergence, as eve better convergence, as described in <xref target="es_ead_pb"/>.</li>
described in <xref target="es_ead_pb"/>.</li> </ol>
</ol> </section>
</section> </section>
</section>
<section anchor="df_algo"> <section anchor="df_algo">
<name>Designated Forwarder Algorithm to Elect per Port-Active PE</name> <name>Designated Forwarder Algorithm to Elect per Port-Active PE</name>
<t>The Ethernet-Segment (ES) routes operating in Port-Active redundancy mo <t>The ES routes operating in Port-Active redundancy mode are advertised w
de are advertised with the new Port ith the new Port
Mode Load-Balancing capability bit in the DF Election Extended Community a Mode Load-Balancing capability bit in the DF Election Extended Community a
s defined in <xref s defined in <xref target="RFC8584"/>. Additionally, the ES associated with the
target="RFC8584"/>. Additionally, the ES associated with the port utilizes port utilizes the existing
the existing Single-Active procedure and signals the Single-Active multi-homed site red
Single-Active procedure and signals the Single-Active Multihomed site redu undancy mode along
ndancy mode along with the Ethernet A-D per-ES route (refer to <xref target="RFC7432" sectio
with the Ethernet-AD per-ES route (refer to <relref target="RFC7432" secti n="7.5"/>).
on="7.5"/>). Finally, The ESI label-based split-horizon procedures specified in <xref t
Finally, The ESI label-based split&nbhy;horizon procedures specified in <r arget="RFC7432" section="8.3"/> <bcp14>SHOULD</bcp14> be employed to prevent tra
elref target="RFC7432" nsient echo packets when L2 circuits are
section="8.3"/> SHOULD be employed to prevent transient echo packets when
Layer-2 circuits are
involved.</t> involved.</t>
<t>Various algorithms for DF election are detailed in Sections <xref targe
<t>Various algorithms for DF Election are detailed in Sections <xref targe t="modulo" format="counter"/> to <xref target="ac_df" format="counter"/> for com
t="modulo" prehensive
format="counter"/> to <xref target="ac_df" format="counter"/> for comprehe
nsive
understanding, although the choice of algorithm in this solution does not significantly impact understanding, although the choice of algorithm in this solution does not significantly impact
complexity or performance compared to other redundancy modes.</t> complexity or performance compared to other redundancy modes.</t>
<section anchor="cap_flag">
<section anchor="cap_flag" title="Capability Flag"> <name>Capability Flag</name>
<t> <xref target="RFC8584"/> defines a DF Election Extended Community an
<t> <xref target="RFC8584"/> defines a DF Election extended community, a d a Bitmap (2
nd a Bitmap (2
octets) field to encode "DF Election Capabilities" to use with the DF el ection algorithm octets) field to encode "DF Election Capabilities" to use with the DF el ection algorithm
in the DF algorithm field: </t> in the DF algorithm field: </t>
<dl newline="false" spacing="normal" indent="10"> <dl newline="false" spacing="normal" indent="10">
<dt>Bit 0:</dt> <dd>D bit or 'Don't Pre-empt' bit, as explained in < <dt>Bit 0:</dt>
xref target="I-D.ietf-bess-evpn-pref-df"/>.</dd> <dd>D bit or 'Don't Preempt' bit, as described in <xref target="RFC978
<dt>Bit 1:</dt> <dd>AC-Influenced DF election, as explained in <xref 5"/>.</dd>
target="RFC8584"/>.</dd> <dt>Bit 1:</dt>
<dd>AC-Influenced DF (AC-DF) election, as described in <xref target="R
FC8584"/>.</dd>
</dl> </dl>
<figure anchor="Bitmap">
<figure anchor="Bitmap">
<name>Amended DF Election Capabilities in the DF Election Extended Com munity</name> <name>Amended DF Election Capabilities in the DF Election Extended Com munity</name>
<artwork align="left"><![CDATA[ <!--[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 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|A| |P| | |D|A| |P| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<t>This document defines the following value and extends the DF Election
<t>This document defines the following value and extends the DF Election Capabilities bitmap field:</t>
Capabilities bitmap field:</t> <dl newline="false" spacing="normal" indent="10">
<dl newline="false" spacing="normal" indent="10">
<dt>Bit 5:</dt> <dt>Bit 5:</dt>
<dd>Port Mode Designated Forwarder Election. This <dd>Port Mode Designated Forwarder Election. This
bit determines that the DF&nbsp;Election algorithm SHOULD be modifie bit determines that the DF election algorithm <bcp14>SHOULD</bcp14>
d to consider the be modified to consider the
port ES only and not the Ethernet Tags.</dd> port ES only and not the Ethernet Tags.</dd>
</dl> </dl>
</section> </section>
<section anchor="modulo" title="Modulo-based Algorithm"> <section anchor="modulo">
<t>The default DF Election algorithm, or modulo-based algorithm, as desc <name>Modulo-Based Algorithm</name>
ribed in <xref <t>The default DF election algorithm, or modulo-based algorithm, as desc
target="RFC7432"/> and updated by <xref target="RFC8584"/>, is applied h ribed in <xref target="RFC7432"/> and updated by <xref target="RFC8584"/>, is ap
ere at the plied here at the
granularity of ES only. Given that the ES-Import Route Target extended c ommunity may be granularity of ES only. Given that the ES-Import Route Target extended c ommunity may be
auto-derived and directly inherits its auto-derived value from ESI bytes 1-6, many operators 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 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 determine the designated forwarder using the modulo-based DF assignment, achieving good
entropy during modulo calculation across ESIs.</t> entropy during modulo calculation across ESIs.</t>
<t>Assuming a redundancy group of N PE nodes, the PE with ordinal i is d esignated as the DF <t>Assuming a redundancy group of N PE nodes, the PE with ordinal i is d esignated as the DF
for an &lt;ES&gt; when (Es mod N) = i, where Es represents bytes 3-6 of that ESI.</t> for an &lt;ES&gt; when (Es mod N) = i, where Es represents bytes 3-6 of that ESI.</t>
</section> </section>
<section anchor="hrw" title="Highest Random Weight Algorithm"> <section anchor="hrw">
<name>Highest Random Weight Algorithm</name>
<t> <t>
An application of Highest Random Weight (HRW) to EVPN DF Election is An application of Highest Random Weight (HRW) to EVPN DF election is
defined in <xref target="RFC8584"/> and MAY also defined in <xref target="RFC8584"/>, and it <bcp14>MAY</bcp14>
be used and signaled. For Port-Active this is modified to operate at the be used and signaled. For Port-Active, this is modified to operate at the
granularity of granularity of
&lt;ES&gt; rather than per &lt;ES, VLAN&gt;.</t> &lt;ES&gt; rather than per &lt;ES, VLAN&gt;.</t>
<t><xref target="RFC8584" section="3.2"/> describes computing a 32-bit C
<t><relref target="RFC8584" section="3.2"/> describes computing a 32-bit yclic Redundancy Check (CRC) over the concatenation of
CRC over the concatenation of
Ethernet Tag (V) and ESI (Es). For Port-Active redundancy mode, the 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 Ethernet Tag is omitted from the CRC computation and all references to (V , Es) are
replaced by (Es).</t> replaced by (Es).</t>
<t>The algorithm to detemine the DF Elected <!--[rfced] How may we rephrase this sentence for clarity? We note
and Backup-DF Elected (BDF) at <relref target="RFC8584" section="3.2"/> i that "DF Elected" is not used elsewhere in the document or in the
s repeated and summarized below using only (Es) 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 Section 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> computation:</t>
<ol> <ol>
<li>DF(Es) = Si| Weight(Es, Si) >= Weight(Es, Sj), for all j. <li>DF(Es) = Si| Weight(Es, Si) &gt;= Weight(Es, Sj), for all j.
In the case of a tie, choose the PE whose IP address is In the case of a tie, choose the PE whose IP address is
numerically the least. Note that 0 &lt;= i,j &lt; number of PEs in t he numerically the least. Note that 0 &lt;= i,j &lt; number of PEs in t he
redundancy group.</li> redundancy group.</li>
<li>BDF(Es) = Sk| Weight(Es, Si) &gt;= Weight(Es, Sk), and
<li>BDF(Es) = Sk| Weight(Es, Si) &gt;= Weight(Es, Sk), and
Weight(Es, Sk) &gt;= Weight(Es, Sj). In the case of a tie, Weight(Es, Sk) &gt;= Weight(Es, Sj). In the case of a tie,
choose the PE whose IP address is numerically the least.</li> choose the PE whose IP address is numerically the least.</li>
</ol> </ol>
<t>Where:</t> <t>Where:</t>
<ul> <ul>
<li>DF(Es) is defined to be the address Si (index i) for which <li>DF(Es) is defined to be the address Si (index i) for which
Weight(Es, Si) is the highest; 0 &lt;= i &lt; N-1.</li> Weight(Es, Si) is the highest; 0 &lt;= i &lt; N-1.</li>
<li>BDF(Es) is defined as that PE with address Sk for which the
<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. 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.</l i> j is the running index from 0 to N-1; i and k are selected values.</l i>
</ul> </ul>
</section> </section>
<section anchor="pref_df" title="Preference-based DF Election"> <section anchor="pref_df">
<t> When the new capability 'Port Mode' is signaled, the preference-base <name>Preference-Based DF Election</name>
d DF&nbsp;Election <t> When the new capability 'Port Mode' is signaled, the preference-base
algorithm in <xref target="I-D.ietf-bess-evpn-pref-df"/> is d DF election
modified to consider the port only and not any associated Ethernet&nbsp;T algorithm <xref target="RFC9785"/> is
ags. The Port Mode modified to consider the port only and not any associated Ethernet Tags.
capability is compatible with the 'Don't Pre-empt' bit and both may be si The Port Mode
gnaled. When an interface recovers, capability is compatible with the 'Don't Preempt' bit and both may be sig
a peering PE signaling D bit enables non-revertive behavior at naled. When an interface recovers,
a peering PE signaling the D bit enables non-revertive behavior at
the port level. </t> the port level. </t>
</section> </section>
<section anchor="ac_df"> <section anchor="ac_df">
<name>AC-Influenced DF Election</name> <name>AC-Influenced DF Election</name>
<t>The AC-DF bit defined in <xref target="RFC8584"/> MUST be set to 0 wh en advertising Port Mode Designated Forwarder Election capability <t>The AC-DF bit defined in <xref target="RFC8584"/> <bcp14>MUST</bcp14> be set to 0 when advertising Port Mode Designated Forwarder Election capability
(P=1). (P=1).
When an AC (sub-interface) goes down, any resulting Ethernet A-D per EVI When an AC (sub-interface) goes down, any resulting Ethernet A-D per EVI
withdrawal does not influence the DF&nbsp;Election.</t> withdrawal does not influence the DF election.</t>
<t>Upon receiving the AC-DF bit set (A=1) from a remote PE, it MUST be i <t>Upon receiving the AC-DF bit set (A=1) from a remote PE, it <bcp14>MU
gnored when performing ST</bcp14> be ignored when performing
Port Mode DF&nbsp;Election.</t> Port Mode Designated Forwarder Election.</t>
</section> </section>
</section> </section>
<section title="Convergence considerations"> <section>
<t>To enhance convergence during failure and recovery when Port-Active red <name>Convergence Considerations</name>
undancy mode is <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> employed, prior synchronization between peering PEs may be beneficial.</t>
<t>The Port-Active mode <t>The Port-Active mode
poses a challenge to synchronization since the "standby" port may be in a down state. Transitioning a "standby" 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 Integra ted Routing and port to an up state and stabilizing the network requires time. For Integra ted Routing and
Bridging (IRB) and Layer 3 services, prior synchronization of ARP / ND cac Bridging (IRB) and L3 services, prior synchronization of ARP / Neighbor Di
hes is recommended. scovery (ND) caches is recommended.
Additionally, associated VRF tables may need to be synchronized. For Layer Additionally, associated Virtual Routing and Forwarding (VRF) tables may n
2 services, eed to be synchronized. For L2 services,
synchronization of MAC tables may be considered.</t> synchronization of MAC tables may be considered.</t>
<t>Moreover, for members of a LAG running LACP, the ability to set the "st andby" port to an <t>Moreover, for members of a LAG running LACP, the ability to set the "st andby" port to an
"out-of-sync" state, also known as "warm-standby," can be utilized to impr ove convergence "out-of-sync" state, also known as "warm-standby," can be utilized to impr ove convergence
times.</t> times.</t>
<section anchor="es_ead_pb">
<section anchor="es_ead_pb" title="Primary / Backup per Ethernet-Segment"> <!--[rfced] In the title of Section 4.1, we added "Bits" as the "P and
<t>The EVPN Layer 2 Attributes Extended Community ("L2-Attr") defined in B bits" are described in this section. Please let us know if this
<xref update is not correct.
target="RFC8214"/> SHOULD be advertised in the Ethernet A-D per ES route
to enable fast Original:
4.1. Primary / Backup per Ethernet-Segment
Current:
4.1. Primary/Backup Bits per Ethernet Segment
-->
<name>Primary/Backup Bits per Ethernet Segment</name>
<t>The EVPN L2-Attr Extended Community defined in <xref target="RFC8214"
/> <bcp14>SHOULD</bcp14> be advertised in the Ethernet A-D per ES route to enabl
e fast
convergence.</t> convergence.</t>
<t>Only the P and B bits of the Control Flags field in the L2-Attr Exten ded Community are <t>Only the P and B bits of the Control Flags field in the L2-Attr Exten ded Community are
relevant to this document, specifically in the context of Ethernet A-D p er ES routes:</t> relevant to this document, specifically in the context of Ethernet A-D p er ES routes:</t>
<ul> <ul>
<li>When advertised, the L2-Attr Extended Community SHALL have only <li>When advertised, the L2-Attr Extended Community <bcp14>SHALL</bcp1
the P or B bits set 4> have only the P or B bits set
in the Control Flags field, and all other bits and fields MUST be ze in the Control Flags field, and all other bits and fields <bcp14>MUS
ro.</li> T</bcp14> be zero.</li>
<li>A remote PE receiving the optional L2-Attr Extended Community in <li>A remote PE receiving the optional L2-Attr Extended Community in E
Ethernet A-D per ES thernet A-D per ES
routes SHALL consider only the P and B bits and ignore other values. routes <bcp14>SHALL</bcp14> consider only the P and B bits and ignor
</li> e other values.</li>
</ul> </ul>
<t>For L2-Attr Extended Community sent and received in Ethernet A-D per EVI <t>For the L2-Attr Extended Community sent and received in Ethernet A-D
routes used in <xref target="RFC8214"/>, <xref target="RFC7432"/> and <xref per EVI
target="I-D.ietf-bess-evpn-vpws-fxc"/>:</t> routes used in <xref target="RFC8214"/>, <xref target="RFC7432"/>, and <xre
f target="RFC9744"/>:</t>
<ul> <ul>
<li>P and B bits received SHOULD be considered overridden by "parent " bits when <li>P and B bits received <bcp14>SHOULD</bcp14> be considered overridd en by "parent" bits when
advertised in the Ethernet A-D per ES.</li> advertised in the Ethernet A-D per ES.</li>
<li>Other fields and bits of the extended community are used accordi ng to the procedures <li>Other fields and bits of the extended community are used according to the procedures
outlined in the referenced documents.</li> outlined in the referenced documents.</li>
</ul> </ul>
<t>By adhering to these procedures, the network ensures proper handling of the L2-Attr <t>By adhering to these procedures, the network ensures proper handling of the L2-Attr
Extended Community to maintain robust and efficient convergence across E thernet Extended Community to maintain robust and efficient convergence across E thernet
Segments.</t> Segments.</t>
</section> </section>
<section title="Backward Compatibility"> <section>
<name>Backward Compatibility</name>
<t>Implementations that comply with <xref target="RFC7432"/> or <xref ta rget="RFC8214"/> only (i.e., implementations <t>Implementations that comply with <xref target="RFC7432"/> or <xref ta rget="RFC8214"/> only (i.e., implementations
that predate this specification) which receive an L2-Attr Extended Community in Ethernet A-D per ES routes will ignore it and continue that predate this specification) and that receive an L2-Attr Extended Commun ity in Ethernet A-D per ES routes will ignore it and continue
to use the default path resolution algorithms of the two specifications abov e:</t> to use the default path resolution algorithms of the two specifications abov e:</t>
<ul> <ul>
<li>The L2-Attr Extended Community in Ethernet A-D per ES route is ignored</ <li>The L2-Attr Extended Community in Ethernet A-D per ES route is ign
li> ored.</li>
<li>The remote ESI Label Extended Community (<xref target="RFC7432"/>) signa
ls Single-Active <!--[rfced] Does the remote ESI label extended community signal a
(<xref target="df_algo"/>)</li> Single-Active "procedure" or perhaps "redundancy mode"? Please
<li>the remote MAC and/or Ethernet A-D per EVI routes are unchanged, the P a clarify.
nd B bits in the L2-Attr
Original:
* The remote ESI Label Extended Community ([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"/> s
ignals Single-Active
(<xref target="df_algo"/>).</li>
<li>The remote Media Access Control (MAC) and/or Ethernet A-D per EVI
routes are unchanged; the P and B bits in the L2-Attr
Extended Community in Ethernet A-D per EVI routes are used.</li> Extended Community in Ethernet A-D per EVI routes are used.</li>
</ul> </ul>
</section> </section>
</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 <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 EVPN VPWS or multi-homing capabilities. The services may include any L2 EVPN solutions such as EVPN Virtual Private Wire Service (VPWS) or
standard EVPN as defined in <xref target="RFC7432"/>. Additionally, L3 ser vices may be standard EVPN as defined in <xref target="RFC7432"/>. Additionally, L3 ser vices may be
provided within a VPN context, as specified in <xref target="RFC4364"/>, o r within a global routing context. provided within a VPN context, as specified in <xref target="RFC4364"/>, o r within a global routing context.
When a PE provides first-hop routing, EVPN IRB may also be deployed on the PEs. The mechanism 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 w here active/standby outlined in this document applies to PEs providing L2 and/or L3 services w here active/standby
redundancy at the interface level is required.</t> redundancy at the interface level is required.</t>
<t>An alternative solution to the one described in this document is Multi- <t>An alternative solution to the one described in this document is MC-LAG
Chassis Link with ICCP active/standby redundancy, as detailed in <xref target="RFC7275"/>. H
Aggregation Group (MC-LAG) with ICCP active-standby redundancy, as detaile owever, ICCP requires LDP to be enabled as a transport for ICCP messages.
d in <xref
target="RFC7275"/>. However, ICCP requires LDP to be enabled as a transpor
t for ICCP messages.
There are numerous scenarios where LDP is not necessary, such as deploymen ts utilizing VXLAN There are numerous scenarios where LDP is not necessary, such as deploymen ts utilizing VXLAN
or SRv6. The solution described in this document using EVPN does not manda te the use of LDP or or SRv6. The solution using EVPN, as described in this document, does not mandate the use of LDP or
ICCP and remains independent of the underlay encapsulation.</t> ICCP and remains independent of the underlay encapsulation.</t>
</section> </section>
<section anchor="IANA">
<name>IANA Considerations</name>
<t>Per this document, IANA has added the following entry to the "DF Electi
on Capabilities" registry under the "Border Gateway Protocol (BGP) Extended
Communities" registry group:</t>
<section anchor="IANA" title="IANA Considerations"> <table anchor="iana_table">
<t>This document solicits the allocation of the following values from the <thead>
"BGP Extended <tr>
Communities" registry group :</t> <th>Bit</th>
<ul spacing="normal"> <th>Name</th>
<li>Bit 5 in the <xref target="RFC8584"/> DF Election Capabilities regi <th>Reference</th>
stry, </tr>
"Port Mode Designated Forwarder Election".</li> </thead>
</ul> <tbody>
</section> <tr>
<td>5</td>
<td>Port Mode Designated Forwarder Election</td>
<td>RFC 9786</td>
</tr>
</tbody>
</table>
<section title="Security Considerations"> </section>
<t>The Security Considerations described in <xref target="RFC7432"/> and < <section>
xref target="RFC8584"/> are applicable to this <name>Security Considerations</name>
<t>The security considerations described in <xref target="RFC7432"/> and <
xref target="RFC8584"/> are applicable to this
document.</t> document.</t>
<t>Introducing a new capability necessitates unanimity among PEs. Without consensus on the new <t>Introducing a new capability necessitates unanimity among PEs. Without consensus on the new
DF Election procedures and Port Mode, the DF&nbsp;Election algorithm defau lts to the procedures DF election procedures and Port Mode, the DF election algorithm defaults t o the procedures
outlined in <xref target="RFC8584"/> and <xref target="RFC7432"/>.This fal lback behavior could outlined in <xref target="RFC8584"/> and <xref target="RFC7432"/>.This fal lback behavior could
be exploited by an attacker who modifies the configuration of one PE withi be exploited by an attacker who modifies the configuration of one PE withi
n the Ethernet n the ES. Such manipulation could force all PEs in the ES to revert to the defau
Segment (ES). Such manipulation could force all PEs in the ES to revert to lt DF election
the default DF&nbsp;Election
algorithm and capabilities. In this scenario, the PEs may be subject to un fair load algorithm and capabilities. In this scenario, the PEs may be subject to un fair load
balancing, service disruption, and potential issues such as black-holing o r duplicate traffic, balancing, service disruption, and potential issues such as black-holing o r duplicate traffic,
as mentioned in the security sections of those documents.</t> as mentioned in the security sections of those documents.</t>
</section> </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.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
432.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
214.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
584.xml"/>
<!-- [RFC9785] draft-ietf-bess-evpn-pref-df-13 companion doc RFC9785; in RFC Edi
tor 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="edito
r">
<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.IE
EE.802.1AX-2014.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
364.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
036.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
275.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
348.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
402.xml"/>
<!--I-D.ietf-bess-evpn-vpws-fxc is now RFC 9744 -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.974
4.xml"/>
</references>
</references>
<section numbered="false">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>The authors thank Anoop Ghanwani for his comments and suggestions and S <t>The authors thank <contact fullname="Anoop Ghanwani"/> for his
tephane Litkowski comments and suggestions and <contact fullname="Stephane Litkowski"/>
and Gunter van de Velde for their careful reviews.</t> and <contact fullname="Gunter Van de Velde"/> for their careful
reviews.</t>
</section>
<section 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>
<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>
<country>United States of America</country>
</postal>
<email>sthoria@cisco.com</email>
</address>
</author>
</section> </section>
<section title="Contributors"> <!-- [rfced] Terminology
<t>In addition to the authors listed on the front page, the follo a) Throughout the text, the following terminology appears to be used
wing inconsistently. Please review these occurrences and let us know if/how they
people have also contributed to this document:</t> may be made consistent.
<author fullname="Ali Sajassi" initials="A." surname="Sajassi">
<organization>Cisco Systems</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country>USA</country>
</postal>
<email>sajassi@cisco.com</email>
</address>
</author>
<author fullname="Samir Thoria" initials="S." surname="Thoria"> Bitmap field vs. bitmap field
<organization>Cisco Systems</organization> [Are these different? For example, "a Bitmap (2 octets) field" vs.
<address> "DF Election Capabilities bitmap field"]
<postal>
<street/>
<city/>
<region/>
<code/>
<country>USA</country>
</postal>
<email>sthoria@cisco.com</email>
</address>
</author>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<references title="Normative References"> b) We updated the text to use the form on the right for consistency
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2 within this document and Cluster 492 (C492). Please let us know of any
119.xml"/> objections.
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7
432.xml"/> active-standby -> active/standby
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 All-active -> All-Active
174.xml"/> DF Election -> DF election (for general use, per RFC 8584)
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 DF Election extended community -> DF Election Extended Community (per RFC 8584
214.xml"/> )
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 'Don't Pre-empt' -> 'Don't Preempt' (per companion doc and IANA registry)
584.xml"/> ESI Label Extended Community -> ESI label extended community (per RFC 7432)
<?rfc include='reference.I-D.draft-ietf-bess-evpn-pref-df-13.xml' ?> Ethernet-AD per-ES -> Ethernet A-D per ES (per RFC 8584)
<xi:include href="https://bib.ietf.org/public/rfc/bibxml6/reference.R.IE Port Mode DF Election -> Port Mode Designated Forwarder Election (per IANA)
EE.802.1AX-2014.xml"/> Single-active -> Single-Active
</references> -->
<!-- [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 and Forwarding (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="Informative References">
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4
364.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5
306.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7
275.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7
348.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8
402.xml"/>
<?rfc include='reference.I-D.draft-ietf-bess-evpn-vpws-fxc-10.xml' ?>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 106 change blocks. 
410 lines changed or deleted 558 lines changed or added

This html diff was produced by rfcdiff 1.48.