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 rdet"> <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="June"/>
<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 multihoming re
ndancy modes. dundancy 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 multihoming, wh ile 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 <t>Although these two multihoming scenarios are widely utilized in data ce
enter and service provider nter and service provider
access networks, there are cases where active/standby multi-homing at the access networks, there are cases where active/standby multihoming at the i
interface level is nterface 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 multihoming. This determinism
m is essential for certain 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 multihoming 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 multihomed to a set of PE no
<t>When a CE device is multi-homed to a set of PE nodes using the <xref ta des 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 connected to the same multihomed CE must synchronize LACP configuration and o
operational data perational data
among them. Historically, the Interchassis Communication Protocol (ICCP) <xre among them. Historically, the Inter-Chassis Communication Protocol (ICCP) <xr
f target="RFC7275"/> 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 EVPN, as described in <xref target="RFC7432"/>, covers the scenario where a C
E is multi-homed to E is multihomed 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 multihoming 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 multihoming 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 multihoming 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 multihoming 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 multihoming
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 multihoming to the CE. In Port-Active redundancy mo
ode, only one of the de, 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>
<section> <name>Overall Advantages</name>
<name>Overall Advantages</name> <t>The use of Port-Active redundancy in EVPN networks provides the follo
<t>The use of Port-Active redundancy in EVPN networks provides the followi wing benefits:</t>
ng benefits:</t> <ol spacing="normal" type="a">
<ol spacing="normal" type="a"> <li>It offers open-standards-based
<li>Port-Active redundancy offers open standards-based active/standby redundancy at the interface level rather than VLAN granular
active/standby redundancy at the interface level, rather than VLAN granula ity <xref target="RFC7432"/>.</li>
rity <xref <li>It eliminates the need for ICCP and LDP <xref target="RFC5036"/>
target="RFC7432"/>.</li> (e.g.,
<li>Port-Active redundancy eliminates the need for ICCP and LDP <xref t Virtual eXtensible Local Area Network (VXLAN) <xref target="RFC7348"/> or
arget="RFC5306"/> (e.g., Segment Routing over IPv6 (SRv6) <xref target="RFC8402"/> may be used in the net
VXLAN <xref work).</li>
target="RFC7348"/> or SRv6 <xref target="RFC8402"/> may be used in the n <li>This mode is agnostic of the underlying technology (MPLS, VXLAN, a
etwork).</li> nd SRv6) and associated services (Layer 2 (L2), Layer 3 (L3), Bridging, E-LINE,
<li>This mode is agnostic of the underlying technology (MPLS, VXLAN, SRv etc.)</li>
6) and associated services (L2, L3, Bridging, E-LINE, etc.)</li> <li>It enables deterministic QoS over MC-LAG attachment circuits.</li>
<li>It enables deterministic QoS over MC-LAG attachment circuits.</li> <li>It is fully compliant with <xref target="RFC7432"/> and does not
<li>Port-Active redundancy 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">
<ol spacing="normal" type="a"> <li>The Ethernet Segment Identifier (ESI) <bcp14>MUST</bcp14> be assigne
<li>The Ethernet-Segment Identifier (ESI) MUST be assigned per access in d per access interface as described
terface as described in <xref target="RFC7432"/>. The ESI can be auto-derived or manually ass
in <xref target="RFC7432"/>. The ESI can be auto-derived or manually ass igned, and the access
igned and the access interface <bcp14>MAY</bcp14> be an L2 or L3 interface.</li>
interface MAY be a Layer-2 or Layer-3 interface.</li> <li>The Ethernet Segment (ES) <bcp14>MUST</bcp14> be configured in Por
t-Active redundancy mode on peering
<li>The Ethernet-Segment (ES) MUST be configured in Port-Active redundan
cy mode on peering
PEs for the specified access interface.</li> 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>
<li>When ESI is configured on a Layer-3 interface, the Ethernet-Segment <li>PEs in the redundancy group leverage the DF election defined in <x
(ES) route (Route ref target="RFC8584"/>
Type-4) can be the only route exchanged by PEs in the redundancy group.< to determine which PE keeps the port in active mode and which PE(s) keep
/li> s it in standby
<li>PEs in the redundancy group leverage the DF election defined in <xre
f target="RFC8584"/>
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 <t>Non-DF routers <bcp14>SHOULD</bcp14> implement a bidirectional bl
and forwarding ocking scheme for all traffic
active state for that Ethernet-Segment.</li> comparable to the Single-Active redundancy mode described in <xref targe
t="RFC7432"/>,
<li>Non-DF routers SHOULD implement a bidirectional blocking scheme for
all traffic
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 multihomed site redu
Single-Active procedure and signals the Single-Active Multihomed site redu ndancy 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>
<dt>Bit 3:</dt>
<dd>Time Synchronization, as described in <xref target="RFC9722"/>.</d
d>
</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[ <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| |T| |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 <t>The algorithm used to determine the DF and Backup Designated
and Backup-DF Elected (BDF) at <relref target="RFC8584" section="3.2"/> i Forwarder (BDF) per <xref target="RFC8584" section="3.2"/> is repeated and su
s repeated and summarized below using only (Es) in the mmarized 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"> <name>Primary/Backup Bits per Ethernet Segment</name>
<t>The EVPN Layer 2 Attributes Extended Community ("L2-Attr") defined in <t>The EVPN L2-Attr Extended Community defined in <xref target="RFC8214"
<xref /> <bcp14>SHOULD</bcp14> be advertised in the Ethernet A-D per ES route to enabl
target="RFC8214"/> SHOULD be advertised in the Ethernet A-D per ES route e fast
to enable 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 <li>The remote ESI Label Extended Community <xref target="RFC7432"/> s
(<xref target="df_algo"/>)</li> ignals the
<li>the remote MAC and/or Ethernet A-D per EVI routes are unchanged, the P a Single-Active redundancy mode (<xref target="df_algo"/>).</li>
nd B bits in the L2-Attr <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 multihoming capabilities. The services may include any L2 EVPN solutions s uch 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 traffic loss 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>
<name>Acknowledgements</name> <back>
<t>The authors thank Anoop Ghanwani for his comments and suggestions and S <references>
tephane Litkowski <name>References</name>
and Gunter van de Velde for their careful reviews.</t> <references>
</section> <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<section title="Contributors"> 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"/>
<t>In addition to the authors listed on the front page, the follo <!--draft-ietf-bess-evpn-fast-df-recovery-12 is now RFC 9722-->
wing <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
people have also contributed to this document:</t> 722.xml"/>
<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"> <!-- [RFC9785] draft-ietf-bess-evpn-pref-df-13 companion doc -->
<organization>Cisco Systems</organization> <reference anchor="RFC9785" target="https://www.rfc-editor.org/info/rfc9785">
<address> <front>
<postal> <title>Preference-Based EVPN Designated Forwarder (DF) Election</title>
<street/> <author fullname="Jorge Rabadan" initials="J." surname="Rabadan" role="edito
<city/> r">
<region/> <organization>Nokia</organization>
<code/> </author>
<country>USA</country> <author fullname="Senthil Sathappan" initials="S." surname="Sathappan">
</postal> <organization>Nokia</organization>
<email>sthoria@cisco.com</email> </author>
</address> <author fullname="Wen Lin" initials="W." surname="Lin">
</author> <organization>Juniper Networks</organization>
</section> </author>
</middle> <author fullname="John Drake" initials="J." surname="Drake">
<!-- *****BACK MATTER ***** --> <organization>Independent</organization>
<back> </author>
<!-- References split into informative and normative --> <author fullname="Ali Sajassi" initials="A." surname="Sajassi">
<organization>Cisco Systems</organization>
</author>
<date month="June" year="2025"/>
</front>
<seriesInfo name="RFC" value="RFC9785"/>
<seriesInfo name="DOI" value="10.17487/RFC9785"/>
</reference>
<references title="Normative References">
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7
432.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8
214.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8
584.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.IE EE.802.1AX-2014.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml6/reference.R.IE EE.802.1AX-2014.xml"/>
</references> </references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
364.xml"/>
<references title="Informative References"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4 036.xml"/>
364.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5 275.xml"/>
306.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 348.xml"/>
275.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 402.xml"/>
348.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 <!--I-D.ietf-bess-evpn-vpws-fxc is now RFC 9744 -->
402.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.974
<?rfc include='reference.I-D.draft-ietf-bess-evpn-vpws-fxc-10.xml' ?> 4.xml"/>
</references>
</references> </references>
<section numbered="false">
<name>Acknowledgements</name>
<t>The authors thank <contact fullname="Anoop Ghanwani"/> for his
comments and suggestions and <contact fullname="Stephane Litkowski"/>
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>
</back> </back>
</rfc> </rfc>
 End of changes. 102 change blocks. 
431 lines changed or deleted 406 lines changed or added

This html diff was produced by rfcdiff 1.48.