rfc9785xml2.original.xml | rfc9785.xml | |||
---|---|---|---|---|
<?xml version="1.0" encoding="US-ASCII"?> | <?xml version='1.0' encoding='utf-8'?> | |||
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ | ||||
<!ENTITY RFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.7432.xml"> | ||||
<!ENTITY RFC8214 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.8214.xml"> | ||||
<!ENTITY RFC7623 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.7623.xml"> | ||||
<!ENTITY RFC8365 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.8365.xml"> | ||||
<!ENTITY RFC8584 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.8584.xml"> | ||||
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.2119.xml"> | ||||
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.8174.xml"> | ||||
<!ENTITY I-D.ietf-bess-evpn-virtual-eth-segment SYSTEM "https://xml2rfc.ietf.org | ||||
/public/rfc/bibxml3/reference.I-D.ietf-bess-evpn-virtual-eth-segment.xml"> | ||||
]> | ||||
<?rfc toc="yes"?> | ||||
<?rfc tocompact="yes"?> | ||||
<?rfc tocdepth="3"?> | ||||
<?rfc tocindent="yes"?> | ||||
<?rfc symrefs="yes"?> | ||||
<?rfc sortrefs="yes"?> | ||||
<?rfc comments="yes"?> | ||||
<?rfc inline="yes"?> | ||||
<?rfc compact="yes"?> | ||||
<?rfc subcompact="no"?> | ||||
<rfc category="std" docName="draft-ietf-bess-evpn-pref-df-13" | ||||
ipr="trust200902" submissionType="IETF" updates="8584"> | ||||
<!--Generated by id2xml 1.5.0 on 2019-12-17T09:50:28Z --> | ||||
<?rfc strict="yes"?> | ||||
<?rfc compact="yes"?> | ||||
<?rfc subcompact="no"?> | ||||
<?rfc symrefs="yes"?> | ||||
<?rfc sortrefs="no"?> | ||||
<?rfc text-list-symbols="o-*+"?> | <!DOCTYPE rfc [ | |||
<!ENTITY nbsp " "> | ||||
<!ENTITY zwsp "​"> | ||||
<!ENTITY nbhy "‑"> | ||||
<!ENTITY wj "⁠"> | ||||
]> | ||||
<?rfc toc="yes"?> | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie tf-bess-evpn-pref-df-13" number="9785" ipr="trust200902" submissionType="IETF" u pdates="8584" obsoletes="" xml:lang="en" consensus="true" tocInclude="true" toc Depth="3" symRefs="true" sortRefs="true" version="3"> | |||
<front> | <front> | |||
<title>Preference-based EVPN DF Election</title> | <title abbrev="Preference-Based EVPN DF Election">Preference-Based EVPN Desi | |||
gnated Forwarder (DF) Election</title> | ||||
<author fullname="J. Rabadan" initials="J." role="editor" | <seriesInfo name="RFC" value="9785"/> | |||
surname="Rabadan"> | <author fullname="Jorge Rabadan" initials="J." role="editor" surname="Rabada | |||
n"> | ||||
<organization>Nokia</organization> | <organization>Nokia</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>520 Almanor Avenue</street> | <street>520 Almanor Avenue</street> | |||
<city>Sunnyvale</city> | <city>Sunnyvale</city> | |||
<region>CA</region> | <region>CA</region> | |||
<code>94085</code> | <code>94085</code> | |||
<country>United States of America</country> | ||||
<country>USA</country> | ||||
</postal> | </postal> | |||
<email>jorge.rabadan@nokia.com</email> | <email>jorge.rabadan@nokia.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Senthil Sathappan" initials="S." surname="Sathappan"> | ||||
<author fullname="S. Sathappan" initials="S." surname="Sathappan"> | ||||
<organization>Nokia</organization> | <organization>Nokia</organization> | |||
<address> | <address> | |||
<email>senthil.sathappan@nokia.com</email> | <email>senthil.sathappan@nokia.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Wen Lin" initials="W." surname="Lin"> | ||||
<author fullname="W. Lin" initials="W." surname="Lin"> | ||||
<organization>Juniper Networks</organization> | <organization>Juniper Networks</organization> | |||
<address> | <address> | |||
<email>wlin@juniper.net</email> | <email>wlin@juniper.net</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="John Drake" initials="J." surname="Drake"> | ||||
<author fullname="J. Drake" initials="J." surname="Drake"> | ||||
<organization>Independent</organization> | <organization>Independent</organization> | |||
<address> | <address> | |||
<email>je_drake@yahoo.com</email> | <email>je_drake@yahoo.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Ali Sajassi" initials="A." surname="Sajassi"> | ||||
<author fullname="A. Sajassi" initials="A." surname="Sajassi"> | ||||
<organization>Cisco Systems</organization> | <organization>Cisco Systems</organization> | |||
<address> | <address> | |||
<email>sajassi@cisco.com</email> | <email>sajassi@cisco.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<date month="May" year="2025"/> | ||||
<date day="9" month="October" year="2023"/> | <area>RTG</area> | |||
<workgroup>bess</workgroup> | ||||
<workgroup>BESS Workgroup</workgroup> | ||||
<abstract> | <abstract> | |||
<t>The Designated Forwarder (DF) in Ethernet Virtual Private Networks | <t>The Designated Forwarder (DF) in Ethernet Virtual Private Networks | |||
(EVPN) is defined as the Provider Edge (PE) router responsible for | (EVPNs) is defined as the Provider Edge (PE) router responsible for | |||
sending Broadcast, Unknown unicast and Multicast traffic (BUM) to a | sending Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a | |||
multi-homed device/network in the case of an all-active multi-homing | multi-homed device/network in the case of an All-Active multi-homing | |||
Ethernet Segment (ES), or BUM and unicast in the case of single-active | Ethernet Segment (ES) or BUM and unicast in the case of Single-Active | |||
multi-homing. The Designated Forwarder is selected out of a candidate | multi-homing. The Designated Forwarder is selected out of a candidate | |||
list of PEs that advertise the same Ethernet Segment Identifier (ESI) to | list of PEs that advertise the same Ethernet Segment Identifier (ESI) to | |||
the EVPN network, according to the Default Designated Forwarder Election | the EVPN network, according to the default DF election | |||
algorithm. While the Default Algorithm provides an efficient and | algorithm. While the default algorithm provides an efficient and | |||
automated way of selecting the Designated Forwarder across different | automated way of selecting the Designated Forwarder across different | |||
Ethernet Tags in the Ethernet Segment, there are some use cases where a | Ethernet Tags in the Ethernet Segment, there are some use cases where a | |||
more 'deterministic' and user-controlled method is required. At the same | more "deterministic" and user-controlled method is required. At the same | |||
time, Network Operators require an easy way to force an on-demand | time, Network Operators require an easy way to force an on-demand | |||
Designated Forwarder switchover in order to carry out some maintenance | Designated Forwarder switchover in order to carry out some maintenance | |||
tasks on the existing Designated Forwarder or control whether a new | tasks on the existing Designated Forwarder or control whether a new | |||
active PE can preempt the existing Designated Forwarder PE.</t> | active PE can preempt the existing Designated Forwarder PE.</t> | |||
<t>This document proposes use of a DF election algorithm that | ||||
<t>This document proposes a Designated Forwarder Election algorithm that | ||||
meets the requirements of determinism and operation control. This | meets the requirements of determinism and operation control. This | |||
document updates RFC8584 by modifying the definition of the DF Election | document updates RFC 8584 by modifying the definition of the DF Election | |||
Extended Community. </t> | Extended Community. </t> | |||
</abstract> | </abstract> | |||
</front> | </front> | |||
<middle> | <middle> | |||
<section anchor="sect-1" title="Introduction"> | <section anchor="sect-1" numbered="true" toc="default"> | |||
<section anchor="sect-1.1" title="Problem Statement"> | <name>Introduction</name> | |||
<t><xref target="RFC7432"/> defines the Designated Forwarder (DF) in | <section anchor="sect-1.1" numbered="true" toc="default"> | |||
<name>Problem Statement</name> | ||||
<t><xref target="RFC7432" format="default"/> defines the Designated Forw | ||||
arder (DF) in | ||||
EVPN networks as the PE responsible for sending Broadcast, Unknown | EVPN networks as the PE responsible for sending Broadcast, Unknown | |||
unicast and Multicast traffic (BUM) to a multi-homed device/network in | Unicast, and Multicast (BUM) traffic to a multi-homed device/network in | |||
the case of an all-active multi-homing Ethernet Segment or BUM and | the case of an All-Active multi-homing Ethernet Segment or BUM and | |||
unicast traffic to a multi-homed device or network in the case of | unicast traffic to a multi-homed device or network in the case of | |||
single-active multi-homing. The Designated Forwarder is selected out | Single-Active multi-homing. The Designated Forwarder is selected out | |||
of a candidate list of PEs that advertise the Ethernet Segment | of a candidate list of PEs that advertise the Ethernet Segment | |||
Identifier (ESI) to the EVPN network and according to the Designated | Identifier (ESI) to the EVPN network and according to the DF election al | |||
Forwarder Election Algorithm, or DF Alg as per <xref | gorithm or to DF Alg as per <xref target="RFC8584" format="default"/>.</t> | |||
target="RFC8584"/>.</t> | ||||
<t>While the Default Designated Forwarder Algorithm <xref | <t>While the default DF algorithm or the Highest Random Weight (HRW) alg | |||
target="RFC7432"/> or the Highest Random Weight algorithm (HRW) <xref | orithm <xref target="RFC8584" format="default"/> provide an efficient and automa | |||
target="RFC8584"/> provide an efficient and automated way of selecting | ted way of selecting | |||
the Designated Forwarder across different Ethernet Tags in the | the Designated Forwarder across different Ethernet Tags in the | |||
Ethernet Segment, there are some use-cases where a more | Ethernet Segment, there are some use cases where a more | |||
user-controlled method is required. At the same time, Network | user-controlled method is required. At the same time, Network | |||
Operators require an easy way to force an on-demand Designated | Operators require an easy way to force an on-demand Designated Forwarde | |||
Forwarder switchover in order to carry out some maintenance tasks on | r switchover in order to carry out some maintenance tasks on | |||
the existing Designated Forwarder or control whether a new active PE | the existing Designated Forwarder or control whether a new active PE | |||
can preempt the existing Designated Forwarder PE.</t> | can preempt the existing Designated Forwarder PE.</t> | |||
</section> | </section> | |||
<section anchor="sect-1.2" numbered="true" toc="default"> | ||||
<section anchor="sect-1.2" title="Solution Requirements"> | <name>Solution Requirements</name> | |||
<t>The procedures described in this document meet the following | <t>The procedures described in this document meet the following | |||
requirements:<list style="letters"> | requirements:</t> | |||
<ol spacing="normal" type="a"><li> | ||||
<t>The solution provides an administrative preference option so | <t>The solution provides an administrative preference option so | |||
that the user can control in what order the candidate PEs may | that the user can control in what order the candidate PEs may | |||
become Designated Forwarder, assuming they are all operationally | become the Designated Forwarder, assuming they are all operationally | |||
ready to take over as Designated Forwarder. The operator can | ready to take over as the Designated Forwarder. The operator can | |||
determine whether the Highest-Preference or Lowest-Preference PE | determine whether the Highest-Preference or Lowest-Preference PE | |||
among the PEs in the Ethernet Segment will be elected as | among the PEs in the Ethernet Segment will be elected as | |||
Designated Forwarder, based on the DF Algorithms described in this | the Designated Forwarder, based on the DF algorithms described in th is | |||
document.</t> | document.</t> | |||
</li> | ||||
<t>The extensions in this document work for <xref | <li> | |||
target="RFC7432"/> Ethernet Segments and virtual Ethernet | <t>The extensions described in this document work for Ethernet Segme | |||
Segments, as defined in <xref | nts <xref target="RFC7432" format="default"/> and virtual Ethernet | |||
target="I-D.ietf-bess-evpn-virtual-eth-segment"/>.</t> | Segments as defined in <xref target="RFC9784" format="default"/>.</t | |||
> | ||||
</li> | ||||
<li> | ||||
<t>The user may force a PE to preempt the existing Designated | <t>The user may force a PE to preempt the existing Designated | |||
Forwarder for a given Ethernet Tag without re-configuring all the | Forwarder for a given Ethernet Tag without reconfiguring all the | |||
PEs in the Ethernet Segment, by simply modifying the existing | PEs in the Ethernet Segment, by simply modifying the existing | |||
administrative preference in that PE.</t> | administrative preference in that PE.</t> | |||
</li> | ||||
<li anchor="DP-capability"> | ||||
<t>The solution allows an option to NOT preempt the current | <t>The solution allows an option to NOT preempt the current | |||
Designated Forwarder ("Don't Preempt" capability), even if the | Designated Forwarder (the "Don't Preempt" Capability), even if the | |||
former Designated Forwarder PE comes back up after a failure. This | former Designated Forwarder PE comes back up after a failure. This | |||
is also known as "non-revertive" behavior, as opposed to the <xref | is also known as "non-revertive" behavior, as opposed to the DF elec | |||
target="RFC7432"/> Designated Forwarder election procedures that | tion procedures <xref target="RFC7432" format="default"/> that | |||
are always revertive (because the winner PE of the default | are always revertive (because the winner PE of the default | |||
Designated Forwarder election algorithm always takes over as the | DF election algorithm always takes over as the | |||
operational Designated Forwarder).</t> | operational Designated Forwarder).</t> | |||
</li> | ||||
<t>The procedures described in this document support single-active | <li> | |||
and all-active multi-homing Ethernet Segments.</t> | <t>The procedures described in this document support Single-Active | |||
</list></t> | and All-Active multi-homing Ethernet Segments.</t> | |||
</li> | ||||
</ol> | ||||
</section> | </section> | |||
<section anchor="sect-1.3" numbered="true" toc="default"> | ||||
<section anchor="sect-1.3" title="Solution Overview"> | <name>Solution Overview</name> | |||
<t>To provide a solution that satisfies the above requirements, we | <t>To provide a solution that satisfies the above requirements, we | |||
introduce two new DF Algorithms that can be advertised in the DF | introduce two new DF algorithms that can be advertised in the DF | |||
Election Extended Community <xref target="sect-3"/>. Carried with the | Election Extended Community (<xref target="sect-3" format="default"/>). | |||
new DF Election Extended Community variants are a DF election | Carried with the | |||
preference advertised for each PE, that influences which PE will | new DF Election Extended Community variants is a DF election | |||
become DF <xref target="sect-4.1"/>. The advertised DF election | preference advertised for each PE that influences which PE will | |||
become the DF (<xref target="sect-4.1" format="default"/>). The advertis | ||||
ed DF election | ||||
preference can dynamically vary from the administratively configured | preference can dynamically vary from the administratively configured | |||
preference to provide non-revertive behavior <xref | preference to provide non-revertive behavior (<xref target="sect-4.3" fo | |||
target="sect-4.3"/>. An optional solution is discussed in <xref | rmat="default"/>). In <xref target="sect-4.2" format="default"/>, an optional so | |||
target="sect-4.2"/>, for use in Ethernet segments that support large | lution is discussed for use in Ethernet Segments that supports large numbers of | |||
numbers of Ethernet Tags and therefore need to balance load among | Ethernet Tags and therefore needs to balance load among | |||
multiple DFs. </t> | multiple DFs. </t> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="sect-2" numbered="true" toc="default"> | ||||
<name>Requirements Language and Terminology</name> | ||||
<t> | ||||
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU | ||||
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL | ||||
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14> | ||||
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", | ||||
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to | ||||
be interpreted as | ||||
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> | ||||
when, and only when, they appear in all capitals, as shown here. | ||||
</t> | ||||
<section anchor="sect-2" title="Requirements Language and Terminology"> | <dl spacing="normal" newline="false"> | |||
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | <dt>AC:</dt><dd>Attachment Circuit. An AC has an Ethernet Tag | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | associated to it.</dd> | |||
"OPTIONAL" in this document are to be interpreted as described in BCP 14 | <dt>CE:</dt><dd>Customer Equipment router</dd> | |||
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, | <dt>DF:</dt><dd>Designated Forwarder</dd> | |||
they appear in all capitals, as shown here.</t> | <dt>DF Alg:</dt><dd>Refers to the DF election | |||
algorithm, which is sometimes shortened to "Alg" in this document.</dd> | ||||
<t><list style="symbols"> | <dt>DP:</dt><dd>Refers to the "Don't Preempt" Capability in the | |||
<t>AC - Attachment Circuit. An AC has an Ethernet Tag associated to | DF Election Extended Community.</dd> | |||
it.</t> | <dt>ENNI:</dt><dd>External Network-Network Interface</dd> | |||
<dt>ES and vES:</dt><dd>Ethernet Segment and virtual Ethernet Segment.</ | ||||
<t>CE - Customer Equipment router.</t> | dd> | |||
<dt>Ethernet A-D per EVI route:</dt><dd>Refers to Route Type 1 or Auto-D | ||||
<t>DF - Designated Forwarder.</t> | iscovery per | |||
EVPN Instance route <xref target="RFC7432" format="default"/>.</dd> | ||||
<t>DF Alg - refers to Designated Forwarder Election Algorithm. This | <dt>EVC:</dt><dd>Ethernet Virtual Circuit</dd> | |||
is sometimes shortened to “Alg” in this document.</t> | <dt>EVI:</dt><dd>EVPN Instance</dd> | |||
<dt>Ethernet Tag:</dt><dd>Used to represent a broadcast domain that is | ||||
<t>DP - refers to the "Don't Preempt" (me) capability in the | configured on a given Ethernet Segment for the purpose of DF election. N | |||
Designated Forwarder Election extended community.</t> | ote that any of the following may be used to | |||
represent a broadcast domain: VLAN IDs (VIDs) (including Q-in-Q tags), c | ||||
<t>ENNI - Ethernet Network to Network Interface.</t> | onfigured | |||
IDs, VXLAN Network Identifiers (VNIs), normalized VIDs, Service | ||||
<t>ES and vES - Ethernet Segment and virtual Ethernet Segment.</t> | Instance Identifiers (I-SIDs), etc., as long as the representation of th | |||
e | ||||
<t>Ethernet A-D per EVI route - refers to <xref target="RFC7432"/> | broadcast domains is configured consistently across the multi-homed | |||
route type 1 or Auto-Discovery per EVPN Instance route.</t> | PEs attached to that Ethernet Segment. The Ethernet Tag value | |||
<bcp14>MUST NOT</bcp14> be zero.</dd> | ||||
<t>EVC - Ethernet Virtual Circuit.</t> | <dt>HRW:</dt><dd>Highest Random Weight, as per <xref target="RFC8584" | |||
format="default"/>.</dd> | ||||
<t>EVI - EVPN Instance.</t> | <dt>OAM:</dt><dd>Operations, Administration, and Maintenance.</dd> | |||
</dl> | ||||
<t>Ethernet Tag - used to represent a Broadcast Domain that is | ||||
configured on a given Ethernet Segment for the purpose of Designated | ||||
Forwarder election. Note that any of the following may be used to | ||||
represent a Broadcast Domain: VIDs (including Q-in-Q tags), | ||||
configured IDs, VNI (VXLAN Network Identifiers), normalized VID, | ||||
I-SIDs (Service Instance Identifiers), etc., as long as the | ||||
representation of the broadcast domains is configured consistently | ||||
across the multi-homed PEs attached to that Ethernet Segment. The | ||||
Ethernet Tag value MUST NOT be zero.</t> | ||||
<t>HRW - Highest Random Weight, as per <xref target="RFC8584"/>.</t> | ||||
<t>OAM - refers to Operations And Maintenance protocols.</t> | ||||
</list></t> | ||||
</section> | </section> | |||
<section anchor="sect-3" numbered="true" toc="default"> | ||||
<name>EVPN BGP Attribute Extensions</name> | ||||
<section anchor="sect-3" title="EVPN BGP Attributes Extensions"> | <t>This solution reuses and extends the DF Election | |||
<t>This solution reuses and extends the Designated Forwarder Election | Extended Community defined in <xref target="RFC8584" format="default"/> th | |||
Extended Community defined in <xref target="RFC8584"/> that is | at is | |||
advertised along with the Ethernet Segment route. It does so by | advertised along with the Ethernet Segment route. It does so by | |||
replacing the last two reserved octets of the DF Election Extended | replacing the last two reserved octets of the DF Election Extended | |||
Community when the DF Algorithm is set to Highest-Preference or | Community when the DF algorithm is set to Highest-Preference or | |||
Lowest-Preference. This document also defines a new capability referred | Lowest-Preference. This document also defines a new capability referred | |||
to as the "Don't Preempt" capability, that MAY be used with | to as the "Don't Preempt" Capability, which <bcp14>MAY</bcp14> be used wit | |||
Highest-Preference or Lowest-Preference DF Algorithms. The format of the | h | |||
DF Election Extended Community that is used in this document | Highest-Preference or Lowest-Preference Algorithms. The format of the | |||
DF Election Extended Community used in this document is as | ||||
follows:</t> | follows:</t> | |||
<figure anchor="df-election-extended-community"> | ||||
<figure anchor="df-election-extended-community" | <name>DF Election Extended Community</name> | |||
title="DF Election Extended Community"> | <artwork name="" type="" align="left" alt=""><![CDATA[ | |||
<artwork><![CDATA[ | ||||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type=0x06 | Sub-Type(0x06)| RSV | DF Alg | Bitmap ~ | | Type=0x06 | Sub-Type(0x06)| RSV | DF Alg | Bitmap ~ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
~ Bitmap | Reserved | DF Preference (2 octets) | | ~ Bitmap | Reserved | DF Preference (2 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t>Where the above fields are defined as follows:</t> | <t>Where the above fields are defined as follows:</t> | |||
<ul spacing="normal"> | ||||
<t><list style="symbols"> | <li><t>The DF algorithm can have the following values:</t> | |||
<t>DF Algorithm can have the following values:<list style="symbols"> | <ul spacing="normal"> | |||
<t>Alg 0 - Default Designated Forwarder Election algorithm, or | <li>Alg 0 - Default DF election algorithm, i.e., | |||
modulus-based algorithm as per <xref target="RFC7432"/>.</t> | the modulus-based algorithm as per <xref target="RFC7432" | |||
format="default"/>.</li> | ||||
<t>Alg 1 - HRW algorithm as per <xref target="RFC8584"/>.</t> | <li>Alg 1 - HRW algorithm as per <xref target="RFC8584" format="defa | |||
ult"/>.</li> | ||||
<t>Alg 2 - Highest-Preference algorithm (this document <xref | <li>Alg 2 - Highest-Preference Algorithm (<xref target="sect-4.1" fo | |||
target="sect-4.1"/>).</t> | rmat="default"/>).</li> | |||
<li>Alg 3 - Lowest-Preference Algorithm (<xref | ||||
<t>Alg TBD - Lowest-Preference algorithm (this document <xref | target="sect-4.1" format="default"/>).</li> | |||
target="sect-4.1"/>). TBD will be replaced by the allocated | </ul> | |||
value at the time of publication.</t> | </li> | |||
</list></t> | <li><t>Bitmap (2 octets) encodes "capabilities" <xref target="RFC8584" | |||
</list><list style="symbols"> | format="default"/>, whereas this document defines the "Don't Preempt" | |||
<t>Bitmap (2 octets) encodes "capabilities" <xref | Capability, which is used to indicate if a PE supports a non-revertive | |||
target="RFC8584"/>, where this document defines the "Don't Preempt" | behavior:</t> | |||
capability, used to indicate if a PE supports a non-revertive | <figure anchor="bitmap-field-in-the-df-election-extended-community"> | |||
behavior:</t> | <name>Bitmap Field in the DF Election Extended Community</name> | |||
</list></t> | <artwork name="" type="" align="left" alt=""><![CDATA[ | |||
<figure anchor="bitmap-field-in-the-df-election-extended-community" | ||||
title="Bitmap field in the DF Election Extended Community"> | ||||
<artwork><![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| | | |D|A| | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<ul spacing="normal"> | ||||
<t><list style="empty"> | <li>Bit 0 (corresponds to Bit 24 of the DF | |||
<t><list style="symbols"> | Election Extended Community, and it is defined by this document): | |||
<t>Bit 0 (corresponds to Bit 24 of the Designated Forwarder | The D bit, or "Don't Preempt" Capability, determines if the | |||
Election Extended Community and it is defined by this document): | PE advertising the Ethernet Segment route requests the remote PEs | |||
the D bit or 'Don't Preempt' bit (DP hereafter), determines if | in the Ethernet Segment to not preempt it as the Designated | |||
the PE advertising the Ethernet Segment route requests the | Forwarder. The default value is DP=0, which is compatible with the | |||
remote PEs in the Ethernet Segment not to preempt it as | 'preempt' or 'revertive' behavior in the default DF algorithm | |||
Designated Forwarder. The default value is DP=0, which is | <xref target="RFC7432" format="default"/>. The "Don't Preempt" Capab | |||
compatible with the 'preempt' or 'revertive' behavior in the | ility is | |||
Default DF Algorithm <xref target="RFC7432"/>. The DP capability | supported by the Highest-Preference or Lowest-Preference | |||
is supported by the Highest-Preference or Lowest-Preference DF | Algorithms. The procedures of the "Don't Preempt" Capability for | |||
Algorithms. The procedures of the "Don't Preempt" capability for | other DF algorithms are out of the scope of this document. The | |||
other DF Algorithms are out of the scope of this document. The | procedures of the "Don't Preempt" Capability for the | |||
procedures of the "Don't Preempt" capability for the | Highest-Preference and Lowest-Preference Algorithms are | |||
Highest-Preference and Lowest-Preference DF Algorithms are | described in <xref target="sect-4.1" format="default"/>.</li> | |||
described in <xref target="sect-4.1"/>.</t> | <li>Bit 1: AC-Influenced DF (AC-DF) election is | |||
described in <xref target="RFC8584" format="default"/>. When set | ||||
<t>Bit 1: AC-DF or AC-Influenced Designated Forwarder Election | to 1, it indicates the desire to use AC-DF with the rest of the PEs | |||
is described in <xref target="RFC8584"/>. When set to 1, it | in the Ethernet | |||
indicates the desire to use AC-Influenced Designated Forwarder | Segment. The AC-DF capability bit <bcp14>MAY</bcp14> be set along | |||
Election with the rest of the PEs in the Ethernet Segment. The | with the "Don't Preempt" Capability and Highest-Preference or | |||
AC-DF capability bit MAY be set along with the DP capability and | Lowest-Preference Algorithms.</li> | |||
the Highest-Preference or Lowest-Preference DF Algorithms.</t> | </ul> | |||
</list></t> | </li> | |||
</list><list style="symbols"> | <li>Designated Forwarder (DF) Preference: | |||
<t>Designated Forwarder (DF) Preference (described in this | Defines a 2-octet value that indicates the PE preference to become the | |||
document): defines a 2-octet value that indicates the PE preference | Designated Forwarder in the Ethernet Segment, as described in <xref | |||
to become the Designated Forwarder in the Ethernet Segment, as | target="sect-4.1" format="default"/>. The allowed values are within | |||
described in <xref target="sect-4.1"/>. The allowed values are | the range 0-65535, and the default value <bcp14>MUST</bcp14> be | |||
within the range 0-65535, and the default value MUST be 32767. This | 32767. This value is the midpoint in the allowed Preference range of | |||
value is the midpoint in the allowed Preference range of values, | values, which gives the operator the flexibility of choosing a | |||
which gives the operator the flexibility of choosing a significant | significant number of values, above or below the default Preference. A | |||
number of values, above or below the default Preference. A | numerically higher or lower value of this field is more preferred for | |||
numerically higher or lower value of this field is more preferred | DF election depending on the DF algorithm being | |||
for Designated Forwarder election depending on the DF Algorithm | used, as explained in <xref target="sect-4.1" format="default"/>. The | |||
being used, as explained in <xref target="sect-4.1"/>. The | Designated Forwarder Preference field is specific to | |||
Designated Forwarder Preference field is specific to DF Algorithms | Highest-Preference and Lowest-Preference Algorithms, and this document d | |||
Highest-Preference and Lowest-Preference, and this document does not | oes not | |||
define any meaning for other algorithms. If the DF Algorithm is | define any meaning for other algorithms. If the DF algorithm is | |||
different from Highest-Preference or Lowest-Preference, these two | different from Highest-Preference or Lowest-Preference, these 2 | |||
octets can be encoded differently.</t> | octets can be encoded differently.</li> | |||
<li>RSV and Reserved fields (from bit 16 to bit 18, and from bit 40 to | ||||
<t>RSV and Reserved fields (from bit 16 to bit 18, and from bit 40 | 47): When the DF algorithm is set to Highest-Preference or | |||
to 47): when DF Algorithm is set to Highest-Preference or | Lowest-Preference, the values are set to zero when | |||
Lowest-Preference algorithm, the values are set to zero when | advertising the Ethernet Segment route, and they are ignored when | |||
advertising the Ethernet Segment route, and they are ignored when | receiving the Ethernet Segment route.</li> | |||
receiving the Ethernet Segment route.</t> | </ul> | |||
</list></t> | ||||
</section> | </section> | |||
<section anchor="sect-4" numbered="true" toc="default"> | ||||
<section anchor="sect-4" title="Solution description"> | <name>Solution Description</name> | |||
<t><xref target="es-and-deterministic-df-election"/> illustrates an | <t><xref target="es-and-deterministic-df-election" format="default"/> illu | |||
strates an | ||||
example that will be used in the description of the solution.</t> | example that will be used in the description of the solution.</t> | |||
<figure anchor="es-and-deterministic-df-election"> | ||||
<figure anchor="es-and-deterministic-df-election" | <name>Preference-Based DF Election</name> | |||
title="Preference-based DF Election"> | <artwork name="" type="" align="left" alt=""><![CDATA[ | |||
<artwork><![CDATA[ | EVPN Network | |||
EVPN network | ||||
+-------------------+ | +-------------------+ | |||
| +-------+ ENNI Aggregation | | +-------+ ENNI Aggregation | |||
| <---ESI1,500 | PE1 | /\ +----Network---+ | | <---ESI1,500 | PE1 | /\ +----Network---+ | |||
| <-----ESI2,100 | |===||=== | | | <-----ESI2,100 | |===||=== | | |||
| | |===||== \ vES1 | +----+ | | | |===||== \ vES1 | +----+ | |||
+-----+ | | \/ |\----------------+CE1 | | +-----+ | | \/ |\----------------+CE1 | | |||
CE3--+ PE4 | +-------+ | \ ------------+ | | CE3--+ PE4 | +-------+ | \ ------------+ | | |||
+-----+ | | \ / | +----+ | +-----+ | | \ / | +----+ | |||
| | | X | | | | | X | | |||
| <---ESI1,255 +-----+============ \ | | | <---ESI1,255 +-----+============ \ | | |||
| <-----ESI2,200 | PE2 |========== \ vES2 | +----+ | | <-----ESI2,200 | PE2 |========== \ vES2 | +----+ | |||
| +-----+ | \ ----------+CE2 | | | +-----+ | \ ----------+CE2 | | |||
| | | --------------+ | | | | | --------------+ | | |||
| +-----+ ----------------------+ | | | +-----+ ----------------------+ | | |||
| <-----ESI2,300 | PE3 +--/ | | +----+ | | <-----ESI2,300 | PE3 +--/ | | +----+ | |||
| +-----+ +--------------+ | | +-----+ +--------------+ | |||
--------------------+]]></artwork> | --------------------+]]></artwork> | |||
</figure> | </figure> | |||
<t><xref target="es-and-deterministic-df-election" format="default"/> show | ||||
<t><xref target="es-and-deterministic-df-election"/> shows three PEs | s three PEs | |||
that are connecting EVCs coming from the Aggregation Network to their | that are connecting EVCs coming from the Aggregation Network to their | |||
EVIs in the EVPN network. CE1 is connected to vES1 - that spans PE1 and | EVIs in the EVPN network. CE1 is connected to vES1, which spans PE1 and | |||
PE2 - and CE2 is connected to vES2, that is attached to PE1, PE2 and | PE2, and CE2 is connected to vES2, which is attached to PE1, PE2, and | |||
PE3.</t> | PE3.</t> | |||
<t>If the algorithm chosen for vES1 and vES2 is the | ||||
<t>If the algorithm chosen for vES1 and vES2 is DF Algorithm | Highest-Preference or Lowest-Preference Algorithm, the PEs may become the | |||
Highest-Preference or Lowest-Preference, the PEs may become Designated | Designated | |||
Forwarder irrespective of their IP address and based on the | Forwarder irrespective of their IP address and based on the | |||
administrative Preference value. The following sections provide some | administrative preference value. The following sections provide some | |||
examples of the procedures and how they are applied in the use-case of | examples of the procedures and how they are applied in the use case of | |||
<xref target="es-and-deterministic-df-election"/>.</t> | <xref target="es-and-deterministic-df-election" format="default"/>.</t> | |||
<section anchor="sect-4.1" numbered="true" toc="default"> | ||||
<name>Use of the Highest-Preference and Lowest-Preference Algorithm</nam | ||||
e> | ||||
<section anchor="sect-4.1" | <t>Assuming the operator wants to control -- in a flexible way -- what | |||
title="Use of the Highest-Preference and Lowest Preference Algori | ||||
thm"> | ||||
<t>Assuming the operator wants to control - in a flexible way - what | ||||
PE becomes the Designated Forwarder for a given virtual Ethernet | PE becomes the Designated Forwarder for a given virtual Ethernet | |||
Segment and the order in which the PEs become Designated Forwarder in | Segment and the order in which the PEs become a Designated Forwarder in | |||
case of multiple failures, the Highest-Preference or Lowest-Preference | case of multiple failures, the Highest-Preference or Lowest-Preference | |||
algorithms can be used. Using the example in <xref | Algorithms can be used. Per the example in <xref target="es-and-determin | |||
target="es-and-deterministic-df-election"/>, these algorithms are used | istic-df-election" format="default"/>, these | |||
algorithms are used | ||||
as follows:</t> | as follows:</t> | |||
<ol spacing="normal" type="a"> | ||||
<t><list style="letters"> | <li><t>vES1 and vES2 are now configurable with three optional | |||
<t>vES1 and vES2 are now configurable with three optional | parameters that are signaled in the DF Election | |||
parameters that are signaled in the Designated Forwarder Election | Extended Community. These parameters are the Preference, | |||
extended community. These parameters are the Preference, | Preemption (or "Don't Preempt" Capability) option, and DF algorithm. We | |||
Preemption option (or "Don't Preempt" option) and DF Algorithm. We | will | |||
will represent these parameters as (Pref,DP,Alg). For instance, | represent these parameters as (Pref, DP, Alg). For instance, vES1 | |||
vES1 (Pref,DP,Alg) is configured as (500,0,Highest-Preference) in | (Pref, DP, Alg) is configured as:</t> | |||
PE1, and (255,0,Highest-Preference) in PE2. vES2 is configured as | <ul empty="true" spacing="compact"> | |||
(100,0,Highest-Preference), (200,0,Highest-Preference) and | <li>(500, 0, Highest-Preference) in PE1,</li> | |||
(300,0,Highest-Preference) in PE1, PE2 and PE3 respectively.</t> | <li>(255, 0, Highest-Preference) in PE2.</li> | |||
</ul> | ||||
<t>vES2 is configured as</t> | ||||
<ul empty="true" spacing="compact"> | ||||
<li>(100, 0, Highest-Preference) in PE1,</li> | ||||
<li>(200, 0, Highest-Preference) in PE2, and</li> | ||||
<li>(300, 0, Highest-Preference) in PE3.</li> | ||||
</ul> | ||||
</li> | ||||
<li> | ||||
<t>The PEs advertise an Ethernet Segment route for each virtual | <t>The PEs advertise an Ethernet Segment route for each virtual | |||
Ethernet Segment, including the three parameters indicated in 'a' | Ethernet Segment, including the three parameters indicated in (a) | |||
above, in the Designated Forwarder Election Extended Community | above, in the DF Election Extended Community | |||
(encoded as described in <xref target="sect-3"/>).</t> | (encoded as described in <xref target="sect-3" format="default"/>).< | |||
/t> | ||||
<t>According to <xref target="RFC8584"/>, each PE will run the | </li> | |||
Designated Forwarder election algorithm upon expiration of the DF | <li> | |||
<t>According to <xref target="RFC8584" format="default"/>, each PE w | ||||
ill run the | ||||
DF election algorithm upon expiration of the DF | ||||
Wait timer. Each PE runs the Highest-Preference or | Wait timer. Each PE runs the Highest-Preference or | |||
Lowest-Preference DF Algorithm for each Ethernet Segment as | Lowest-Preference Algorithm for each Ethernet Segment as | |||
follows: <list style="symbols"> | follows: </t> | |||
<t>The PE will check the DF Algorithm value in each Ethernet | <ul spacing="normal"> | |||
<li> | ||||
<t>The PE will check the DF algorithm value in each Ethernet | ||||
Segment route, and assuming all the Ethernet Segment routes | Segment route, and assuming all the Ethernet Segment routes | |||
(including the local route) are consistent in this DF | (including the local route) are consistent in this DF | |||
Algorithm (that is, all are configured for Highest-Preference | algorithm (that is, all are configured for Highest-Preference | |||
or Lowest-Preference, but not a mix), the PE runs the | or Lowest-Preference, but not a mix), the PE runs the | |||
procedure in this section. Otherwise, the procedure falls back | procedure in this section. Otherwise, the procedure falls back | |||
to <xref target="RFC7432"/> Default Algorithm. The | to the default DF algorithm <xref target="RFC7432" format="defau | |||
Highest-Preference and Lowest-Preference Algorithms are | lt"/>. | |||
different Algorithms, therefore if two PEs configured for | The Highest-Preference and Lowest-Preference Algorithms are | |||
Highest-Preference and Lowest-Preference respectively, are | different algorithms; therefore, if two PEs configured for | |||
Highest-Preference and Lowest-Preference, respectively, are | ||||
attached to the same Ethernet Segment, the operational | attached to the same Ethernet Segment, the operational | |||
Designated Forwarder Election Algorithm will fall back to the | DF election algorithm will fall back to the | |||
Default Algorithm.</t> | default DF algorithm.</t> | |||
</li> | ||||
<li> | ||||
<t>If all the PEs attached to the Ethernet Segment advertise | <t>If all the PEs attached to the Ethernet Segment advertise | |||
Highest-Preference Algorithm, each PE builds a list of | the Highest-Preference Algorithm, each PE builds a list of | |||
candidate PEs, ordered by Preference value from the | candidate PEs, ordered by preference value from the | |||
numerically highest value to lowest value. E.g., PE1 builds a | numerically highest value to lowest value. For example, PE1 buil | |||
ds a | ||||
list of candidate PEs for vES1 ordered by the Preference, from | list of candidate PEs for vES1 ordered by the Preference, from | |||
high to low: <PE1, PE2> (since PE1's preference is more | high to low: <PE1, PE2> (since PE1's preference is more | |||
preferred than PE2's). Hence, PE1 becomes the Designated | preferred than PE2's). Hence, PE1 becomes the Designated | |||
Forwarder for vES1. In the same way, PE3 becomes the | Forwarder for vES1. In the same way, PE3 becomes the | |||
Designated Forwarder for vES2.</t> | Designated Forwarder for vES2.</t> | |||
</li> | ||||
<li> | ||||
<t>If all the PEs attached to the Ethernet Segment advertise | <t>If all the PEs attached to the Ethernet Segment advertise | |||
Lowest-Preference Algorithm, then the candidate list is | the Lowest-Preference Algorithm, then the candidate list is | |||
ordered from the numerically lowest Preference value to the | ordered from the numerically lowest preference value to the | |||
highest Preference value. E.g., PE1's ordered list for vES1 is | highest preference value. For example, PE1's ordered list for vE | |||
S1 is | ||||
<PE2, PE1>. Hence, PE2 becomes the Designated Forwarder | <PE2, PE1>. Hence, PE2 becomes the Designated Forwarder | |||
for vES1. In the same way, PE1 becomes the Designated | for vES1. In the same way, PE1 becomes the Designated | |||
Forwarder for vES2.</t> | Forwarder for vES2.</t> | |||
</list></t> | </li> | |||
</ul> | ||||
<t>Assuming some maintenance tasks had to be executed on a PE the | </li> | |||
<li> | ||||
<t>Assuming some maintenance tasks had to be executed on a PE, the | ||||
operator may want to make sure the PE is not the Designated | operator may want to make sure the PE is not the Designated | |||
Forwarder for the Ethernet Segment so that the impact on the | Forwarder for the Ethernet Segment so that the impact on the | |||
service is minimized. E.g., if PE3 is going on maintenance and the | service is minimized. For example, if PE3 is going on maintenance an | |||
DF Algorithm is Highest-Preference, the operator could change | d the | |||
vES2's Preference on PE3 from 300 to e.g., 50 (hence, the Ethernet | DF algorithm is Highest-Preference, the operator could change | |||
Segment route from PE3 is updated with the new preference value) | vES2's Preference on PE3 from 300 to, e.g., 50 (hence, the Ethernet | |||
Segment route from PE3 is updated with the new preference value), | ||||
so that PE2 is forced to take over as Designated Forwarder for | so that PE2 is forced to take over as Designated Forwarder for | |||
vES2 (irrespective of the DP capability). Once the maintenance | vES2 (irrespective of the "Don't Preempt" Capability). Once the main tenance | |||
task on PE3 is over, the operator could decide to leave the latest | task on PE3 is over, the operator could decide to leave the latest | |||
configured preference value or configure the initial preference | configured preference value or configure the initial preference | |||
value back. A similar procedure can be used for DF Algorithm | value back. A similar procedure can be used for the | |||
Lowest-Preference too, that is, suppose the algorithm for vES2 is | Lowest-Preference Algorithm too. For example, suppose the algorithm | |||
for vES2 is | ||||
Lowest-Preference, and PE1 (the DF) goes on maintenance mode. The | Lowest-Preference, and PE1 (the DF) goes on maintenance mode. The | |||
operator could change vES2's Preference on PE1 from 100 to e.g., | operator could change vES2's Preference on PE1 from 100 to, e.g., | |||
250, so that PE2 is forced to take over as Designated Forwarder | 250, so that PE2 is forced to take over as the Designated Forwarder | |||
for vES2.</t> | for vES2.</t> | |||
</li> | ||||
<li> | ||||
<t>In case of equal Preference in two or more PEs in the Ethernet | <t>In case of equal Preference in two or more PEs in the Ethernet | |||
Segment, the DP bit and the numerically lowest IP address of the | Segment, the "Don't Preempt" Capability and the numerically lowest I P address of the | |||
candidate PE(s) are used as tiebreakers. The procedures for the | candidate PE(s) are used as tiebreakers. The procedures for the | |||
use of the DP bit are specified in <xref target="sect-4.3"/>.If | use of the "Don't Preempt" Capability are specified in <xref target= "sect-4.3" format="default"/>. If | |||
more than one PE is advertising itself as the preferred Designated | more than one PE is advertising itself as the preferred Designated | |||
Forwarder, an implementation MUST first select the PE advertising | Forwarder, an implementation <bcp14>MUST</bcp14> first select the PE | |||
the DP bit set, and then select the PE with the lowest IP address | advertising | |||
(if the DP bit selection does not yield a unique candidate). The | the "Don't Preempt" Capability set, and then select the PE with the | |||
PE's IP address is the address used in the candidate list and it | lowest IP address | |||
(if the "Don't Preempt" Capability selection does not yield a unique | ||||
candidate). The | ||||
PE's IP address is the address used in the candidate list, and it | ||||
is derived from the Originating Router's IP address of the | is derived from the Originating Router's IP address of the | |||
Ethernet Segment route. In case PEs use the Originating Router's | Ethernet Segment route. In case PEs use the Originating Router's | |||
IP address of different families, an IPv4 address is always | IP address of different families, an IPv4 address is always | |||
considered numerically lower than an IPv6 address. Some examples | considered numerically lower than an IPv6 address. Some examples | |||
of the use of the DP bit and IP address tiebreakers follow: <list | of using the "Don't Preempt" Capability and IP address tiebreakers f | |||
style="symbols"> | ollow: </t> | |||
<t>If vES1 parameters were (500,0,Highest-Preference) in PE1 | <ul spacing="normal"> | |||
and (500,1,Highest-Preference) in PE2, PE2 would be elected | <li> | |||
due to the DP bit. The same example applies if PE1 and PE2 | <t>If vES1 parameters were (500, 0, Highest-Preference) in PE1 | |||
advertise Lowest-Preference DF Algorithm instead.</t> | and (500, 1, Highest-Preference) in PE2, PE2 would be elected | |||
due to the "Don't Preempt" Capability. The same example applies | ||||
<t>If vES1 parameters were (500,0,Highest-Preference) in PE1 | if PE1 and PE2 | |||
and (500,0,Highest-Preference) in PE2, PE1 would be elected, | advertise the Lowest-Preference Algorithm instead.</t> | |||
</li> | ||||
<li> | ||||
<t>If vES1 parameters were (500, 0, Highest-Preference) in PE1 | ||||
and (500, 0, Highest-Preference) in PE2, PE1 would be elected, | ||||
if PE1's IP address is lower than PE2's. Or PE2 would be | if PE1's IP address is lower than PE2's. Or PE2 would be | |||
elected if PE2's IP address is lower than PE1's. The same | elected if PE2's IP address is lower than PE1's. The same | |||
example applies if PE1 and PE2 advertise Lowest-Preference DF | example applies if PE1 and PE2 advertise the Lowest-Preference | |||
Algorithm instead.</t> | Algorithm instead.</t> | |||
</list></t> | </li> | |||
</ul> | ||||
<t>The Preference is an administrative option that MUST be | </li> | |||
configured on a per-Ethernet Segment basis, and it is normally | <li> | |||
configured from the management plane. The Preference value MAY | <t>The Preference is an administrative option that <bcp14>MUST</bcp1 | |||
4> be | ||||
configured on a per-Ethernet-Segment basis, and it is normally | ||||
configured from the management plane. The preference value <bcp14>MA | ||||
Y</bcp14> | ||||
also be dynamically changed based on the use of local policies | also be dynamically changed based on the use of local policies | |||
that react to events on the PE. The following examples illustrate | that react to events on the PE. The following examples illustrate | |||
the use of local policy to change the Preference value in a | the use of local policy to change the preference value in a | |||
dynamic way.<list style="empty"> | dynamic way.</t> | |||
<t>E.g., on PE1, if the DF Algorithm is Highest-Preference, | <ul spacing="normal"> | |||
ES1's Preference value can be lowered from 500 to 100 in case | <li> | |||
<t>On PE1, if the DF algorithm is Highest-Preference, | ||||
ES1's preference value can be lowered from 500 to 100 in case | ||||
the bandwidth on the ENNI port is decreased by 50% (that could | the bandwidth on the ENNI port is decreased by 50% (that could | |||
happen if e.g., the 2-port Link Aggregation Group between PE1 | happen if, e.g., the 2-port Link Aggregation Group between PE1 | |||
and the Aggregation Network loses one port).</t> | and the Aggregation Network loses one port).</t> | |||
</li> | ||||
<t>Local policy MAY also trigger dynamic Preference changes | <li> | |||
<t>Local policy <bcp14>MAY</bcp14> also trigger dynamic Preferen | ||||
ce changes | ||||
based on the PE's bandwidth availability in the core, specific | based on the PE's bandwidth availability in the core, specific | |||
ports going operationally down, etc.</t> | ports going operationally down, etc.</t> | |||
</li> | ||||
<li> | ||||
<t>The definition of the actual local policies is out of scope | <t>The definition of the actual local policies is out of scope | |||
of this document.</t> | of this document.</t> | |||
</list></t> | </li> | |||
</list></t> | </ul> | |||
</li> | ||||
</ol> | ||||
<t>The Highest-Preference and Lowest-Preference Algorithms MAY be used | <t>Highest-Preference and Lowest-Preference Algorithms <bcp14>MAY</bcp14 > be used | |||
along with the AC-DF capability. Assuming all the PEs in the Ethernet | along with the AC-DF capability. Assuming all the PEs in the Ethernet | |||
Segment are configured consistently with Highest-Preference or | Segment are configured consistently with the Highest-Preference or | |||
Lowest-Preference Algorithm and AC-DF capability, a given PE in the | Lowest-Preference Algorithm and AC-DF capability, a given PE in the | |||
Ethernet Segment is not considered as a candidate for Designated | Ethernet Segment is not considered as a candidate for DF election until | |||
Forwarder Election until its corresponding Ethernet A-D per ES and | its corresponding Ethernet A-D per ES and | |||
Ethernet A-D per EVI routes are received, as described in <xref | Ethernet A-D per EVI routes are received, as described in <xref target=" | |||
target="RFC8584"/>.</t> | RFC8584" format="default"/>.</t> | |||
<t>Highest-Preference and Lowest-Preference Algorithms can be | ||||
<t>The Highest-Preference and Lowest-Preference DF Algorithms can be | ||||
used in different virtual Ethernet Segments on the same PE. For | used in different virtual Ethernet Segments on the same PE. For | |||
instance, PE1 and PE2 can use Highest-Preference for vES1 and PE1, PE2 | instance, PE1 and PE2 can use Highest-Preference for vES1 and PE1, and P | |||
and PE3 Lowest-Preference for vES2. The use of one DF Algorithm over | E2 | |||
and PE3 can use Lowest-Preference for vES2. The use of one DF algorithm | ||||
over | ||||
the other is the operator's choice. The existence of both provides | the other is the operator's choice. The existence of both provides | |||
flexibility and full control to the operator.</t> | flexibility and full control to the operator.</t> | |||
<t>The procedures in this document can be used in <xref | <t>The procedures in this document can be used in an Ethernet Segment as | |||
target="RFC7432"/>-based Ethernet Segment or virtual Ethernet Segment | defined in <xref target="RFC7432" format="default"/> or a virtual Ethernet Segm | |||
as in <xref target="I-D.ietf-bess-evpn-virtual-eth-segment"/>, and | ent per <xref target="RFC9784" format="default"/> and | |||
also EVPN networks as in <xref target="RFC8214"/>, <xref | also in EVPN networks as described in <xref target="RFC8214" format="def | |||
target="RFC7623"/> or <xref target="RFC8365"/>.</t> | ault"/>, <xref target="RFC7623" format="default"/>, or <xref target="RFC8365" fo | |||
rmat="default"/>.</t> | ||||
</section> | </section> | |||
<section anchor="sect-4.2" numbered="true" toc="default"> | ||||
<section anchor="sect-4.2" | <name>Use of the Highest-Preference or Lowest-Preference Algorithm in Et | |||
title="Use of the Highest-Preference or Lowest-Preference algorit | hernet Segments</name> | |||
hm in [RFC7432] Ethernet Segments"> | <t>While the Highest-Preference or Lowest-Preference Algorithm | |||
<t>While the Highest-Preference or Lowest-Preference DF Algorithm | described in <xref target="sect-4.1" format="default"/> is typically use | |||
described in <xref target="sect-4.1"/> is typically used in virtual | d in virtual | |||
Ethernet Segment scenarios where there is normally an individual | Ethernet Segment scenarios where there is normally an individual | |||
Ethernet Tag per virtual Ethernet Segment, the existing <xref | Ethernet Tag per virtual Ethernet Segment, the existing definition of an | |||
target="RFC7432"/> definition of an Ethernet Segment allows | Ethernet Segment <xref target="RFC7432" format="default"/> allows | |||
potentially up to thousands of Ethernet Tags on the same Ethernet | potentially up to thousands of Ethernet Tags on the same Ethernet | |||
Segment. If this is the case, if Highest-Preference or | Segment. If this is the case, and if the Highest-Preference or | |||
Lowest-Preference Algorithm is configured in all the PEs of the | Lowest-Preference Algorithm is configured in all the PEs of the | |||
Ethernet Segment, the same PE will be the elected Designated Forwarder | Ethernet Segment, the same PE will be the elected Designated Forwarder | |||
for all the Ethernet Tags of the Ethernet Segment. A potential way to | for all the Ethernet Tags of the Ethernet Segment. A potential way to | |||
achieve a more granular load balancing is described below.</t> | achieve a more granular load balancing is described below.</t> | |||
<t>The Ethernet Segment is configured with an administrative | <t>The Ethernet Segment is configured with an administrative | |||
Preference value and an administrative DF Algorithm, i.e., | preference value and an administrative DF algorithm, i.e., | |||
Highest-Preference or Lowest-Preference Algorithm. However, the | Highest-Preference or Lowest-Preference Algorithm. However, the | |||
administrative DF Algorithm (which is used to signal the DF Algorithm | administrative DF algorithm (which is used to signal the DF algorithm | |||
for the Ethernet Segment) MAY be overridden to a different operational | for the Ethernet Segment) <bcp14>MAY</bcp14> be overridden to a differen | |||
DF Algorithm for a range of Ethernet Tags. With this option, the PE | t operational | |||
builds a list of candidate PEs ordered by Preference, however the | DF algorithm for a range of Ethernet Tags. With this option, the PE | |||
builds a list of candidate PEs ordered by Preference; however, the | ||||
Designated Forwarder for a given Ethernet Tag will be determined by | Designated Forwarder for a given Ethernet Tag will be determined by | |||
the locally overridden DF Algorithm.</t> | the locally overridden DF algorithm.</t> | |||
<t>For instance:</t> | <t>For instance:</t> | |||
<ul spacing="normal"> | ||||
<t><list style="symbols"> | <li> | |||
<t>Assuming ES3 is defined in PE1 and PE2, PE1 may be configured | <t>Assuming ES3 is defined in PE1 and PE2, PE1 may be configured | |||
as (500,0,Highest-Preference) for ES3 and PE2 as | as (500, 0, Highest-Preference) and PE2 as (100, 0, Highest-Preferen | |||
(100,0,Highest-Preference). Both PEs will advertise the Ethernet | ce) for ES3. | |||
Both PEs will advertise the Ethernet | ||||
Segment routes for ES3 with the indicated parameters in the DF | Segment routes for ES3 with the indicated parameters in the DF | |||
Election Extended Community.</t> | Election Extended Community.</t> | |||
</li> | ||||
<t>In addition, assuming VLAN-based service interfaces and that | <li> | |||
<t>In addition, assuming there are VLAN-based service interfaces and | ||||
that | ||||
the PEs are attached to all Ethernet Tags in the range 1-4000, | the PEs are attached to all Ethernet Tags in the range 1-4000, | |||
both PE1 and PE2 may be configured with (Ethernet | both PE1 and PE2 may be configured with (Ethernet | |||
Tag-range,Lowest-Preference), e.g., (2001-4000, | Tag-range, Lowest-Preference), e.g., (2001-4000, Lowest-Preference). | |||
Lowest-Preference).</t> | </t> | |||
</li> | ||||
<t>This will result in PE1 being Designated Forwarder for Ethernet | <li> | |||
<t>This will result in PE1 being the Designated Forwarder for Ethern | ||||
et | ||||
Tags 1-2000 (since they use the default Highest-Preference | Tags 1-2000 (since they use the default Highest-Preference | |||
Algorithm) and PE2 being Designated Forwarder for Ethernet Tags | Algorithm) and PE2 being the Designated Forwarder for Ethernet Tags | |||
2001-4000, due to the local policy overriding the | 2001-4000, due to the local policy overriding the | |||
Highest-Preference Algorithm.</t> | Highest-Preference Algorithm.</t> | |||
</list></t> | </li> | |||
</ul> | ||||
<t>While the above logic provides a perfect load balancing | <t>While the above logic provides a perfect load-balancing | |||
distribution of Ethernet Tags per Designated Forwarder when there are | distribution of Ethernet Tags per Designated Forwarder when there are | |||
only two PEs, for Ethernet Segments attached to three or more PEs, | only two PEs, for Ethernet Segments attached to three or more PEs, | |||
there would be only two Designated Forwarder PEs for all the Ethernet | there would be only two Designated Forwarder PEs for all the Ethernet | |||
Tags. Any other logic that provides a fair distribution of the | Tags. Any other logic that provides a fair distribution of the | |||
Designated Forwarder function among the three or more PEs is valid, as | Designated Forwarder function among the three or more PEs is valid, as | |||
long as that logic is consistent in all the PEs in the Ethernet | long as that logic is consistent in all the PEs in the Ethernet | |||
Segment. It is important to note that, when a local policy overrides | Segment. It is important to note that, when a local policy overrides | |||
the Highest-Preference or Lowest-Preference signaled by all the PEs in | the Highest-Preference or Lowest-Preference signaled by all the PEs in | |||
the Ethernet Segment, this local policy MUST be consistent in all the | the Ethernet Segment, this local policy <bcp14>MUST</bcp14> be consisten t in all the | |||
PEs of the Ethernet Segment. If the local policy is inconsistent for a | PEs of the Ethernet Segment. If the local policy is inconsistent for a | |||
given Ethernet Tag in the Ethernet Segment, packet drops or packet | given Ethernet Tag in the Ethernet Segment, packet drops or packet | |||
duplication may occur on that Ethernet Tag. For all these reasons the | duplication may occur on that Ethernet Tag. For all these reasons, the | |||
use of virtual Ethernet Segments is RECOMMENDED for cases where more | use of virtual Ethernet Segments is <bcp14>RECOMMENDED</bcp14> for cases | |||
than two PEs per Ethernet Segment exist and a good load balancing | where more | |||
than two PEs per Ethernet Segment exist and a good load-balancing | ||||
distribution per Ethernet Tag of the Designated Forwarder function is | distribution per Ethernet Tag of the Designated Forwarder function is | |||
desired. </t> | desired. </t> | |||
</section> | </section> | |||
<section anchor="sect-4.3" numbered="true" toc="default"> | ||||
<section anchor="sect-4.3" title="The Non-Revertive Capability"> | <name>The Non-Revertive Capability</name> | |||
<t>As discussed in <xref target="sect-1.2"/> (d), a capability to NOT | <t>As discussed in <xref target="DP-capability" format="none">item d</xr | |||
ef> of <xref target="sect-1.2" format="default"/>, a capability to NOT | ||||
preempt the existing Designated Forwarder (for all the Ethernet Tags | preempt the existing Designated Forwarder (for all the Ethernet Tags | |||
in the Ethernet Segment) is required and therefore added to the | in the Ethernet Segment) is required and therefore added to the | |||
Designated Forwarder Election extended community. This option allows a | DF Election Extended Community. This option allows a | |||
non-revertive behavior in the Designated Forwarder election.</t> | non-revertive behavior in the DF election.</t> | |||
<t>Note that when a given PE in an Ethernet Segment is taken down for | <t>Note that when a given PE in an Ethernet Segment is taken down for | |||
maintenance operations, before bringing it back, the Preference may be | maintenance operations, before bringing it back, the Preference may be | |||
changed in order to provide a non-revertive behavior. The DP bit and | changed in order to provide a non-revertive behavior. The "Don't Preempt " Capability and | |||
the mechanism explained in this section will be used for those cases | the mechanism explained in this section will be used for those cases | |||
when a former Designated Forwarder comes back up without any | when a former Designated Forwarder comes back up without any | |||
controlled maintenance operation, and the non-revertive option is | controlled maintenance operation, and the non-revertive option is | |||
desired in order to avoid service impact.</t> | desired in order to avoid service impact.</t> | |||
<t>In <xref target="es-and-deterministic-df-election" format="default"/> | ||||
<t>In <xref target="es-and-deterministic-df-election"/>, we assume | , we assume | |||
that based on the Highest-Preference Algorithm, PE3 is the Designated | that based on the Highest-Preference Algorithm, PE3 is the Designated | |||
Forwarder for ESI2.</t> | Forwarder for ESI2.</t> | |||
<t>If PE3 has a link, EVC, or node failure, PE2 would take over as the | ||||
<t>If PE3 has a link, EVC or node failure, PE2 would take over as | ||||
Designated Forwarder. If/when PE3 comes back up again, PE3 will take | Designated Forwarder. If/when PE3 comes back up again, PE3 will take | |||
over, causing some unnecessary packet loss in the Ethernet | over, causing some unnecessary packet loss in the Ethernet | |||
Segment.</t> | Segment.</t> | |||
<t>The following procedure avoids preemption upon failure recovery | <t>The following procedure avoids preemption upon failure recovery | |||
(please refer to <xref target="es-and-deterministic-df-election"/>). | (see <xref target="es-and-deterministic-df-election" format="default"/>) . | |||
The procedure supports a non-revertive mode that can be used along | The procedure supports a non-revertive mode that can be used along | |||
with: <list style="symbols"> | with: </t> | |||
<ul spacing="normal"> | ||||
<li> | ||||
<t>Highest-Preference Algorithm</t> | <t>Highest-Preference Algorithm</t> | |||
</li> | ||||
<li> | ||||
<t>Lowest-Preference Algorithm</t> | <t>Lowest-Preference Algorithm</t> | |||
</li> | ||||
<li> | ||||
<t>Highest-Preference or Lowest-Preference Algorithm, where a | <t>Highest-Preference or Lowest-Preference Algorithm, where a | |||
local policy overrides the Highest/Lowest-Preference tiebreaker | local policy overrides the Highest-/Lowest-Preference tiebreaker | |||
for a range of Ethernet Tags <xref target="sect-4.2"/></t> | for a range of Ethernet Tags (<xref target="sect-4.2" format="defaul | |||
</list>The procedure is described assuming Highest-Preference | t"/>)</t> | |||
</li> | ||||
</ul> | ||||
<t>The procedure is described, assuming the Highest-Preference | ||||
Algorithm in the Ethernet Segment, where local policy overrides the | Algorithm in the Ethernet Segment, where local policy overrides the | |||
tiebreaker for a given Ethernet Tag. The other cases above are a | tiebreaker for a given Ethernet Tag. The other cases above are a | |||
sub-set of this one and the differences are explained.</t> | subset of this one, and the differences are explained.</t> | |||
<ol spacing="normal" type="1"><li> | ||||
<t><list style="numbers"> | <t>A "Don't Preempt" Capability is defined on a | |||
<t>A "Don't Preempt" capability is defined on a | per-PE / per-Ethernet-Segment basis, as described in <xref target="s | |||
per-PE/per-Ethernet Segment basis, as described in <xref | ect-3" format="default"/>. If "Don't Preempt" is disabled (default | |||
target="sect-3"/>. If "Don't Preempt" is disabled (default | ||||
behavior), the PE sets DP to zero and advertises it in an Ethernet | behavior), the PE sets DP to zero and advertises it in an Ethernet | |||
Segment route. If "Don't Preempt" is enabled, the Ethernet Segment | Segment route. If "Don't Preempt" is enabled, the Ethernet Segment | |||
route from the PE indicates the desire of not being preempted by | route from the PE indicates the desire of not being preempted by | |||
the other PEs in the Ethernet Segment. All the PEs in an Ethernet | the other PEs in the Ethernet Segment. All the PEs in an Ethernet | |||
Segment should be consistent in their configuration of the DP | Segment should be consistent in their configuration of the "Don't Pr | |||
capability, however, this document does not enforce the | eempt" | |||
Capability; however, this document does not enforce the | ||||
consistency across all the PEs. In case of inconsistency in the | consistency across all the PEs. In case of inconsistency in the | |||
support of the DP capability in the PEs of the same Ethernet | support of the "Don't Preempt" Capability in the PEs of the same Eth ernet | |||
Segment, non-revertive behavior is not guaranteed. However, PEs | Segment, non-revertive behavior is not guaranteed. However, PEs | |||
supporting this capability still attempt this procedure.</t> | supporting this capability still attempt this procedure.</t> | |||
</li> | ||||
<t>We assume we want to avoid 'preemption' in all the PEs in the | <li> | |||
<t>Assuming we want to avoid 'preemption' in all the PEs in the | ||||
Ethernet Segment, the three PEs are configured with the "Don't | Ethernet Segment, the three PEs are configured with the "Don't | |||
Preempt" capability. In this example, we assume ESI2 is configured | Preempt" Capability. In this example, we assume ESI2 is configured | |||
as 'DP=enabled' in the three PEs.</t> | as 'DP=enabled' in the three PEs.</t> | |||
</li> | ||||
<li> | ||||
<t>We also assume vES2 is attached to Ethernet Tag-1 and Ethernet | <t>We also assume vES2 is attached to Ethernet Tag-1 and Ethernet | |||
Tag-2. vES2 uses Highest-Preference as DF Algorithm and a local | Tag-2. | |||
vES2 uses Highest-Preference as the DF algorithm, and a local | ||||
policy is configured in the three PEs to use Lowest-Preference for | policy is configured in the three PEs to use Lowest-Preference for | |||
Ethernet Tag-2. When vES2 is enabled in the three PEs, the PEs | Ethernet Tag-2. When vES2 is enabled in the three PEs, the PEs | |||
will exchange the Ethernet Segment routes and select PE3 as | will exchange the Ethernet Segment routes and select PE3 as | |||
Designated Forwarder for Ethernet Tag-1 (due to the | the Designated Forwarder for Ethernet Tag-1 (due to the | |||
Highest-Preference), and PE1 as Designated Forwarder for Ethernet | Highest-Preference) and PE1 as the Designated Forwarder for Ethernet | |||
Tag-2 (due to the Lowest-Preference).</t> | Tag-2 (due to the Lowest-Preference).</t> | |||
</li> | ||||
<t>If PE3's vES2 goes down (due to EVC failure - detected by OAM, | <li> | |||
or port failure or node failure), PE2 will become the Designated | <t>If PE3's vES2 goes down (due to an EVC failure (as detected by OA | |||
M protocols), | ||||
a port failure, or a node failure), PE2 will become the Designated | ||||
Forwarder for Ethernet Tag-1. No changes will occur for Ethernet | Forwarder for Ethernet Tag-1. No changes will occur for Ethernet | |||
Tag-2.</t> | Tag-2.</t> | |||
</li> | ||||
<li> | ||||
<t>When PE3's vES2 comes back up, PE3 will start a boot-timer (if | <t>When PE3's vES2 comes back up, PE3 will start a boot-timer (if | |||
booting up) or hold-timer (if the port or EVC recovers). That | booting up) or hold-timer (if the port or EVC recovers). That | |||
timer will allow some time for PE3 to receive the Ethernet Segment | timer will allow some time for PE3 to receive the Ethernet Segment | |||
routes from PE1 and PE2. This timer is applied between the INIT | routes from PE1 and PE2. This timer is applied between the INIT | |||
and the DF_WAIT states in the Designated Forwarder Election Finite | and the DF_WAIT states in the DF election Finite | |||
State Machine described in <xref target="RFC8584"/>. PE3 will | State Machine described in <xref target="RFC8584" format="default"/> | |||
then:<list style="symbols"> | . PE3 will | |||
then:</t> | ||||
<ul spacing="normal"> | ||||
<li> | ||||
<t>Select a "reference-PE" among the Ethernet Segment routes | <t>Select a "reference-PE" among the Ethernet Segment routes | |||
in the virtual Ethernet Segment. If the Ethernet Segment uses | in the virtual Ethernet Segment. If the Ethernet Segment uses | |||
the Highest-Preference algorithm, select a "Highest-PE". If it | the Highest-Preference Algorithm, select a "Highest-PE". If it | |||
uses the Lowest-Preference algorithm, select a "Lowest-PE". If | uses the Lowest-Preference Algorithm, select a "Lowest-PE". If | |||
a local policy is in use, to override the | a local policy is in use, to override the | |||
Highest/Lowest-Preference for a range of Ethernet Tags (as | Highest-/Lowest-Preference for a range of Ethernet Tags (as | |||
discussed in <xref target="sect-4.2"/>), it is necessary to | discussed in <xref target="sect-4.2" format="default"/>), it is | |||
necessary to | ||||
select both a Highest-PE and a Lowest-PE. They are selected as | select both a Highest-PE and a Lowest-PE. They are selected as | |||
follows: <list style="symbols"> | follows: </t> | |||
<ul spacing="normal"> | ||||
<li> | ||||
<t>The Highest-PE is the PE with higher Preference, using | <t>The Highest-PE is the PE with higher Preference, using | |||
the DP bit first (with DP=1 being better) and, after that, | the "Don't Preempt" Capability first (with DP=1 being better ) and, after that, | |||
the lower PE-IP address as tiebreakers. </t> | the lower PE-IP address as tiebreakers. </t> | |||
</li> | ||||
<li> | ||||
<t>The Lowest-PE is the PE with lower Preference, using | <t>The Lowest-PE is the PE with lower Preference, using | |||
the DP bit first (with DP=1 being better) and, after that, | the "Don't Preempt" Capability first (with DP=1 being better ) and, after that, | |||
the lower PE-IP address as tiebreakers. </t> | the lower PE-IP address as tiebreakers. </t> | |||
</li> | ||||
<t>In our example, the Highest-Preference algorithm is | <li> | |||
<t>In our example, the Highest-Preference Algorithm is | ||||
used, with a local policy to override it to use | used, with a local policy to override it to use | |||
Lowest-Preference for a range of Ethernet Tags. Therefore | Lowest-Preference for a range of Ethernet Tags. Therefore, | |||
PE3 selects a Highest-PE and a Lowest-PE. PE3 will select | PE3 selects a Highest-PE and a Lowest-PE. PE3 will select | |||
PE2 as Highest-PE over PE1, since, when comparing | PE2 as the Highest-PE over PE1, because when comparing | |||
(Pref,DP,PE-IP), (200,1,PE2-IP) wins over (100,1,PE1-IP). | (Pref, DP, PE-IP), (200, 1, PE2-IP) wins over (100, 1, PE1-I | |||
PE3 will select PE1 as Lowest-PE over PE2, since | P). | |||
(100,1,PE1-IP) wins over (200,1,PE2-IP). Note that if | PE3 will select PE1 as the Lowest-PE over PE2, because | |||
(100, 1, PE1-IP) wins over (200, 1, PE2-IP). Note that if | ||||
there were only one remote PE in the Ethernet Segment, | there were only one remote PE in the Ethernet Segment, | |||
Lowest and Highest PE would be the same PE.</t> | the Lowest and Highest PE would be the same PE.</t> | |||
</list></t> | </li> | |||
</ul> | ||||
</li> | ||||
<li> | ||||
<t>Check its own administrative Pref and compare it with the | <t>Check its own administrative Pref and compare it with the | |||
one of the Highest-PE and Lowest-PE that have the DP | one of the Highest-PE and Lowest-PE that have the "Don't Preempt | |||
capability set in their Ethernet Segment routes. Depending on | " | |||
this comparison PE3 sends the Ethernet Segment route with a | Capability set in their Ethernet Segment routes. Depending on | |||
(Pref,DP) that may be different from its administrative | this comparison, PE3 sends the Ethernet Segment route with a | |||
(Pref,DP):<list style="symbols"> | (Pref, DP) that may be different from its administrative | |||
<t>If PE3's Pref value is higher or equal than the | (Pref, DP):</t> | |||
<ul spacing="normal"> | ||||
<li> | ||||
<t>If PE3's Pref value is higher than or equal to the | ||||
Highest-PE's, PE3 will send the Ethernet Segment route | Highest-PE's, PE3 will send the Ethernet Segment route | |||
with an 'in-use' operational Pref equal to the | with an 'in-use' operational Pref equal to the | |||
Highest-PE's and DP=0.</t> | Highest-PE's and DP=0.</t> | |||
</li> | ||||
<t>If PE3's Pref value is lower or equal than the | <li> | |||
<t>If PE3's Pref value is lower than or equal to the | ||||
Lowest-PE's, PE3 will send the Ethernet Segment route with | Lowest-PE's, PE3 will send the Ethernet Segment route with | |||
an 'in-use' operational Preference equal to the | an 'in-use' operational Preference equal to the | |||
Lowest-PE's and DP=0.</t> | Lowest-PE's and DP=0.</t> | |||
</li> | ||||
<t>If PE3's Pref value is not higher or equal than the | <li> | |||
Highest-PE's and is not lower or equal than the | <t>If PE3's Pref value is not higher than or equal to the | |||
Highest-PE's and is not lower than or equal to the | ||||
Lowest-PE's, PE3 will send the Ethernet Segment route with | Lowest-PE's, PE3 will send the Ethernet Segment route with | |||
its administrative (Pref,DP)=(300,1).</t> | its administrative (Pref, DP)=(300, 1).</t> | |||
</li> | ||||
<li> | ||||
<t>In this example, PE3's administrative Pref=300 is | <t>In this example, PE3's administrative Pref=300 is | |||
higher than the Highest-PE with DP=1, that is, PE2 | higher than the Highest-PE with DP=1, that is, PE2 | |||
(Pref=200). Hence, PE3 will inherit PE2's preference and | (Pref=200). Hence, PE3 will inherit PE2's preference and | |||
send the Ethernet Segment route with an operational | send the Ethernet Segment route with an operational | |||
'in-use' (Pref,DP)=(200,0).</t> | 'in-use' (Pref, DP)=(200, 0).</t> | |||
</list></t> | </li> | |||
</ul> | ||||
<t>Note that, a PE will always send its DP capability set to | </li> | |||
zero as long as the advertised Pref is the 'in-use' | <li> | |||
<t>Send its "Don't Preempt" Capability set to | ||||
zero, as long as the advertised Pref is the 'in-use' | ||||
operational Pref (as opposed to the 'administrative' | operational Pref (as opposed to the 'administrative' | |||
Pref).</t> | Pref).</t> | |||
</li> | ||||
<t>This Ethernet Segment route update sent by PE3, with | <li> | |||
(200,0,PE3-IP), will not cause any Designated Forwarder | <t>Not trigger any Designated Forwarder changes for Ethernet Tag | |||
switchover for any Ethernet Tag. PE2 will continue being | -1. This Ethernet Segment route update sent by PE3, with | |||
Designated Forwarder for Ethernet Tag-1. This is because the | (200, 0, PE3-IP), will not cause any Designated Forwarder | |||
DP bit will be used as a tiebreaker in the Designated | switchover for any Ethernet Tag. This is because the | |||
Forwarder election. That is, if a PE has two candidate PEs | "Don't Preempt" Capability will be used as a tiebreaker in the | |||
DF election. That is, if a PE has two candidate PEs | ||||
with the same Pref, it will pick the one with DP=1. There are | with the same Pref, it will pick the one with DP=1. There are | |||
no Designated Forwarder changes for Ethernet Tag-2 either.</t> | no Designated Forwarder changes for Ethernet Tag-2 either.</t> | |||
</list></t> | </li> | |||
</ul> | ||||
</li> | ||||
<li> | ||||
<t>For any subsequent received update/withdraw in the Ethernet | <t>For any subsequent received update/withdraw in the Ethernet | |||
Segment, the PEs will go through the process described in (5) to | Segment, the PEs will go through the process described in (5) to | |||
select Highest and Lowest-PEs, now considering themselves as | select the Highest-PEs and Lowest-PEs, now considering themselves as | |||
candidates. For instance, if PE2 fails, upon receiving PE2's | candidates. For instance, if PE2 fails upon receiving PE2's | |||
Ethernet Segment route withdrawal, PE3 and PE1 will go through the | Ethernet Segment route withdrawal, PE3 and PE1 will go through the | |||
selection of new Highest and Lowest-PEs (considering their own | selection of the new Highest-PEs and Lowest-PEs (considering their o | |||
active Ethernet Segment route) and then they will run the | wn | |||
Designated Forwarder Election.<list style="symbols"> | active Ethernet Segment route), and then they will run the | |||
<t>If a PE selects itself as new Highest or Lowest-PE and it | DF election.</t> | |||
<ul spacing="normal"> | ||||
<li> | ||||
<t>If a PE selects itself as the new Highest-PE or Lowest-PE and | ||||
it | ||||
was not before, the PE will then compare its operational | was not before, the PE will then compare its operational | |||
'in-use' Pref with its administrative Pref. If different, the | 'in-use' Pref with its administrative Pref. If different, the | |||
PE will send an Ethernet Segment route update with its | PE will send an Ethernet Segment route update with its | |||
administrative Pref and DP values. In the example, PE3 will be | administrative Pref and DP values. In the example, PE3 will be | |||
the new Highest-PE, therefore it will send an Ethernet Segment | the new Highest-PE; therefore, it will send an Ethernet Segment | |||
route update with (Pref,DP)=(300,1).</t> | route update with (Pref, DP)=(300, 1).</t> | |||
</li> | ||||
<t>After running the Designated Forwarder Election, PE3 will | <li> | |||
<t>After running the DF election, PE3 will | ||||
become the new Designated Forwarder for Ethernet Tag-1. No | become the new Designated Forwarder for Ethernet Tag-1. No | |||
changes will occur for Ethernet Tag-2.</t> | changes will occur for Ethernet Tag-2.</t> | |||
</list></t> | </li> | |||
</list></t> | </ul> | |||
</li> | ||||
<t>Note that, irrespective of the DP bit, when a PE or Ethernet | </ol> | |||
Segment comes back and the PE advertises a Designated Forwarder | <t>Note that, irrespective of the "Don't Preempt" Capability, when a PE | |||
Election Algorithm different from the one configured in the rest of | or Ethernet | |||
Segment comes back and the PE advertises a DF | ||||
election algorithm different from the one configured in the rest of | ||||
the PEs in the Ethernet Segment, all the PEs in the Ethernet Segment | the PEs in the Ethernet Segment, all the PEs in the Ethernet Segment | |||
MUST fall back to the Default <xref target="RFC7432"/> Algorithm.</t> | <bcp14>MUST</bcp14> fall back to the default DF algorithm <xref target=" RFC7432" format="default"/>.</t> | |||
<t>This document does not modify the use of the P and B bits in the | <t>This document does not modify the use of the P and B bits in the | |||
Ethernet A-D per EVI routes <xref target="RFC8214"/> advertised by the | Ethernet A-D per EVI routes <xref target="RFC8214" format="default"/> ad | |||
PEs in the Ethernet Segment after running the Designated Forwarder | vertised by the | |||
Election, irrespective of the revertive or non-revertive behavior in | PEs in the Ethernet Segment after running the DF | |||
election, irrespective of the revertive or non-revertive behavior in | ||||
the PE.</t> | the PE.</t> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="sect-5" numbered="true" toc="default"> | ||||
<section anchor="sect-5" title="Security Considerations"> | <name>Security Considerations</name> | |||
<t>This document describes a Designated Forwarder Election Algorithm | <t>This document describes a DF election algorithm | |||
that provides absolute control (by configuration) over what PE is the | that provides absolute control (by configuration) over what PE is the | |||
Designated Forwarder for a given Ethernet Tag. While this control is | Designated Forwarder for a given Ethernet Tag. While this control is | |||
desired in many situations, a malicious user that gets access to the | desired in many situations, a malicious user that gets access to the | |||
configuration of a PE in the Ethernet Segment may change the behavior of | configuration of a PE in the Ethernet Segment may change the behavior of | |||
the network. In other DF Algorithms such as HRW, the Designated | the network. In other DF algorithms such as HRW, the DF election is more a | |||
Forwarder Election is more automated and cannot be determined by | utomated and cannot be determined by | |||
configuration. With Highest-Preference or Lowest-Preference as DF | configuration. | |||
Algorithm, an attacker may change the configuration of the Preference | If the DF algorithm is Highest-Preference or Lowest-Preference, an attacke | |||
value on a PE and Ethernet Segment, and impact the traffic going through | r may change the configuration of the preference | |||
value on a PE and Ethernet Segment to impact the traffic going through | ||||
that PE and Ethernet Segment.</t> | that PE and Ethernet Segment.</t> | |||
<t>The non-revertive capability described in this document may be seen | <t>The non-revertive capability described in this document may be seen | |||
as a security improvement over the regular EVPN revertive Designated | as a security improvement over the regular EVPN revertive DF election: an | |||
Forwarder Election: an intentional link (or node) "flapping" on a PE | intentional link (or node) "flapping" on a PE | |||
will only cause service disruption once, when the PE goes to | will only cause service disruption once, when the PE goes to | |||
Non-Designated Forwarder state. However, an attacker who gets access to | Non-Designated Forwarder state. However, an attacker who gets access to | |||
the configuration of a PE in the Ethernet Segment will be able to | the configuration of a PE in the Ethernet Segment will be able to | |||
disable the non-revertive behavior, by advertising a conflicting DF | disable the non-revertive behavior, by advertising a conflicting DF | |||
election algorithm and thereby forcing fallback to the Default | election algorithm and thereby forcing fallback to the default DF | |||
algorithm. </t> | algorithm. </t> | |||
<t>The document also describes how a local policy can override the | <t>The document also describes how a local policy can override the | |||
Highest-Preference or Lowest-Preference algorithms for a range of | Highest-Preference or Lowest-Preference Algorithms for a range of | |||
Ethernet Tags in the Ethernet Segment. If the local policy is not | Ethernet Tags in the Ethernet Segment. If the local policy is not | |||
consistent across all PEs in the Ethernet Segment and there is an | consistent across all PEs in the Ethernet Segment and there is an | |||
Ethernet Tag that ends up with an inconsistent use of Highest-Preference | Ethernet Tag that ends up with an inconsistent use of Highest-Preference | |||
or Lowest-Preference in different PEs, packet drop or packet duplication | or Lowest-Preference in different PEs, packet drop or packet duplication | |||
may occur for that Ethernet Tag.</t> | may occur for that Ethernet Tag.</t> | |||
<t>Finally, the two DF election algorithms specified | ||||
<t>Finally, the two Designated Forwarder Election Algorithms specified | ||||
in this document (Highest-Preference and Lowest-Preference) do not | in this document (Highest-Preference and Lowest-Preference) do not | |||
change the way the PEs share their Ethernet Segment information, | change the way the PEs share their Ethernet Segment information, | |||
compared to the algorithms in <xref target="RFC7432"/> and <xref | compared to the algorithms in <xref target="RFC7432" format="default"/> an | |||
target="RFC8584"/>. Therefore the security considerations in <xref | d <xref target="RFC8584" format="default"/>. Therefore, the security considerati | |||
target="RFC7432"/> and <xref target="RFC8584"/> apply to this document | ons in <xref target="RFC7432" format="default"/> and <xref target="RFC8584" form | |||
too.</t> | at="default"/> apply to this document | |||
</section> | as well.</t> | |||
<section anchor="sect-6" title="IANA Considerations"> | ||||
<t>This document solicits:</t> | ||||
<t><list style="symbols"> | ||||
<t>The allocation of two new values in the "DF Alg" registry created | ||||
by <xref target="RFC8584"/> as follows:<figure> | ||||
<artwork><![CDATA[Alg Name R | ||||
eference | ||||
2 Highest-Preference Algorithm This document | ||||
TBD Lowest-Preference Algorithm This document]]></artwork> | ||||
</figure></t> | ||||
<t>The allocation of a new value in the "DF Election Capabilities" | ||||
registry created by <xref target="RFC8584"/> for the 2-octet Bitmap | ||||
field in the DF Election Extended Community (Border gateway Protocol | ||||
(BGP) Extended Communities registry), as follows:<figure> | ||||
<artwork><![CDATA[Bit Name Ref | ||||
erence | ||||
0 D (Don't Preempt) Capability This document]]></artwork> | ||||
</figure></t> | ||||
</list><list style="symbols"> | ||||
<t>To update the reference of the "DF Election Extended Community" | ||||
field, in the EVPN Extended Community Sub-Types registry, as | ||||
follows:<figure> | ||||
<artwork><![CDATA[Sub-Type Value Name | ||||
Reference | ||||
0x06 DF Election Extended Community [RFC8584] and This Document | ||||
]]></artwork> | ||||
</figure> </t> | ||||
</list></t> | ||||
</section> | ||||
<section anchor="sect-7" title="Acknowledgments "> | ||||
<t>The authors would like to thank Kishore Tiruveedhula and Sasha | ||||
Vainshtein for their review and comments. Also thank you to Luc Andre | ||||
Burdet and Stephane Litkowski for their thorough review and suggestions | ||||
for a new DF Algorithm for lowest-preference.</t> | ||||
</section> | </section> | |||
<section anchor="sect-6" numbered="true" toc="default"> | ||||
<name>IANA Considerations</name> | ||||
<t>Per this document, IANA has:</t> | ||||
<section anchor="sect-8" title="Contributors "> | <ul spacing="normal"> | |||
<t>In addition to the authors listed, the following individuals also | <li> | |||
contributed to this document:</t> | <t>Allocated two new values in the "DF Alg" registry created | |||
by <xref target="RFC8584" format="default"/>, as follows:</t> | ||||
<t>Tony Przygienda, Juniper</t> | ||||
<t>Satya Mohanty, Cisco</t> | <table align="left"> | |||
<thead> | ||||
<tr> | ||||
<th>Alg</th> | ||||
<th>Name</th> | ||||
<th>Reference</th> | ||||
</tr> | ||||
</thead> | ||||
<tbody> | ||||
<tr> | ||||
<td>2</td> | ||||
<td>Highest-Preference Algorithm</td> | ||||
<td>RFC 9785</td> | ||||
</tr> | ||||
<tr> | ||||
<td>3</td> | ||||
<td>Lowest-Preference Algorithm</td> | ||||
<td>RFC 9785</td> | ||||
</tr> | ||||
</tbody> | ||||
</table> | ||||
</li> | ||||
<li> | ||||
<t>Allocated a new value in the "DF Election Capabilities" | ||||
registry created by <xref target="RFC8584" format="default"/> for the | ||||
2-octet Bitmap | ||||
field in the DF Election Extended Community (under the "Border | ||||
Gateway Protocol (BGP) Extended Communities" registry group), as follo | ||||
ws:</t> | ||||
<t>Kiran Nagaraj, Nokia</t> | <table align="left"> | |||
<thead> | ||||
<tr> | ||||
<th>Bit</th> | ||||
<th>Name</th> | ||||
<th>Reference</th> | ||||
</tr> | ||||
</thead> | ||||
<tbody> | ||||
<tr> | ||||
<td>0</td> | ||||
<td>D (Don't Preempt) Capability</td> | ||||
<td>RFC 9785</td> | ||||
</tr> | ||||
</tbody> | ||||
</table> | ||||
</li> | ||||
<t>Vinod Prabhu, Nokia</t> | <li> | |||
<t>Listed this document as an additional reference for the DF Election | ||||
Extended Community field in the "EVPN Extended Community Sub-Types" registry, a | ||||
s follows:</t> | ||||
<t>Selvakumar Sivaraj, Juniper</t> | <table align="left"> | |||
<thead> | ||||
<tr> | ||||
<th>Sub-Type Value</th> | ||||
<th>Name</th> | ||||
<th>Reference</th> | ||||
</tr> | ||||
</thead> | ||||
<tbody> | ||||
<tr> | ||||
<td>0x06</td> | ||||
<td>DF Election Extended Community</td> | ||||
<td><xref target="RFC8584"/> and RFC 9785</td> | ||||
</tr> | ||||
</tbody> | ||||
</table> | ||||
</li> | ||||
</ul> | ||||
<t>Sami Boutros, VMWare</t> | ||||
</section> | </section> | |||
</middle> | </middle> | |||
<back> | <back> | |||
<references title="Normative References"> | <references> | |||
&RFC7432; | ||||
&RFC8584; | ||||
&RFC2119; | ||||
&RFC8174; | ||||
&I-D.ietf-bess-evpn-virtual-eth-segment; | <name>References</name> | |||
</references> | <references> | |||
<name>Normative References</name> | ||||
<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 | ||||
584.xml"/> | ||||
<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.8 | ||||
174.xml"/> | ||||
<references title="Informative References"> | <!-- draft-ietf-bess-evpn-virtual-eth-segment-19 companion doc RFC 9784. --> | |||
&RFC8214; | ||||
&RFC8365; | <reference anchor="RFC9784" target="https://www.rfc-editor.org/info/rfc9784"> | |||
<front> | ||||
<title>EVPN Virtual Ethernet Segment</title> | ||||
<author initials="A." surname="Sajassi" fullname="Ali Sajassi"> | ||||
<organization>Cisco Systems</organization> | ||||
</author> | ||||
<author initials="P." surname="Brissette" fullname="Patrice Brissette"> | ||||
<organization>Cisco Systems</organization> | ||||
</author> | ||||
<author initials="R." surname="Schell" fullname="Rick Schell"> | ||||
<organization>Verizon</organization> | ||||
</author> | ||||
<author initials="J." surname="Drake" fullname="John Drake"> | ||||
<organization>Juniper</organization> | ||||
</author> | ||||
<author initials="J." surname="Rabadan" fullname="Jorge Rabadan"> | ||||
<organization>Nokia</organization> | ||||
</author> | ||||
<date month="May" year="2025" /> | ||||
</front> | ||||
<seriesInfo name="RFC" value="9784"/> | ||||
<seriesInfo name="DOI" value="10.17487/9784"/> | ||||
</reference> | ||||
&RFC7623; | </references> | |||
<references> | ||||
<name>Informative References</name> | ||||
<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 | ||||
365.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 | ||||
623.xml"/> | ||||
</references> | ||||
</references> | </references> | |||
<section anchor="sect-7" numbered="false" toc="default"> | ||||
<name>Acknowledgements</name> | ||||
<t>The authors would like to thank <contact fullname="Kishore | ||||
Tiruveedhula"/> and <contact fullname="Sasha Vainshtein"/> for their | ||||
reviews and comments. Also, thank you to <contact fullname="Luc André | ||||
Burdet"/> and <contact fullname="Stephane Litkowski"/> for their | ||||
thorough reviews and suggestions for a new | ||||
Lowest-Preference Algorithm.</t> | ||||
</section> | ||||
<section anchor="sect-8" numbered="false" toc="default"> | ||||
<name>Contributors</name> | ||||
<t>In addition to the authors listed, the following individuals also | ||||
contributed to this document:</t> | ||||
<contact fullname="Tony Przygienda"> | ||||
<organization>Juniper</organization> | ||||
</contact> | ||||
<contact fullname="Satya Mohanty"> | ||||
<organization>Cisco</organization> | ||||
</contact> | ||||
<contact fullname="Kiran Nagaraj"> | ||||
<organization>Nokia</organization> | ||||
</contact> | ||||
<contact fullname="Vinod Prabhu"> | ||||
<organization>Nokia</organization> | ||||
</contact> | ||||
<contact fullname="Selvakumar Sivaraj"> | ||||
<organization>Juniper</organization> | ||||
</contact> | ||||
<contact fullname="Sami Boutros"> | ||||
<organization>VMWare</organization> | ||||
</contact> | ||||
</section> | ||||
</back> | </back> | |||
</rfc> | </rfc> | |||
End of changes. 181 change blocks. | ||||
606 lines changed or deleted | 739 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |