rfc9785v1.txt | rfc9785.txt | |||
---|---|---|---|---|
skipping to change at line 24 ¶ | skipping to change at line 24 ¶ | |||
Abstract | Abstract | |||
The Designated Forwarder (DF) in Ethernet Virtual Private Networks | The Designated Forwarder (DF) in Ethernet Virtual Private Networks | |||
(EVPNs) 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 (BUM) traffic 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 | multi-homing. The Designated Forwarder is selected out of a | |||
candidate list of PEs that advertise the same Ethernet Segment | candidate list of PEs that advertise the same Ethernet Segment | |||
Identifier (ESI) to the EVPN network, according to the Default | Identifier (ESI) to the EVPN network, according to the default DF | |||
Designated Forwarder Election algorithm. While the Default Algorithm | election algorithm. While the default algorithm provides an | |||
provides an efficient and automated way of selecting the Designated | efficient and automated way of selecting the Designated Forwarder | |||
Forwarder across different Ethernet Tags in the Ethernet Segment, | across different Ethernet Tags in the Ethernet Segment, there are | |||
there are some use cases where a more "deterministic" and user- | some use cases where a more "deterministic" and user-controlled | |||
controlled method is required. At the same time, Network Operators | method is required. At the same time, Network Operators require an | |||
require an easy way to force an on-demand Designated Forwarder | easy way to force an on-demand Designated Forwarder switchover in | |||
switchover in order to carry out some maintenance tasks on the | order to carry out some maintenance tasks on the existing Designated | |||
existing Designated Forwarder or control whether a new active PE can | Forwarder or control whether a new active PE can preempt the existing | |||
preempt the existing Designated Forwarder PE. | Designated Forwarder PE. | |||
This document proposes use of a Designated Forwarder Election | This document proposes use of a DF election algorithm that meets the | |||
algorithm that meets the requirements of determinism and operation | requirements of determinism and operation control. This document | |||
control. This document updates RFC 8584 by modifying the definition | updates RFC 8584 by modifying the definition of the DF Election | |||
of the DF Election Extended Community. | Extended Community. | |||
Status of This Memo | Status of This Memo | |||
This is an Internet Standards Track document. | This is an Internet Standards Track document. | |||
This document is a product of the Internet Engineering Task Force | This document is a product of the Internet Engineering Task Force | |||
(IETF). It represents the consensus of the IETF community. It has | (IETF). It represents the consensus of the IETF community. It has | |||
received public review and has been approved for publication by the | received public review and has been approved for publication by the | |||
Internet Engineering Steering Group (IESG). Further information on | Internet Engineering Steering Group (IESG). Further information on | |||
Internet Standards is available in Section 2 of RFC 7841. | Internet Standards is available in Section 2 of RFC 7841. | |||
skipping to change at line 103 ¶ | skipping to change at line 103 ¶ | |||
1.1. Problem Statement | 1.1. Problem Statement | |||
[RFC7432] defines the Designated Forwarder (DF) in EVPN networks as | [RFC7432] defines the Designated Forwarder (DF) in EVPN networks as | |||
the PE responsible for sending Broadcast, Unknown Unicast, and | the PE responsible for sending Broadcast, Unknown Unicast, and | |||
Multicast (BUM) traffic to a multi-homed device/network in the case | Multicast (BUM) traffic to a multi-homed device/network in the case | |||
of an All-Active multi-homing Ethernet Segment or BUM and unicast | of an All-Active multi-homing Ethernet Segment or BUM and unicast | |||
traffic to a multi-homed device or network in the case of Single- | traffic to a multi-homed device or network in the case of Single- | |||
Active multi-homing. The Designated Forwarder is selected out of a | Active multi-homing. The Designated Forwarder is selected out of a | |||
candidate list of PEs that advertise the Ethernet Segment Identifier | candidate list of PEs that advertise the Ethernet Segment Identifier | |||
(ESI) to the EVPN network and according to the Designated Forwarder | (ESI) to the EVPN network and according to the DF election algorithm | |||
Election Algorithm or to DF Alg as per [RFC8584]. | or to DF Alg as per [RFC8584]. | |||
While the Default Designated Forwarder Algorithm [RFC7432] or the | While the default DF algorithm or the Highest Random Weight (HRW) | |||
Highest Random Weight (HRW) algorithm [RFC8584] provide an efficient | algorithm [RFC8584] provide an efficient and automated way of | |||
and automated way of selecting the Designated Forwarder across | selecting the Designated Forwarder across different Ethernet Tags in | |||
different Ethernet Tags in the Ethernet Segment, there are some use | the Ethernet Segment, there are some use cases where a more user- | |||
cases where a more user-controlled method is required. At the same | controlled method is required. At the same time, Network Operators | |||
time, Network Operators require an easy way to force an on-demand | require an easy way to force an on-demand Designated Forwarder | |||
Designated Forwarder switchover in order to carry out some | switchover in order to carry out some maintenance tasks on the | |||
maintenance tasks on the existing Designated Forwarder or control | existing Designated Forwarder or control whether a new active PE can | |||
whether a new active PE can preempt the existing Designated Forwarder | preempt the existing Designated Forwarder PE. | |||
PE. | ||||
1.2. Solution Requirements | 1.2. Solution Requirements | |||
The procedures described in this document meet the following | The procedures described in this document meet the following | |||
requirements: | requirements: | |||
a. The solution provides an administrative preference option so that | a. The solution provides an administrative preference option so that | |||
the user can control in what order the candidate PEs may become | the user can control in what order the candidate PEs may become | |||
the Designated Forwarder, assuming they are all operationally | the Designated Forwarder, assuming they are all operationally | |||
ready to take over as the 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 the | among the PEs in the Ethernet Segment will be elected as the | |||
Designated Forwarder, based on the DF Algorithms described in | Designated Forwarder, based on the DF algorithms described in | |||
this document. | this document. | |||
b. The extensions described in this document work for Ethernet | b. The extensions described in this document work for Ethernet | |||
Segments [RFC7432] and virtual Ethernet Segments as defined in | Segments [RFC7432] and virtual Ethernet Segments as defined in | |||
[RFC9784]. | [RFC9784]. | |||
c. The user may force a PE to preempt the existing Designated | c. The user may force a PE to preempt the existing Designated | |||
Forwarder for a given Ethernet Tag without reconfiguring 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. | administrative preference in that PE. | |||
d. The solution allows an option to NOT preempt the current | d. The solution allows an option to NOT preempt the current | |||
Designated Forwarder (the "Don't Preempt" capability), even if | Designated Forwarder (the "Don't Preempt" Capability), even if | |||
the former Designated Forwarder PE comes back up after a failure. | the former Designated Forwarder PE comes back up after a failure. | |||
This is also known as "non-revertive" behavior, as opposed to the | This is also known as "non-revertive" behavior, as opposed to the | |||
Designated Forwarder election procedures [RFC7432] that are | DF election procedures [RFC7432] that are always revertive | |||
always revertive (because the winner PE of the default Designated | (because the winner PE of the default DF election algorithm | |||
Forwarder election algorithm always takes over as the operational | always takes over as the operational Designated Forwarder). | |||
Designated Forwarder). | ||||
e. The procedures described in this document support Single-Active | e. The procedures described in this document support Single-Active | |||
and All-Active multi-homing Ethernet Segments. | and All-Active multi-homing Ethernet Segments. | |||
1.3. Solution Overview | 1.3. Solution Overview | |||
To provide a solution that satisfies the above requirements, we | 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 (Section 3). Carried with the new DF | Election Extended Community (Section 3). Carried with the new DF | |||
Election Extended Community variants is a DF election preference | Election Extended Community variants is a DF election preference | |||
advertised for each PE that influences which PE will become the DF | advertised for each PE that influences which PE will become the DF | |||
(Section 4.1). The advertised DF election preference can dynamically | (Section 4.1). The advertised DF election preference can dynamically | |||
vary from the administratively configured preference to provide non- | vary from the administratively configured preference to provide non- | |||
revertive behavior (Section 4.3). In Section 4.2, an optional | revertive behavior (Section 4.3). In Section 4.2, an optional | |||
solution is discussed for use in Ethernet Segments that supports | solution is discussed for use in Ethernet Segments that supports | |||
large numbers of Ethernet Tags and therefore needs to balance load | large numbers of Ethernet Tags and therefore needs to balance load | |||
among multiple DFs. | among multiple DFs. | |||
skipping to change at line 180 ¶ | skipping to change at line 178 ¶ | |||
"OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
AC: Attachment Circuit. An AC has an Ethernet Tag associated to it. | AC: Attachment Circuit. An AC has an Ethernet Tag associated to it. | |||
CE: Customer Equipment router | CE: Customer Equipment router | |||
DF: Designated Forwarder | DF: Designated Forwarder | |||
DF Alg: Refers to the Designated Forwarder Election Algorithm, which | DF Alg: Refers to the DF election algorithm, which is sometimes | |||
is sometimes shortened to "Alg" in this document. | shortened to "Alg" in this document. | |||
DP: Refers to the "Don't Preempt" (me) capability in the DF Election | DP: Refers to the "Don't Preempt" Capability in the DF Election | |||
Extended Community. | Extended Community. | |||
ENNI: External Network-Network Interface | ENNI: External Network-Network Interface | |||
ES and vES: Ethernet Segment and virtual Ethernet Segment. | ES and vES: Ethernet Segment and virtual Ethernet Segment. | |||
Ethernet A-D per EVI route: Refers to [RFC7432] route type 1 or | Ethernet A-D per EVI route: Refers to Route Type 1 or Auto-Discovery | |||
Auto-Discovery per EVPN Instance route. | per EVPN Instance route [RFC7432]. | |||
EVC: Ethernet Virtual Circuit | EVC: Ethernet Virtual Circuit | |||
EVI: EVPN Instance | EVI: EVPN Instance | |||
Ethernet Tag: Used to represent a broadcast domain that is | Ethernet Tag: Used to represent a broadcast domain that is | |||
configured on a given Ethernet Segment for the purpose of | configured on a given Ethernet Segment for the purpose of DF | |||
Designated Forwarder election. Note that any of the following may | election. Note that any of the following may be used to represent | |||
be used to represent a broadcast domain: VLAN IDs (VIDs) | a broadcast domain: VLAN IDs (VIDs) (including Q-in-Q tags), | |||
(including Q-in-Q tags), configured IDs, VXLAN Network Identifiers | configured IDs, VXLAN Network Identifiers (VNIs), normalized VIDs, | |||
(VNIs), normalized VIDs, Service Instance Identifiers (I-SIDs), | Service Instance Identifiers (I-SIDs), etc., as long as the | |||
etc., as long as the representation of the broadcast domains is | representation of the broadcast domains is configured consistently | |||
configured consistently across the multi-homed PEs attached to | across the multi-homed PEs attached to that Ethernet Segment. The | |||
that Ethernet Segment. The Ethernet Tag value MUST NOT be zero. | Ethernet Tag value MUST NOT be zero. | |||
HRW: Highest Random Weight, as per [RFC8584]. | HRW: Highest Random Weight, as per [RFC8584]. | |||
OAM: Operations, Administration, and Maintenance. | OAM: Operations, Administration, and Maintenance. | |||
3. EVPN BGP Attribute Extensions | 3. EVPN BGP Attribute Extensions | |||
This solution reuses and extends the DF Election Extended Community | This solution reuses and extends the DF Election Extended Community | |||
defined in [RFC8584] that is advertised along with the Ethernet | defined in [RFC8584] that is advertised along with the Ethernet | |||
Segment route. It does so by replacing the last two reserved octets | Segment route. It does so by replacing the last two reserved octets | |||
of the DF Election Extended Community when the DF Algorithm is set to | of the DF Election Extended Community when the DF algorithm is set to | |||
Highest-Preference or Lowest-Preference. This document also defines | Highest-Preference or Lowest-Preference. This document also defines | |||
a new capability referred to as the "Don't Preempt" capability, which | a new capability referred to as the "Don't Preempt" Capability, which | |||
MAY be used with Highest-Preference or Lowest-Preference DF | MAY be used with Highest-Preference or Lowest-Preference Algorithms. | |||
Algorithms. The format of the DF Election Extended Community used in | The format of the DF Election Extended Community used in this | |||
this document is as follows: | document is as follows: | |||
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) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 1: DF Election Extended Community | Figure 1: DF Election Extended Community | |||
Where the above fields are defined as follows: | Where the above fields are defined as follows: | |||
* The DF Algorithm can have the following values: | * The DF algorithm can have the following values: | |||
- Alg 0 - Default Designated Forwarder Election algorithm, or | - Alg 0 - Default DF election algorithm, i.e., the modulus-based | |||
modulus-based algorithm as per [RFC7432]. | algorithm as per [RFC7432]. | |||
- Alg 1 - HRW algorithm as per [RFC8584]. | - Alg 1 - HRW algorithm as per [RFC8584]. | |||
- Alg 2 - Highest-Preference Algorithm (Section 4.1). | - Alg 2 - Highest-Preference Algorithm (Section 4.1). | |||
- Alg 3 - Lowest-Preference Algorithm (Section 4.1). | - Alg 3 - Lowest-Preference Algorithm (Section 4.1). | |||
* Bitmap (2 octets) encodes "capabilities" [RFC8584], whereas this | * Bitmap (2 octets) encodes "capabilities" [RFC8584], whereas this | |||
document defines the "Don't Preempt" capability, which is used to | document defines the "Don't Preempt" Capability, which is used to | |||
indicate if a PE supports a non-revertive behavior: | indicate if a PE supports a non-revertive behavior: | |||
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| | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 2: Bitmap Field in the DF Election Extended Community | Figure 2: Bitmap Field in the DF Election Extended Community | |||
- Bit 0 (corresponds to Bit 24 of the DF Election Extended | - Bit 0 (corresponds to Bit 24 of the DF Election Extended | |||
Community, and it is defined by this document): The D bit, or | Community, and it is defined by this document): The D bit, or | |||
'Don't Preempt' bit ("DP" hereafter), determines if the PE | "Don't Preempt" Capability, determines if the PE advertising | |||
advertising the Ethernet Segment route requests the remote PEs | the Ethernet Segment route requests the remote PEs in the | |||
in the Ethernet Segment to not preempt it as the Designated | Ethernet Segment to not preempt it as the Designated Forwarder. | |||
Forwarder. The default value is DP=0, which is compatible with | The default value is DP=0, which is compatible with the | |||
the 'preempt' or 'revertive' behavior in the Default DF | 'preempt' or 'revertive' behavior in the default DF algorithm | |||
Algorithm [RFC7432]. The DP capability is supported by the | [RFC7432]. The "Don't Preempt" Capability is supported by the | |||
Highest-Preference or Lowest-Preference DF Algorithms. The | Highest-Preference or Lowest-Preference Algorithms. The | |||
procedures of the "Don't Preempt" capability for other DF | procedures of the "Don't Preempt" Capability for other DF | |||
Algorithms are out of the scope of this document. The | algorithms are out of the scope of this document. The | |||
procedures of the "Don't Preempt" capability for the Highest- | procedures of the "Don't Preempt" Capability for the Highest- | |||
Preference and Lowest-Preference DF Algorithms are described in | Preference and Lowest-Preference Algorithms are described in | |||
Section 4.1. | Section 4.1. | |||
- Bit 1: AC-Influenced DF (AC-DF) election is described in | - Bit 1: AC-Influenced DF (AC-DF) election is described in | |||
[RFC8584]. When set to 1, it indicates the desire to use AC-DF | [RFC8584]. When set to 1, it indicates the desire to use AC-DF | |||
with the rest of the PEs in the Ethernet Segment. The AC-DF | with the rest of the PEs in the Ethernet Segment. The AC-DF | |||
capability bit MAY be set along with the DP capability and | capability bit MAY be set along with the "Don't Preempt" | |||
Highest-Preference or Lowest-Preference DF Algorithms. | Capability and Highest-Preference or Lowest-Preference | |||
Algorithms. | ||||
* Designated Forwarder (DF) Preference: Defines a 2-octet value that | * Designated Forwarder (DF) Preference: Defines a 2-octet value that | |||
indicates the PE preference to become the Designated Forwarder in | indicates the PE preference to become the Designated Forwarder in | |||
the Ethernet Segment, as described in Section 4.1. The allowed | the Ethernet Segment, as described in Section 4.1. The allowed | |||
values are within the range 0-65535, and the default value MUST be | values are within the range 0-65535, and the default value MUST be | |||
32767. This value is the midpoint in the allowed Preference range | 32767. This value is the midpoint in the allowed Preference range | |||
of values, which gives the operator the flexibility of choosing a | of values, which gives the operator the flexibility of choosing a | |||
significant number of values, above or below the default | significant number of values, above or below the default | |||
Preference. A numerically higher or lower value of this field is | Preference. A numerically higher or lower value of this field is | |||
more preferred for Designated Forwarder election depending on the | more preferred for DF election depending on the DF algorithm being | |||
DF Algorithm being used, as explained in Section 4.1. The | used, as explained in Section 4.1. The Designated Forwarder | |||
Designated Forwarder Preference field is specific to DF Algorithms | Preference field is specific to Highest-Preference and Lowest- | |||
Highest-Preference and Lowest-Preference, and this document does | Preference Algorithms, and this document does not define any | |||
not define any meaning for other algorithms. If the DF Algorithm | meaning for other algorithms. If the DF algorithm is different | |||
is different from Highest-Preference or Lowest-Preference, these 2 | from Highest-Preference or Lowest-Preference, these 2 octets can | |||
octets can be encoded differently. | be encoded differently. | |||
* RSV and Reserved fields (from bit 16 to bit 18, and from bit 40 to | * RSV and Reserved fields (from bit 16 to bit 18, and from bit 40 to | |||
47): When the DF Algorithm is set to Highest-Preference or Lowest- | 47): When the DF algorithm is set to Highest-Preference or Lowest- | |||
Preference, the values are set to zero when advertising the | Preference, the values are set to zero when advertising the | |||
Ethernet Segment route, and they are ignored when receiving the | Ethernet Segment route, and they are ignored when receiving the | |||
Ethernet Segment route. | Ethernet Segment route. | |||
4. Solution Description | 4. Solution Description | |||
Figure 3 illustrates an example that will be used in the description | Figure 3 illustrates an example that will be used in the description | |||
of the solution. | of the solution. | |||
EVPN Network | EVPN Network | |||
skipping to change at line 332 ¶ | skipping to change at line 331 ¶ | |||
--------------------+ | --------------------+ | |||
Figure 3: Preference-Based DF Election | Figure 3: Preference-Based DF Election | |||
Figure 3 shows three PEs that are connecting EVCs coming from the | Figure 3 shows three PEs that are connecting EVCs coming from the | |||
Aggregation Network to their EVIs in the EVPN network. CE1 is | Aggregation Network to their EVIs in the EVPN network. CE1 is | |||
connected to vES1, which spans PE1 and PE2, and CE2 is connected to | connected to vES1, which spans PE1 and PE2, and CE2 is connected to | |||
vES2, which is attached to PE1, PE2, and PE3. | vES2, which is attached to PE1, PE2, and PE3. | |||
If the algorithm chosen for vES1 and vES2 is the Highest-Preference | If the algorithm chosen for vES1 and vES2 is the Highest-Preference | |||
or Lowest-Preference DF Algorithm, the PEs may become the Designated | or Lowest-Preference Algorithm, the PEs may become the 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 | examples of the procedures and how they are applied in the use case | |||
of Figure 3. | of Figure 3. | |||
4.1. Use of the Highest-Preference and Lowest-Preference Algorithm | 4.1. Use of the Highest-Preference and Lowest-Preference Algorithm | |||
Assuming the operator wants to control -- in a flexible way -- what | 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 a Designated Forwarder | Segment and the order in which the PEs become a Designated Forwarder | |||
in case of multiple failures, the Highest-Preference or Lowest- | in case of multiple failures, the Highest-Preference or Lowest- | |||
Preference Algorithms can be used. Per the example in Figure 3, | Preference Algorithms can be used. Per the example in Figure 3, | |||
these algorithms are used as follows: | these algorithms are used as follows: | |||
a. vES1 and vES2 are now configurable with three optional parameters | a. vES1 and vES2 are now configurable with three optional parameters | |||
that are signaled in the DF Election Extended Community. These | that are signaled in the DF Election Extended Community. These | |||
parameters are the Preference, Preemption (or "Don't Preempt") | parameters are the Preference, Preemption (or "Don't Preempt" | |||
option, and DF Algorithm. We will represent these parameters as | Capability) option, and DF algorithm. We will represent these | |||
(Pref,DP,Alg). For instance, vES1 (Pref,DP,Alg) is configured as | parameters as (Pref, DP, Alg). For instance, vES1 (Pref, DP, | |||
(500,0,Highest-Preference) in PE1 and as (255,0,Highest- | Alg) is configured as: | |||
Preference) in PE2. vES2 is configured as (100,0,Highest- | ||||
Preference), (200,0,Highest-Preference), and (300,0,Highest- | (500, 0, Highest-Preference) in PE1, | |||
Preference) in PE1, PE2, and PE3, respectively. | (255, 0, Highest-Preference) in PE2. | |||
vES2 is configured as | ||||
(100, 0, Highest-Preference) in PE1, | ||||
(200, 0, Highest-Preference) in PE2, and | ||||
(300, 0, Highest-Preference) in PE3. | ||||
b. The PEs advertise an Ethernet Segment route for each virtual | b. 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 DF Election Extended Community (encoded as | above, in the DF Election Extended Community (encoded as | |||
described in Section 3). | described in Section 3). | |||
c. According to [RFC8584], each PE will run the Designated Forwarder | c. According to [RFC8584], each PE will run the DF election | |||
election algorithm upon expiration of the DF Wait timer. Each PE | algorithm upon expiration of the DF Wait timer. Each PE runs the | |||
runs the Highest-Preference or Lowest-Preference DF Algorithm for | Highest-Preference or Lowest-Preference Algorithm for each | |||
each Ethernet Segment as follows: | Ethernet Segment as follows: | |||
* The PE will check the DF Algorithm value in each Ethernet | * 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 | procedure in this section. Otherwise, the procedure falls | |||
back to the Default Algorithm [RFC7432]. The Highest- | back to the default DF algorithm [RFC7432]. The Highest- | |||
Preference and Lowest-Preference Algorithms are different | Preference and Lowest-Preference Algorithms are different | |||
algorithms; therefore, if two PEs configured for Highest- | algorithms; therefore, if two PEs configured for Highest- | |||
Preference and Lowest-Preference, respectively, are attached | Preference and Lowest-Preference, respectively, are attached | |||
to the same Ethernet Segment, the operational Designated | to the same Ethernet Segment, the operational DF election | |||
Forwarder Election Algorithm will fall back to the Default | algorithm will fall back to the default DF algorithm. | |||
Algorithm. | ||||
* If all the PEs attached to the Ethernet Segment advertise the | * If all the PEs attached to the Ethernet Segment advertise the | |||
Highest-Preference Algorithm, each PE builds a list of | 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. For example, PE1 | numerically highest value to lowest value. For example, PE1 | |||
builds a list of candidate PEs for vES1 ordered by the | builds a list of candidate PEs for vES1 ordered by the | |||
Preference, from high to low: <PE1, PE2> (since PE1's | Preference, from high to low: <PE1, PE2> (since PE1's | |||
preference is more preferred than PE2's). Hence, PE1 becomes | preference is more preferred than PE2's). Hence, PE1 becomes | |||
the Designated Forwarder for vES1. In the same way, PE3 | the Designated Forwarder for vES1. In the same way, PE3 | |||
becomes the Designated Forwarder for vES2. | becomes the Designated Forwarder for vES2. | |||
* If all the PEs attached to the Ethernet Segment advertise the | * If all the PEs attached to the Ethernet Segment advertise the | |||
Lowest-Preference Algorithm, then the candidate list is | 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. For example, PE1's ordered list for | highest preference value. For example, PE1's ordered list for | |||
vES1 is <PE2, PE1>. Hence, PE2 becomes the Designated | vES1 is <PE2, PE1>. Hence, PE2 becomes the Designated | |||
Forwarder for vES1. In the same way, PE1 becomes the | Forwarder for vES1. In the same way, PE1 becomes the | |||
Designated Forwarder for vES2. | Designated Forwarder for vES2. | |||
d. Assuming some maintenance tasks had to be executed on a PE, the | d. 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. For example, if PE3 is going on | service is minimized. For example, if PE3 is going on | |||
maintenance and the DF Algorithm is Highest-Preference, the | maintenance and the DF algorithm is Highest-Preference, the | |||
operator could change vES2's Preference on PE3 from 300 to, e.g., | operator could change vES2's Preference on PE3 from 300 to, e.g., | |||
50 (hence, the Ethernet Segment route from PE3 is updated with | 50 (hence, the Ethernet Segment route from PE3 is updated with | |||
the new preference value), so that PE2 is forced to take over as | the new preference value), so that PE2 is forced to take over as | |||
Designated Forwarder for vES2 (irrespective of the DP | Designated Forwarder for vES2 (irrespective of the "Don't | |||
capability). Once the maintenance task on PE3 is over, the | Preempt" Capability). Once the maintenance task on PE3 is over, | |||
operator could decide to leave the latest configured preference | the operator could decide to leave the latest configured | |||
value or configure the initial preference value back. A similar | preference value or configure the initial preference value back. | |||
procedure can be used for the Lowest-Preference DF Algorithm too. | A similar procedure can be used for the Lowest-Preference | |||
For example, suppose the algorithm for vES2 is Lowest-Preference, | Algorithm too. For example, suppose the algorithm for vES2 is | |||
and PE1 (the DF) goes on maintenance mode. The operator could | Lowest-Preference, and PE1 (the DF) goes on maintenance mode. | |||
change vES2's Preference on PE1 from 100 to, e.g., 250, so that | The operator could change vES2's Preference on PE1 from 100 to, | |||
PE2 is forced to take over as the Designated Forwarder for vES2. | e.g., 250, so that PE2 is forced to take over as the Designated | |||
Forwarder for vES2. | ||||
e. In case of equal Preference in two or more PEs in the Ethernet | e. 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 | |||
candidate PE(s) are used as tiebreakers. The procedures for the | lowest IP address of the candidate PE(s) are used as tiebreakers. | |||
use of the DP bit are specified in Section 4.3. If more than one | The procedures for the use of the "Don't Preempt" Capability are | |||
PE is advertising itself as the preferred Designated Forwarder, | specified in Section 4.3. If more than one PE is advertising | |||
an implementation MUST first select the PE advertising the DP bit | itself as the preferred Designated Forwarder, an implementation | |||
set, and then select the PE with the lowest IP address (if the DP | MUST first select the PE advertising the "Don't Preempt" | |||
bit selection does not yield a unique candidate). The PE's IP | Capability set, and then select the PE with the lowest IP address | |||
address is the address used in the candidate list, and it is | (if the "Don't Preempt" Capability selection does not yield a | |||
derived from the Originating Router's IP address of the Ethernet | unique candidate). The PE's IP address is the address used in | |||
Segment route. In case PEs use the Originating Router's IP | the candidate list, and it is derived from the Originating | |||
address of different families, an IPv4 address is always | Router's IP address of the Ethernet Segment route. In case PEs | |||
considered numerically lower than an IPv6 address. Some examples | use the Originating Router's IP address of different families, an | |||
of using the DP bit and IP address tiebreakers follow: | IPv4 address is always considered numerically lower than an IPv6 | |||
address. Some examples of using the "Don't Preempt" Capability | ||||
and IP address tiebreakers follow: | ||||
* If vES1 parameters were (500,0,Highest-Preference) in PE1 and | * If vES1 parameters were (500, 0, Highest-Preference) in PE1 | |||
(500,1,Highest-Preference) in PE2, PE2 would be elected due to | and (500, 1, Highest-Preference) in PE2, PE2 would be elected | |||
the DP bit. The same example applies if PE1 and PE2 advertise | due to the "Don't Preempt" Capability. The same example | |||
the Lowest-Preference DF Algorithm instead. | applies if PE1 and PE2 advertise the Lowest-Preference | |||
Algorithm instead. | ||||
* If vES1 parameters were (500,0,Highest-Preference) in PE1 and | * If vES1 parameters were (500, 0, Highest-Preference) in PE1 | |||
(500,0,Highest-Preference) in PE2, PE1 would be elected, if | and (500, 0, Highest-Preference) in PE2, PE1 would be elected, | |||
PE1's IP address is lower than PE2's. Or PE2 would be elected | if PE1's IP address is lower than PE2's. Or PE2 would be | |||
if PE2's IP address is lower than PE1's. The same example | elected if PE2's IP address is lower than PE1's. The same | |||
applies if PE1 and PE2 advertise the Lowest-Preference DF | example applies if PE1 and PE2 advertise the Lowest-Preference | |||
Algorithm instead. | Algorithm instead. | |||
f. The Preference is an administrative option that MUST be | f. The Preference is an administrative option that MUST be | |||
configured on a per-Ethernet-Segment basis, and it is normally | configured on a per-Ethernet-Segment basis, and it is normally | |||
configured from the management plane. The Preference value MAY | configured from the management plane. The preference value MAY | |||
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 | that react to events on the PE. The following examples | |||
illustrate the use of local policy to change the Preference value | illustrate the use of local policy to change the preference value | |||
in a dynamic way. | in a dynamic way. | |||
* On PE1, if the DF Algorithm is Highest-Preference, ES1's | * On PE1, if the DF algorithm is Highest-Preference, ES1's | |||
Preference value can be lowered from 500 to 100 in case the | preference value can be lowered from 500 to 100 in case the | |||
bandwidth on the ENNI port is decreased by 50% (that could | 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). | and the Aggregation Network loses one port). | |||
* Local policy MAY also trigger dynamic Preference changes based | * Local policy MAY also trigger dynamic Preference changes based | |||
on the PE's bandwidth availability in the core, specific ports | on the PE's bandwidth availability in the core, specific ports | |||
going operationally down, etc. | going operationally down, etc. | |||
* The definition of the actual local policies is out of scope of | * The definition of the actual local policies is out of scope of | |||
this document. | this document. | |||
Highest-Preference and Lowest-Preference Algorithms MAY be used along | Highest-Preference and Lowest-Preference Algorithms MAY be used along | |||
with the AC-DF capability. Assuming all the PEs in the Ethernet | with the AC-DF capability. Assuming all the PEs in the Ethernet | |||
Segment are configured consistently with the 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 | |||
Forwarder Election until its corresponding Ethernet A-D per ES and | until its corresponding Ethernet A-D per ES and Ethernet A-D per EVI | |||
Ethernet A-D per EVI routes are received, as described in [RFC8584]. | routes are received, as described in [RFC8584]. | |||
Highest-Preference and Lowest-Preference DF Algorithms can be used in | Highest-Preference and Lowest-Preference Algorithms can be used in | |||
different virtual Ethernet Segments on the same PE. For instance, | different virtual Ethernet Segments on the same PE. For instance, | |||
PE1 and PE2 can use Highest-Preference for vES1 and PE1, and PE2 and | PE1 and PE2 can use Highest-Preference for vES1 and PE1, and PE2 and | |||
PE3 can use Lowest-Preference for vES2. The use of one DF Algorithm | 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 | over the other is the operator's choice. The existence of both | |||
provides flexibility and full control to the operator. | provides flexibility and full control to the operator. | |||
The procedures in this document can be used in an Ethernet Segment as | The procedures in this document can be used in an Ethernet Segment as | |||
defined in [RFC7432] or a virtual Ethernet Segment per [RFC9784] and | defined in [RFC7432] or a virtual Ethernet Segment per [RFC9784] and | |||
also in EVPN networks as described in [RFC8214], [RFC7623], or | also in EVPN networks as described in [RFC8214], [RFC7623], or | |||
[RFC8365]. | [RFC8365]. | |||
4.2. Use of the Highest-Preference or Lowest-Preference Algorithm in | 4.2. Use of the Highest-Preference or Lowest-Preference Algorithm in | |||
Ethernet Segments | Ethernet Segments | |||
While the Highest-Preference or Lowest-Preference DF Algorithm | While the Highest-Preference or Lowest-Preference Algorithm described | |||
described in Section 4.1 is typically used in virtual Ethernet | in Section 4.1 is typically used in virtual Ethernet Segment | |||
Segment scenarios where there is normally an individual Ethernet Tag | scenarios where there is normally an individual Ethernet Tag per | |||
per virtual Ethernet Segment, the existing definition of an Ethernet | virtual Ethernet Segment, the existing definition of an Ethernet | |||
Segment [RFC7432] allows potentially up to thousands of Ethernet Tags | Segment [RFC7432] allows potentially up to thousands of Ethernet Tags | |||
on the same Ethernet Segment. If this is the case, and if the | on the same Ethernet Segment. If this is the case, and if the | |||
Highest-Preference or Lowest-Preference Algorithm is configured in | Highest-Preference or Lowest-Preference Algorithm is configured in | |||
all the PEs of the Ethernet Segment, the same PE will be the elected | all the PEs of the Ethernet Segment, the same PE will be the elected | |||
Designated Forwarder for all the Ethernet Tags of the Ethernet | Designated Forwarder for all the Ethernet Tags of the Ethernet | |||
Segment. A potential way to achieve a more granular load balancing | Segment. A potential way to achieve a more granular load balancing | |||
is described below. | is described below. | |||
The Ethernet Segment is configured with an administrative Preference | The Ethernet Segment is configured with an administrative preference | |||
value and an administrative DF Algorithm, i.e., Highest-Preference or | value and an administrative DF algorithm, i.e., Highest-Preference or | |||
Lowest-Preference Algorithm. However, the administrative DF | Lowest-Preference Algorithm. However, the administrative DF | |||
Algorithm (which is used to signal the DF Algorithm for the Ethernet | algorithm (which is used to signal the DF algorithm for the Ethernet | |||
Segment) MAY be overridden to a different operational DF Algorithm | Segment) MAY be overridden to a different operational DF algorithm | |||
for a range of Ethernet Tags. With this option, the PE builds a list | for a range of Ethernet Tags. With this option, the PE builds a list | |||
of candidate PEs ordered by Preference; however, the Designated | of candidate PEs ordered by Preference; however, the Designated | |||
Forwarder for a given Ethernet Tag will be determined by the locally | Forwarder for a given Ethernet Tag will be determined by the locally | |||
overridden DF Algorithm. | overridden DF algorithm. | |||
For instance: | For instance: | |||
* Assuming ES3 is defined in PE1 and PE2, PE1 may be configured as | * Assuming ES3 is defined in PE1 and PE2, PE1 may be configured as | |||
(500,0,Highest-Preference) and PE2 as (100,0,Highest-Preference) | (500, 0, Highest-Preference) and PE2 as (100, 0, Highest- | |||
for ES3. Both PEs will advertise the Ethernet Segment routes for | Preference) for ES3. Both PEs will advertise the Ethernet Segment | |||
ES3 with the indicated parameters in the DF Election Extended | routes for ES3 with the indicated parameters in the DF Election | |||
Community. | Extended Community. | |||
* In addition, assuming there are VLAN-based service interfaces and | * In addition, assuming there are VLAN-based service interfaces and | |||
that the PEs are attached to all Ethernet Tags in the range | that the PEs are attached to all Ethernet Tags in the range | |||
1-4000, both PE1 and PE2 may be configured with (Ethernet Tag- | 1-4000, both PE1 and PE2 may be configured with (Ethernet Tag- | |||
range, Lowest-Preference), e.g., (2001-4000, Lowest-Preference). | range, Lowest-Preference), e.g., (2001-4000, Lowest-Preference). | |||
* This will result in PE1 being the Designated Forwarder for | * This will result in PE1 being the Designated Forwarder for | |||
Ethernet Tags 1-2000 (since they use the default Highest- | Ethernet Tags 1-2000 (since they use the default Highest- | |||
Preference Algorithm) and PE2 being the Designated Forwarder for | Preference Algorithm) and PE2 being the Designated Forwarder for | |||
Ethernet Tags 2001-4000, due to the local policy overriding the | Ethernet Tags 2001-4000, due to the local policy overriding the | |||
skipping to change at line 553 ¶ | skipping to change at line 561 ¶ | |||
more than two PEs per Ethernet Segment exist and a good load- | more than two PEs per Ethernet Segment exist and a good load- | |||
balancing distribution per Ethernet Tag of the Designated Forwarder | balancing distribution per Ethernet Tag of the Designated Forwarder | |||
function is desired. | function is desired. | |||
4.3. The Non-Revertive Capability | 4.3. The Non-Revertive Capability | |||
As discussed in item d of Section 1.2, a capability to NOT preempt | As discussed in item d of Section 1.2, a capability to NOT preempt | |||
the existing Designated Forwarder (for all the Ethernet Tags in the | the existing Designated Forwarder (for all the Ethernet Tags in the | |||
Ethernet Segment) is required and therefore added to the DF Election | Ethernet Segment) is required and therefore added to the DF Election | |||
Extended Community. This option allows a non-revertive behavior in | Extended Community. This option allows a non-revertive behavior in | |||
the Designated Forwarder election. | the DF election. | |||
Note that when a given PE in an Ethernet Segment is taken down for | Note that when a given PE in an Ethernet Segment is taken down for | |||
maintenance operations, before bringing it back, the Preference may | maintenance operations, before bringing it back, the Preference may | |||
be changed in order to provide a non-revertive behavior. The DP bit | be changed in order to provide a non-revertive behavior. The "Don't | |||
and the mechanism explained in this section will be used for those | Preempt" Capability and the mechanism explained in this section will | |||
cases when a former Designated Forwarder comes back up without any | be used for those cases when a former Designated Forwarder comes back | |||
controlled maintenance operation, and the non-revertive option is | up without any controlled maintenance operation, and the non- | |||
desired in order to avoid service impact. | revertive option is desired in order to avoid service impact. | |||
In Figure 3, we assume that based on the Highest-Preference | In Figure 3, we assume that based on the Highest-Preference | |||
Algorithm, PE3 is the Designated Forwarder for ESI2. | Algorithm, PE3 is the Designated Forwarder for ESI2. | |||
If PE3 has a link, EVC, or node failure, PE2 would take over as the | If PE3 has a link, EVC, or node failure, PE2 would take over as the | |||
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 Segment. | over, causing some unnecessary packet loss in the Ethernet Segment. | |||
The following procedure avoids preemption upon failure recovery (see | The following procedure avoids preemption upon failure recovery (see | |||
Figure 3). The procedure supports a non-revertive mode that can be | Figure 3). The procedure supports a non-revertive mode that can be | |||
skipping to change at line 587 ¶ | skipping to change at line 595 ¶ | |||
* Highest-Preference or Lowest-Preference Algorithm, where a local | * Highest-Preference or Lowest-Preference Algorithm, where a local | |||
policy overrides the Highest-/Lowest-Preference tiebreaker for a | policy overrides the Highest-/Lowest-Preference tiebreaker for a | |||
range of Ethernet Tags (Section 4.2) | range of Ethernet Tags (Section 4.2) | |||
The procedure is described, assuming the Highest-Preference Algorithm | The procedure is described, assuming the Highest-Preference Algorithm | |||
in the Ethernet Segment, where local policy overrides the tiebreaker | in the Ethernet Segment, where local policy overrides the tiebreaker | |||
for a given Ethernet Tag. The other cases above are a subset of this | for a given Ethernet Tag. The other cases above are a subset of this | |||
one, and the differences are explained. | one, and the differences are explained. | |||
1. A "Don't Preempt" capability is defined on a per-PE / per- | 1. A "Don't Preempt" Capability is defined on a per-PE / per- | |||
Ethernet-Segment basis, as described in Section 3. If "Don't | Ethernet-Segment basis, as described in Section 3. If "Don't | |||
Preempt" is disabled (default behavior), the PE sets DP to zero | Preempt" is disabled (default behavior), the PE sets DP to zero | |||
and advertises it in an Ethernet Segment route. If "Don't | and advertises it in an Ethernet Segment route. If "Don't | |||
Preempt" is enabled, the Ethernet Segment route from the PE | Preempt" is enabled, the Ethernet Segment route from the PE | |||
indicates the desire of not being preempted by the other PEs in | indicates the desire of not being preempted by the other PEs in | |||
the Ethernet Segment. All the PEs in an Ethernet Segment should | the Ethernet Segment. All the PEs in an Ethernet Segment should | |||
be consistent in their configuration of the DP capability; | be consistent in their configuration of the "Don't Preempt" | |||
however, this document does not enforce the consistency across | Capability; however, this document does not enforce the | |||
all the PEs. In case of inconsistency in the support of the DP | consistency across all the PEs. In case of inconsistency in the | |||
capability in the PEs of the same Ethernet Segment, non-revertive | support of the "Don't Preempt" Capability in the PEs of the same | |||
behavior is not guaranteed. However, PEs supporting this | Ethernet Segment, non-revertive behavior is not guaranteed. | |||
capability still attempt this procedure. | However, PEs supporting this capability still attempt this | |||
procedure. | ||||
2. Assuming we want to avoid 'preemption' in all the PEs in the | 2. 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 | Preempt" Capability. In this example, we assume ESI2 is | |||
configured as 'DP=enabled' in the three PEs. | configured as 'DP=enabled' in the three PEs. | |||
3. We also assume vES2 is attached to Ethernet Tag-1 and Ethernet | 3. We also assume vES2 is attached to Ethernet Tag-1 and Ethernet | |||
Tag-2. vES2 uses Highest-Preference as the DF Algorithm, and a | Tag-2. vES2 uses Highest-Preference as the DF algorithm, and a | |||
local policy is configured in the three PEs to use Lowest- | local policy is configured in the three PEs to use Lowest- | |||
Preference for Ethernet Tag-2. When vES2 is enabled in the three | Preference for Ethernet Tag-2. When vES2 is enabled in the three | |||
PEs, the PEs will exchange the Ethernet Segment routes and select | PEs, the PEs will exchange the Ethernet Segment routes and select | |||
PE3 as the Designated Forwarder for Ethernet Tag-1 (due to the | PE3 as the Designated Forwarder for Ethernet Tag-1 (due to the | |||
Highest-Preference) and PE1 as the Designated Forwarder for | Highest-Preference) and PE1 as the Designated Forwarder for | |||
Ethernet Tag-2 (due to the Lowest-Preference). | Ethernet Tag-2 (due to the Lowest-Preference). | |||
4. If PE3's vES2 goes down (due to an EVC failure (as detected by | 4. If PE3's vES2 goes down (due to an EVC failure (as detected by | |||
OAM protocols), a port failure, or a node failure), PE2 will | OAM protocols), a port failure, or a node failure), PE2 will | |||
become the Designated Forwarder for Ethernet Tag-1. No changes | become the Designated Forwarder for Ethernet Tag-1. No changes | |||
will occur for Ethernet Tag-2. | will occur for Ethernet Tag-2. | |||
5. When PE3's vES2 comes back up, PE3 will start a boot-timer (if | 5. 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 | timer will allow some time for PE3 to receive the Ethernet | |||
Segment routes from PE1 and PE2. This timer is applied between | Segment routes from PE1 and PE2. This timer is applied between | |||
the INIT and the DF_WAIT states in the Designated Forwarder | the INIT and the DF_WAIT states in the DF election Finite State | |||
Election Finite State Machine described in [RFC8584]. PE3 will | Machine described in [RFC8584]. PE3 will then: | |||
then: | ||||
* Select a "reference-PE" among the Ethernet Segment routes in | * Select a "reference-PE" among the Ethernet Segment routes in | |||
the virtual Ethernet Segment. If the Ethernet Segment uses | the virtual Ethernet Segment. If the Ethernet Segment uses | |||
the Highest-Preference Algorithm, select a "Highest-PE". If | the Highest-Preference Algorithm, select a "Highest-PE". If | |||
it uses the Lowest-Preference Algorithm, select a "Lowest-PE". | it uses the Lowest-Preference Algorithm, select a "Lowest-PE". | |||
If a local policy is in use, to override the Highest-/Lowest- | If a local policy is in use, to override the Highest-/Lowest- | |||
Preference for a range of Ethernet Tags (as discussed in | Preference for a range of Ethernet Tags (as discussed in | |||
Section 4.2), it is necessary to select both a Highest-PE and | Section 4.2), it is necessary to select both a Highest-PE and | |||
a Lowest-PE. They are selected as follows: | a Lowest-PE. They are selected as follows: | |||
- The Highest-PE is the PE with higher Preference, using the | - 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) | |||
lower PE-IP address as tiebreakers. | and, after that, the lower PE-IP address as tiebreakers. | |||
- The Lowest-PE is the PE with lower Preference, using the DP | - The Lowest-PE is the PE with lower Preference, using the | |||
bit first (with DP=1 being better) and, after that, the | "Don't Preempt" Capability first (with DP=1 being better) | |||
lower PE-IP address as tiebreakers. | and, after that, the lower PE-IP address as tiebreakers. | |||
- In our example, the Highest-Preference Algorithm is used, | - In our example, the Highest-Preference Algorithm is used, | |||
with a local policy to override it to use Lowest-Preference | with a local policy to override it to use Lowest-Preference | |||
for a range of Ethernet Tags. Therefore, PE3 selects a | for a range of Ethernet Tags. Therefore, PE3 selects a | |||
Highest-PE and a Lowest-PE. PE3 will select PE2 as the | Highest-PE and a Lowest-PE. PE3 will select PE2 as the | |||
Highest-PE over PE1, because when comparing (Pref,DP,PE- | Highest-PE over PE1, because when comparing (Pref, DP, PE- | |||
IP), (200,1,PE2-IP) wins over (100,1,PE1-IP). PE3 will | IP), (200, 1, PE2-IP) wins over (100, 1, PE1-IP). PE3 will | |||
select PE1 as the Lowest-PE over PE2, because | select PE1 as the Lowest-PE over PE2, because (100, 1, | |||
(100,1,PE1-IP) wins over (200,1,PE2-IP). Note that if | PE1-IP) wins over (200, 1, PE2-IP). Note that if there | |||
there were only one remote PE in the Ethernet Segment, the | were only one remote PE in the Ethernet Segment, the Lowest | |||
Lowest and Highest PE would be the same PE. | and Highest PE would be the same PE. | |||
* Check its own administrative Pref and compare it with the one | * Check its own administrative Pref and compare it with the one | |||
of the Highest-PE and Lowest-PE that have the DP capability | of the Highest-PE and Lowest-PE that have the "Don't Preempt" | |||
set in their Ethernet Segment routes. Depending on this | Capability set in their Ethernet Segment routes. Depending on | |||
comparison, PE3 sends the Ethernet Segment route with a | this comparison, PE3 sends the Ethernet Segment route with a | |||
(Pref,DP) that may be different from its administrative | (Pref, DP) that may be different from its administrative | |||
(Pref,DP): | (Pref, DP): | |||
- If PE3's Pref value is higher than or equal to the Highest- | - If PE3's Pref value is higher than or equal to the Highest- | |||
PE's, PE3 will send the Ethernet Segment route with an 'in- | PE's, PE3 will send the Ethernet Segment route with an 'in- | |||
use' operational Pref equal to the Highest-PE's and DP=0. | use' operational Pref equal to the Highest-PE's and DP=0. | |||
- If PE3's Pref value is lower than or equal to the Lowest- | - If PE3's Pref value is lower than or equal to the Lowest- | |||
PE's, PE3 will send the Ethernet Segment route with an 'in- | PE's, PE3 will send the Ethernet Segment route with an 'in- | |||
use' operational Preference equal to the Lowest-PE's and | use' operational Preference equal to the Lowest-PE's and | |||
DP=0. | DP=0. | |||
- If PE3's Pref value is not higher than or equal to the | - 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- | Highest-PE's and is not lower than or equal to the Lowest- | |||
PE's, PE3 will send the Ethernet Segment route with its | PE's, PE3 will send the Ethernet Segment route with its | |||
administrative (Pref,DP)=(300,1). | administrative (Pref, DP)=(300, 1). | |||
- In this example, PE3's administrative Pref=300 is higher | - In this example, PE3's administrative Pref=300 is higher | |||
than the Highest-PE with DP=1, that is, PE2 (Pref=200). | than the Highest-PE with DP=1, that is, PE2 (Pref=200). | |||
Hence, PE3 will inherit PE2's preference and send the | Hence, PE3 will inherit PE2's preference and send the | |||
Ethernet Segment route with an operational 'in-use' | Ethernet Segment route with an operational 'in-use' (Pref, | |||
(Pref,DP)=(200,0). | DP)=(200, 0). | |||
* Note that a PE will always send its DP capability set to zero | * Send its "Don't Preempt" Capability set to zero, as long as | |||
as long as the advertised Pref is the 'in-use' operational | the advertised Pref is the 'in-use' operational Pref (as | |||
Pref (as opposed to the 'administrative' Pref). | opposed to the 'administrative' Pref). | |||
* This Ethernet Segment route update sent by PE3, with | * Not trigger any Designated Forwarder changes for Ethernet Tag- | |||
(200,0,PE3-IP), will not cause any Designated Forwarder | 1. This Ethernet Segment route update sent by PE3, with (200, | |||
switchover for any Ethernet Tag. PE2 will continue being the | 0, PE3-IP), will not cause any Designated Forwarder switchover | |||
Designated Forwarder for Ethernet Tag-1. This is because the | for any Ethernet Tag. This is because the "Don't Preempt" | |||
DP bit will be used as a tiebreaker in the Designated | Capability will be used as a tiebreaker in the DF election. | |||
Forwarder election. That is, if a PE has two candidate PEs | That is, if a PE has two candidate PEs with the same Pref, it | |||
with the same Pref, it will pick the one with DP=1. There are | will pick the one with DP=1. There are no Designated | |||
no Designated Forwarder changes for Ethernet Tag-2 either. | Forwarder changes for Ethernet Tag-2 either. | |||
6. For any subsequent received update/withdraw in the Ethernet | 6. 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 the Highest-PEs and Lowest-PEs, now considering themselves | select the Highest-PEs and Lowest-PEs, now considering themselves | |||
as candidates. For instance, if PE2 fails upon receiving PE2's | as candidates. For instance, if PE2 fails upon receiving PE2's | |||
Ethernet Segment route withdrawal, PE3 and PE1 will go through | Ethernet Segment route withdrawal, PE3 and PE1 will go through | |||
the selection of the new Highest-PEs and Lowest-PEs (considering | the selection of the new Highest-PEs and Lowest-PEs (considering | |||
their own active Ethernet Segment route), and then they will run | their own active Ethernet Segment route), and then they will run | |||
the Designated Forwarder Election. | the DF election. | |||
* If a PE selects itself as the new Highest-PE or Lowest-PE and | * 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 | it 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 | administrative Pref and DP values. In the example, PE3 will | |||
be the new Highest-PE; therefore, it will send an Ethernet | be the new Highest-PE; therefore, it will send an Ethernet | |||
Segment route update with (Pref,DP)=(300,1). | Segment route update with (Pref, DP)=(300, 1). | |||
* After running the Designated Forwarder Election, PE3 will | * After running the DF election, PE3 will become the new | |||
become the new Designated Forwarder for Ethernet Tag-1. No | Designated Forwarder for Ethernet Tag-1. No changes will | |||
changes will occur for Ethernet Tag-2. | occur for Ethernet Tag-2. | |||
Note that, irrespective of the DP bit, when a PE or Ethernet Segment | Note that, irrespective of the "Don't Preempt" Capability, when a PE | |||
comes back and the PE advertises a Designated Forwarder Election | 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 | algorithm different from the one configured in the rest of the PEs in | |||
the Ethernet Segment, all the PEs in the Ethernet Segment MUST fall | the Ethernet Segment, all the PEs in the Ethernet Segment MUST fall | |||
back to the Default [RFC7432] Algorithm. | back to the default DF algorithm [RFC7432]. | |||
This document does not modify the use of the P and B bits in the | This document does not modify the use of the P and B bits in the | |||
Ethernet A-D per EVI routes [RFC8214] advertised by the PEs in the | Ethernet A-D per EVI routes [RFC8214] advertised by the PEs in the | |||
Ethernet Segment after running the Designated Forwarder Election, | Ethernet Segment after running the DF election, irrespective of the | |||
irrespective of the revertive or non-revertive behavior in the PE. | revertive or non-revertive behavior in the PE. | |||
5. Security Considerations | 5. Security Considerations | |||
This document describes a Designated Forwarder Election Algorithm | This document describes a DF election algorithm that provides | |||
that provides absolute control (by configuration) over what PE is the | absolute control (by configuration) over what PE is the Designated | |||
Designated Forwarder for a given Ethernet Tag. While this control is | Forwarder for a given Ethernet Tag. While this control is desired in | |||
desired in many situations, a malicious user that gets access to the | many situations, a malicious user that gets access to the | |||
configuration of a PE in the Ethernet Segment may change the behavior | configuration of a PE in the Ethernet Segment may change the behavior | |||
of the network. In other DF Algorithms such as HRW, the Designated | of the network. In other DF algorithms such as HRW, the DF election | |||
Forwarder Election is more automated and cannot be determined by | is more automated and cannot be determined by configuration. If the | |||
configuration. If the DF Algorithm is Highest-Preference or Lowest- | DF algorithm is Highest-Preference or Lowest-Preference, an attacker | |||
Preference, an attacker may change the configuration of the | may change the configuration of the preference value on a PE and | |||
Preference value on a PE and Ethernet Segment to impact the traffic | Ethernet Segment to impact the traffic going through that PE and | |||
going through that PE and Ethernet Segment. | Ethernet Segment. | |||
The non-revertive capability described in this document may be seen | 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 | |||
Forwarder Election: an intentional link (or node) "flapping" on a PE | election: an intentional link (or node) "flapping" on a PE will only | |||
will only cause service disruption once, when the PE goes to Non- | cause service disruption once, when the PE goes to Non-Designated | |||
Designated Forwarder state. However, an attacker who gets access to | Forwarder state. However, an attacker who gets access to the | |||
the configuration of a PE in the Ethernet Segment will be able to | configuration of a PE in the Ethernet Segment will be able to disable | |||
disable the non-revertive behavior, by advertising a conflicting DF | the non-revertive behavior, by advertising a conflicting DF election | |||
election algorithm and thereby forcing fallback to the Default | algorithm and thereby forcing fallback to the default DF algorithm. | |||
algorithm. | ||||
The document also describes how a local policy can override the | 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- | Ethernet Tag that ends up with an inconsistent use of Highest- | |||
Preference or Lowest-Preference in different PEs, packet drop or | Preference or Lowest-Preference in different PEs, packet drop or | |||
packet duplication may occur for that Ethernet Tag. | packet duplication may occur for that Ethernet Tag. | |||
Finally, the two Designated Forwarder Election Algorithms specified | Finally, the two DF election algorithms specified in this document | |||
in this document (Highest-Preference and Lowest-Preference) do not | (Highest-Preference and Lowest-Preference) do not change the way the | |||
change the way the PEs share their Ethernet Segment information, | PEs share their Ethernet Segment information, compared to the | |||
compared to the algorithms in [RFC7432] and [RFC8584]. Therefore, | algorithms in [RFC7432] and [RFC8584]. Therefore, the security | |||
the security considerations in [RFC7432] and [RFC8584] apply to this | considerations in [RFC7432] and [RFC8584] apply to this document as | |||
document as well. | well. | |||
6. IANA Considerations | 6. IANA Considerations | |||
Per this document, IANA has: | Per this document, IANA has: | |||
* Allocated two new values in the "DF Alg" registry created by | * Allocated two new values in the "DF Alg" registry created by | |||
[RFC8584], as follows: | [RFC8584], as follows: | |||
+=====+==============================+===========+ | +=====+==============================+===========+ | |||
| Alg | Name | Reference | | | Alg | Name | Reference | | |||
skipping to change at line 814 ¶ | skipping to change at line 821 ¶ | |||
| 0x06 | DF Election | [RFC8584] | | | 0x06 | DF Election | [RFC8584] | | |||
| | Extended Community | and RFC 9785 | | | | Extended Community | and RFC 9785 | | |||
+----------------+--------------------------------+--------------+ | +----------------+--------------------------------+--------------+ | |||
Table 3 | Table 3 | |||
7. References | 7. References | |||
7.1. Normative References | 7.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | ||||
Requirement Levels", BCP 14, RFC 2119, | ||||
DOI 10.17487/RFC2119, March 1997, | ||||
<https://www.rfc-editor.org/info/rfc2119>. | ||||
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., | [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., | |||
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based | Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based | |||
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February | Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February | |||
2015, <https://www.rfc-editor.org/info/rfc7432>. | 2015, <https://www.rfc-editor.org/info/rfc7432>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | ||||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | ||||
[RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake, | [RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake, | |||
J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet | J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet | |||
VPN Designated Forwarder Election Extensibility", | VPN Designated Forwarder Election Extensibility", | |||
RFC 8584, DOI 10.17487/RFC8584, April 2019, | RFC 8584, DOI 10.17487/RFC8584, April 2019, | |||
<https://www.rfc-editor.org/info/rfc8584>. | <https://www.rfc-editor.org/info/rfc8584>. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | ||||
Requirement Levels", BCP 14, RFC 2119, | ||||
DOI 10.17487/RFC2119, March 1997, | ||||
<https://www.rfc-editor.org/info/rfc2119>. | ||||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | ||||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | ||||
[RFC9784] Sajassi, A., Brissette, P., Schell, R., Drake, J., and J. | [RFC9784] Sajassi, A., Brissette, P., Schell, R., Drake, J., and J. | |||
Rabadan, "EVPN Virtual Ethernet Segment", RFC 9784, | Rabadan, "EVPN Virtual Ethernet Segment", RFC 9784, | |||
DOI 10.17487/9784, May 2025, | DOI 10.17487/9784, May 2025, | |||
<https://www.rfc-editor.org/info/rfc9784>. | <https://www.rfc-editor.org/info/rfc9784>. | |||
7.2. Informative References | 7.2. Informative References | |||
[RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. | ||||
Henderickx, "Provider Backbone Bridging Combined with | ||||
Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, | ||||
September 2015, <https://www.rfc-editor.org/info/rfc7623>. | ||||
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. | [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. | |||
Rabadan, "Virtual Private Wire Service Support in Ethernet | Rabadan, "Virtual Private Wire Service Support in Ethernet | |||
VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, | VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, | |||
<https://www.rfc-editor.org/info/rfc8214>. | <https://www.rfc-editor.org/info/rfc8214>. | |||
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., | [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., | |||
Uttaro, J., and W. Henderickx, "A Network Virtualization | Uttaro, J., and W. Henderickx, "A Network Virtualization | |||
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, | Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, | |||
DOI 10.17487/RFC8365, March 2018, | DOI 10.17487/RFC8365, March 2018, | |||
<https://www.rfc-editor.org/info/rfc8365>. | <https://www.rfc-editor.org/info/rfc8365>. | |||
[RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. | ||||
Henderickx, "Provider Backbone Bridging Combined with | ||||
Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, | ||||
September 2015, <https://www.rfc-editor.org/info/rfc7623>. | ||||
Acknowledgements | Acknowledgements | |||
The authors would like to thank Kishore Tiruveedhula and Sasha | The authors would like to thank Kishore Tiruveedhula and Sasha | |||
Vainshtein for their reviews and comments. Also, thank you to Luc | Vainshtein for their reviews and comments. Also, thank you to Luc | |||
André Burdet and Stephane Litkowski for their thorough reviews and | André Burdet and Stephane Litkowski for their thorough reviews and | |||
suggestions for a new Lowest-Preference DF Algorithm. | suggestions for a new Lowest-Preference Algorithm. | |||
Contributors | Contributors | |||
In addition to the authors listed, the following individuals also | In addition to the authors listed, the following individuals also | |||
contributed to this document: | contributed to this document: | |||
Tony Przygienda | Tony Przygienda | |||
Juniper | Juniper | |||
Satya Mohanty | Satya Mohanty | |||
End of changes. 78 change blocks. | ||||
250 lines changed or deleted | 257 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |