< draft-ietf-bess-evpn-pref-df-05.txt   draft-ietf-bess-evpn-pref-df-06.txt >
BESS Workgroup J. Rabadan, Ed. BESS Workgroup J. Rabadan, Ed.
Internet-Draft S. Sathappan Internet-Draft S. Sathappan
Intended status: Standards Track Nokia Intended status: Standards Track Nokia
Expires: June 19, 2020 T. Przygienda Expires: December 21, 2020 T. Przygienda
W. Lin W. Lin
J. Drake J. Drake
Juniper Networks Juniper Networks
A. Sajassi A. Sajassi
S. Mohanty S. Mohanty
Cisco Systems Cisco Systems
December 17, 2019 June 19, 2020
Preference-based EVPN DF Election Preference-based EVPN DF Election
draft-ietf-bess-evpn-pref-df-05 draft-ietf-bess-evpn-pref-df-06
Abstract Abstract
The Designated Forwarder (DF) in Ethernet Virtual Private Networks The Designated Forwarder (DF) in Ethernet Virtual Private Networks
(EVPN) is defined as the PE responsible for sending Broadcast, (EVPN) is defined as the PE responsible for sending Broadcast,
Unknown unicast and Broadcast traffic (BUM) to a multi-homed device/ Unknown unicast and Broadcast traffic (BUM) to a multi-homed device/
network in the case of an all-active multi-homing Ethernet Segment network in the case of an all-active multi-homing Ethernet Segment
(ES), or BUM and unicast in the case of single-active multi-homing. (ES), or BUM and unicast in the case of single-active multi-homing.
The DF is selected out of a candidate list of PEs that advertise the The DF is selected out of a candidate list of PEs that advertise the
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 19, 2020. This Internet-Draft will expire on December 21, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Solution requirements . . . . . . . . . . . . . . . . . . 3 1.2. Solution requirements . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Requirements Language and Terminology . . . . . . . . . . . . 4
3. EVPN BGP Attributes Extensions . . . . . . . . . . . . . . . 5 3. EVPN BGP Attributes Extensions . . . . . . . . . . . . . . . 5
4. Solution description . . . . . . . . . . . . . . . . . . . . 6 4. Solution description . . . . . . . . . . . . . . . . . . . . 6
4.1. Use of the Preference algorithm . . . . . . . . . . . . . 7 4.1. Use of the Preference algorithm . . . . . . . . . . . . . 7
4.2. Use of the Preference algorithm in [RFC7432] Ethernet 4.2. Use of the Preference algorithm in [RFC7432] Ethernet
Segments . . . . . . . . . . . . . . . . . . . . . . . . 9 Segments . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. The Non-Revertive Capability . . . . . . . . . . . . . . 10 4.3. The Non-Revertive Capability . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
1.1. Problem Statement 1.1. Problem Statement
[RFC7432] defines the Designated Forwarder (DF) in (PBB-)EVPN [RFC7432] defines the Designated Forwarder (DF) in (PBB-)EVPN
networks as the PE responsible for sending broadcast, multicast and networks as the PE responsible for sending broadcast, multicast and
unknown unicast traffic (BUM) to a multi-homed device/network in the unknown unicast traffic (BUM) to a multi-homed device/network in the
case of an all-active multi-homing ES or BUM and unicast traffic to a case of an all-active multi-homing ES or BUM and unicast traffic to a
multi-homed device or network in case of single-active multi-homing. multi-homed device or network in case of single-active multi-homing.
skipping to change at page 4, line 5 skipping to change at page 4, line 5
Ethernet Tag without re-configuring all the PEs in the ES. Ethernet Tag without re-configuring all the PEs in the ES.
d. The solution allows an option to NOT preempt the current DF, even d. The solution allows an option to NOT preempt the current DF, even
if the former DF PE comes back up after a failure. This is also if the former DF PE comes back up after a failure. This is also
known as "non-revertive" behavior, as opposed to the [RFC7432] DF known as "non-revertive" behavior, as opposed to the [RFC7432] DF
election procedures that are always revertive. election procedures that are always revertive.
e. The solution works for single-active and all-active multi-homing e. The solution works for single-active and all-active multi-homing
Ethernet Segments. Ethernet Segments.
2. Conventions and Terminology 2. Requirements Language and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
o AC - Attachment Circuit. An AC has an Ethernet Tag associated to o AC - Attachment Circuit. An AC has an Ethernet Tag associated to
it. it.
o BUM - refers to the Broadcast, Unknown unicast and Multicast o BUM - refers to the Broadcast, Unknown unicast and Multicast
traffic. traffic.
o DF, NDF and BDF - Designated Forwarder, Non-Designated Forwarder o DF, NDF and BDF - Designated Forwarder, Non-Designated Forwarder
and Backup Designated Forwarder. and Backup Designated Forwarder.
o DF Alg - refers to Designated Forwarder Election Algorithm. o DF Alg or simply Alg - refers to Designated Forwarder Election
Algorithm.
o HRW - Highest Random Weight, as per [RFC8584]. o HRW - Highest Random Weight, as per [RFC8584].
o ES, vES and ESI - Ethernet Segment, virtual Ethernet Segment and o ES, vES and ESI - Ethernet Segment, virtual Ethernet Segment and
Ethernet Segment Identifier. Ethernet Segment Identifier.
o EVI - EVPN Instance. o EVI - EVPN Instance.
o ISID - refers to Service Instance Identifiers in Provider Backbone o ISID - refers to Service Instance Identifiers in Provider Backbone
Bridging (PBB) networks. Bridging (PBB) networks.
skipping to change at page 6, line 28 skipping to change at page 6, line 28
and DF Alg 2. and DF Alg 2.
o DF Preference (defined in this document): defines a 2-octet value o DF Preference (defined in this document): defines a 2-octet value
that indicates the PE preference to become the DF in the ES. The that indicates the PE preference to become the DF in the ES. The
allowed values are within the range 0-65535, and the default value allowed values are within the range 0-65535, and the default value
MUST be 32767. This value is the midpoint in the allowed MUST be 32767. This value is the midpoint in the allowed
Preference range of values, which gives the operator the Preference range of values, which gives the operator the
flexibility of choosing a significant number of values, above or flexibility of choosing a significant number of values, above or
below the default Preference. The DF Preference field is specific below the default Preference. The DF Preference field is specific
to DF Alg 2 and does not represent any Preference value for other to DF Alg 2 and does not represent any Preference value for other
Algs. Algs. If the DF Alg is different than Alg 2, these two octets can
be encoded differently.
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
+-------------------+ +-------------------+
| +-------+ ENNI Aggregation | +-------+ ENNI Aggregation
| <---ESI1,500 | PE1 | /\ +----Network---+ | <---ESI1,500 | PE1 | /\ +----Network---+
skipping to change at page 7, line 47 skipping to change at page 7, line 47
4.1. Use of the Preference algorithm 4.1. Use of the Preference algorithm
Assuming the operator wants to control - in a flexible way - what PE Assuming the operator wants to control - in a flexible way - what PE
becomes the DF for a given vES and the order in which the PEs become becomes the DF for a given vES and the order in which the PEs become
DF in case of multiple failures, the following procedure may be used: DF in case of multiple failures, the following procedure may be used:
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 option (or "Don't parameters are the Preference, Preemption option (or "Don't
Preempt Me" option) and DF Alg. We will represent these Preempt Me" option) and DF Alg. We will represent these
parameters as [Pref,DP,Alg]. Let's assume vES1 is configured as parameters as (Pref,DP,Alg). Let's assume vES1 is configured as
[500,0,Pref] in PE1, and [255,0,Pref] in PE2. vES2 is configured (500,0,Pref) in PE1, and (255,0,Pref) in PE2. vES2 is configured
as [100,0,Pref], [200,0,Pref] and [300,0,Pref] in PE1, PE2 and as (100,0,Pref), (200,0,Pref) and (300,0,Pref) in PE1, PE2 and
PE3 respectively. PE3 respectively.
b. The PEs will advertise an ES route for each vES, including the 3 b. The PEs will advertise an ES route for each vES, including the 3
parameters in the DF Election Extended Community. parameters in the DF Election Extended Community.
c. According to [RFC8584], each PE will run the DF election c. According to [RFC8584], each PE will run the DF election
algorithm upon expiration of the DF Wait timer. In this case, algorithm upon expiration of the DF Wait timer. In this case,
each PE runs the Preference-based DF Alg for each ES as follows: each PE runs the Preference-based DF Alg for each ES as follows:
- The PE will check the DF Alg value in each ES route, and - The PE will check the DF Alg value in each ES route, and
assuming all the ES routes are consistent in this DF Alg and assuming all the ES routes are consistent in this DF Alg and
the value is 2 (Preference-based), the PE will run the new the value is 2 (Preference-based), the PE will run the
extended procedure. Otherwise, the procedure will fall back procedure in this section. Otherwise, the procedure will fall
to [RFC7432] Default Alg. back to [RFC7432] Default Alg.
- In this Preference-based Alg, each PE builds a list of - In this Preference-based Alg, each PE builds a list of
candidate PEs, ordered by Preference. E.g. PE1 will build a candidate PEs, ordered by Preference. E.g. PE1 will build 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. Hence PE1 will become the DF for vES1. high to low: PE1>PE2. Hence PE1 will become the DF for vES1.
In the same way, PE3 becomes the DF for vES2. In the same way, PE3 becomes the DF for vES2.
d. Note that, by default, the Highest-Preference is chosen for each d. Note that, by default, the Highest-Preference is chosen for each
ES or vES, however the ES configuration can be changed to the ES or vES, however the ES configuration can be changed to the
Lowest-Preference algorithm as long as this option is consistent Lowest-Preference algorithm as long as this option is consistent
skipping to change at page 8, line 38 skipping to change at page 8, line 38
configured as Alg Preference-based with Lowest-Preference, in configured as Alg Preference-based with Lowest-Preference, in
which case, PE2 would have been the DF. which case, PE2 would have been the DF.
e. Assuming some maintenance tasks had to be executed on PE3, the e. Assuming some maintenance tasks had to be executed on PE3, the
operator could set vES2's Preference to e.g., 50 so that PE2 is operator could set vES2's Preference to e.g., 50 so that PE2 is
forced to take over as DF for vES2 (irrespective of the DP forced to take over as DF for vES2 (irrespective of the DP
capability). Once the maintenance on PE3 is over, the operator capability). Once the maintenance on PE3 is over, the operator
could decide to leave the existing preference or configure the could decide to leave the existing preference or configure the
old preference back. old preference back.
f. In case of equal Preference in two or more PEs in the ES, the f. In case of equal Preference in two or more PEs in the ES, the DP
tie-breakers will be the DP bit and the lowest IP PE, in that bit and the lowest IP of the candidate PEs are used as tie-
order. For instance: breakers. After selecting the PEs with the highest Preference
value, an implementation MUST first select the PE advertising the
DP bit set, and then select the PE with the lowest IP address (if
the DP bit 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 ES
route. Some examples of the use of the DP bit and IP address
tie-breakers follow:
- If vES1 parameters were [500,0,Pref] in PE1 and [500,1,Pref] - If vES1 parameters were (500,0,Pref) in PE1 and (500,1,Pref)
in PE2, PE2 would be elected due to the DP bit. in PE2, PE2 would be elected due to the DP bit.
- If vES1 parameters were [500,0,Pref] in PE1 and [500,0,Pref] - If vES1 parameters were (500,0,Pref) in PE1 and (500,0,Pref)
in PE2, PE1 would be elected, assuming PE1's IP address is in PE2, PE1 would be elected, assuming PE1's IP address is
lower than PE2's. lower than PE2's.
g. The Preference is an administrative option that MUST be g. The Preference is an administrative option that MUST be
configured on a per-ES basis from the management plane, but MAY configured on a per-ES basis from the management plane, but MAY
also be dynamically changed based on the use of local policies. also be dynamically changed based on the use of local policies.
For instance, on PE1, ES1's Preference can be lowered from 500 to For instance, on PE1, ES1's Preference can be lowered from 500 to
100 in case the bandwidth on the ENNI port is decreased a 50% 100 in case the bandwidth on the ENNI port is decreased a 50%
(that could happen if e.g. the 2-port LAG between PE1 and the (that could happen if e.g. the 2-port LAG between PE1 and the
Aggregation Network loses one port). Policies MAY also trigger Aggregation Network loses one port). Policies MAY also trigger
skipping to change at page 9, line 44 skipping to change at page 10, line 6
administrative Preference value, but then a range of Ethernet Tags administrative Preference value, but then a range of Ethernet Tags
can be defined to use the Highest-Preference or the Lowest-Preference can be defined to use the Highest-Preference or the Lowest-Preference
depending on the desired behavior. With this option, the PE will depending on the desired behavior. With this option, the PE will
build a list of candidate PEs ordered by Preference, however the DF build a list of candidate PEs ordered by Preference, however the DF
for a given Ethernet Tag will be determined by the local for a given Ethernet Tag will be determined by the local
configuration. configuration.
For instance: For instance:
o Assuming ES3 is defined in PE1 and PE2, PE1 may be configured as o Assuming ES3 is defined in PE1 and PE2, PE1 may be configured as
[500,0,Preference] for ES3 and PE2 as [100,0,Preference]. (500,0,Preference) for ES3 and PE2 as (100,0,Preference).
o In addition, assuming VLAN-based service interfaces, the PEs will o In addition, assuming VLAN-based service interfaces, the PEs will
be configured with (Ethernet Tag-range,high_or_low), E.g., be configured with (Ethernet Tag-range,high_or_low), E.g.,
(1-2000,high) and (2001-4000, low). (1-2000,high) and (2001-4000, low).
o This will result in PE1 being DF for Ethernet Tags 1-2000 and PE2 o This will result in PE1 being DF for Ethernet Tags 1-2000 and PE2
being DF for Ethernet Tags 2001-4000. being DF for Ethernet Tags 2001-4000.
For Ethernet Segments attached to three or more PEs, any other logic For Ethernet Segments attached to three or more PEs, any other logic
that provides a fair distribution of the DF function among the PEs is that provides a fair distribution of the DF function among the PEs is
skipping to change at page 10, line 34 skipping to change at page 10, line 44
In Figure 3, we assume that based on the Highest-Pref, PE3 is the DF In Figure 3, we assume that based on the Highest-Pref, PE3 is the DF
for ESI2. for ESI2.
If PE3 has a link, EVC or node failure, PE2 would take over as DF. If PE3 has a link, EVC or node failure, PE2 would take over as DF.
If/when PE3 comes back up again, PE3 will take over, causing some If/when PE3 comes back up again, PE3 will take over, causing some
unnecessary packet loss in the ES. unnecessary packet loss in the ES.
The following procedure avoids preemption upon failure recovery The following procedure avoids preemption upon failure recovery
(please refer to Figure 1): (please refer to Figure 1):
1. A new "Don't Preempt Me" capability is defined on a per-PE per-ES 1. A new "Don't Preempt Me" capability is defined on a per-PE/per-ES
basis, as described in Section 3. If "Don't Preempt Me" is basis, as described in Section 3. If "Don't Preempt Me" is
disabled (default behavior), the advertised DP bit will be 0. If disabled (default behavior), the advertised DP bit will be 0. If
"Don't Preempt Me" is enabled, the ES route will be advertised "Don't Preempt Me" is enabled, the ES route will be advertised
with DP=1 ("Don't Preempt Me"). All the PEs in an ES SHOULD be with DP=1 ("Don't Preempt Me"). All the PEs in an ES SHOULD be
consistent in their configuration of the DP capability, however consistent in their configuration of the DP capability, however
this document do not enforces the consistency across all the PEs. this document do not enforce the consistency across all the PEs.
In case of inconsistency in the support of the DP capability in
the PEs of the same ES, non-revertive behavior is not guaranteed.
2. Assuming we want to avoid 'preemption' in all the PEs in the ES, 2. Assuming we want to avoid 'preemption' in all the PEs in the ES,
the three PEs are configured with the "Don't Preempt Me" the three PEs are configured with the "Don't Preempt Me"
capability. In this example, we assume ESI2 is configured as capability. In this example, we assume ESI2 is configured as
'DP=enabled' in the three PEs. 'DP=enabled' in the three PEs.
3. Assuming Ethernet Tag-1 uses Highest-Pref in vES2 and Ethernet 3. Assuming Ethernet Tag-1 uses Highest-Pref in vES2 and Ethernet
Tag-2 uses Lowest-Pref, when vES2 is enabled in the three PEs, Tag-2 uses Lowest-Pref, when vES2 is enabled in the three PEs,
the PEs will exchange the ES routes and select PE3 as DF for the PEs will exchange the ES routes and select PE3 as DF for
Ethernet Tag-1 (due to the Highest-Pref type), and PE1 as DF for Ethernet Tag-1 (due to the Highest-Pref type), and PE1 as DF for
Ethernet Tag-2 (due to the Lowest-Pref). Ethernet Tag-2 (due to the Lowest-Pref).
4. If PE3's vES2 goes down (due to EVC failure - detected by OAM, or 4. If PE3's vES2 goes down (due to EVC failure - detected by OAM, or
port failure or node failure), PE2 will become the DF for port failure or node failure), PE2 will become the DF for
Ethernet Tag-1. No changes will occur for Ethernet Tag-2. Ethernet Tag-1. No changes 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 ES routes from timer will allow some time for PE3 to receive the ES routes from
PE1 and PE2. PE3 will then: PE1 and PE2. This timer is applied between the INIT and the
DF_WAIT states in the DF Election Finite State Machine described
in [RFC8584]. PE3 will then:
- Select two "reference-PEs" among the ES routes in the vES, the - Select two "reference-PEs" among the ES routes in the vES, the
"Highest-PE" and the "Lowest-PE": "Highest-PE" and the "Lowest-PE":
* 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 DP bit first (with DP=1 being better) and, after that, the
lower PE-IP address as tie-breakers. PE3 will select PE2 lower PE-IP address as tie-breakers. PE3 will select PE2
as Highest-PE over PE1, since, when comparing [Pref,DP,PE- as Highest-PE over PE1, since, when comparing (Pref,DP,PE-
IP], [200,1,PE2-IP] wins over [100,1,PE1-IP]. IP), (200,1,PE2-IP) wins over (100,1,PE1-IP).
* The Lowest-PE is the PE with lower Preference, using the DP * The Lowest-PE is the PE with lower Preference, using the DP
bit first (with DP=1 being better) and, after that, the bit first (with DP=1 being better) and, after that, the
lower PE-IP address as tie-breakers. PE3 will select PE1 lower PE-IP address as tie-breakers. PE3 will select PE1
as Lowest-PE over PE2, since [100,1,PE1-IP] wins over as Lowest-PE over PE2, since (100,1,PE1-IP) wins over
[200,1,PE2-IP]. (200,1,PE2-IP).
* Note that if there were only one remote PE in the ES, * Note that if there were only one remote PE in the ES,
Lowest and Highest PE would be the same PE. Lowest and Highest PE would be the same PE.
- Check its own administrative Pref and compares it with the one - Check its own administrative Pref and compares it with the one
of the Highest-PE and Lowest-PE that have DP=1 in their ES of the Highest-PE and Lowest-PE that have DP=1 in their ES
routes. Depending on this comparison PE3 will send the ES routes. Depending on this comparison PE3 will send the ES
route with a [Pref,DP] that may be different from its route with a (Pref,DP) that may be different from its
administrative [Pref,DP]: administrative (Pref,DP):
* If PE3's Pref value is higher than the Highest-PE's, PE3 * If PE3's Pref value is higher than the Highest-PE's, PE3
will send the ES route with an 'in-use' operational Pref will send the ES route with an 'in-use' operational Pref
equal to the Highest-PE's and DP=0. equal to the Highest-PE's and DP=0.
* If PE3's Pref value is lower than the Lowest-PE's, PE3 will * If PE3's Pref value is lower than the Lowest-PE's, PE3 will
send the ES route with an 'in-use' operational Preference send the ES route with an 'in-use' operational Preference
equal to the Lowest-PE's and DP=0. equal to the Lowest-PE's and DP=0.
* If PE3's Pref value is neither higher nor lower than the * If PE3's Pref value is neither higher nor lower than the
Highest-PE's or the Lowest-PE's respectively, PE3 will send Highest-PE's or the Lowest-PE's respectively, PE3 will send
the ES route with its administrative [Pref,DP]=[300,1]. the ES route with its 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 ES Hence PE3 will inherit PE2's preference and send the ES
route with an operational 'in-use' [Pref,DP]=[200,0]. route with an operational 'in-use' (Pref,DP)=(200,0).
- Note that, a PE will always send DP=0 as long as the - Note that, a PE will always send DP=0 as long as the
advertised Pref is the 'in-use' operational Pref (as opposed advertised Pref is the 'in-use' operational Pref (as opposed
to the 'administrative' Pref). to the 'administrative' Pref).
- This ES route update sent by PE3 (with [200,0,PE3-IP]) will - This ES route update sent by PE3, with (200,0,PE3-IP), will
not cause any DF switchover for any Ethernet Tag. PE2 will not cause any DF switchover for any Ethernet Tag. PE2 will
continue being DF for Ethernet Tag-1. This is because the DP continue being DF for Ethernet Tag-1. This is because the DP
bit will be used as a tie-breaker in the DF election. That bit will be used as a tie-breaker in the DF election. That
is, if a PE has two candidate PEs with the same Pref, it will is, if a PE has two candidate PEs with the same Pref, it will
pick up the one with DP=1. There are no DF changes for pick up the one with DP=1. There are no DF changes for
Ethernet Tag-2 either. Ethernet Tag-2 either.
6. Subsequently, if PE2 fails, upon receiving PE2's ES route 6. For any subsequent update/withdraw in the ES, the PEs will go
withdrawal, PE3 and PE1 will go through the process described in through the process described in (5) to select Highest and
(5) to select new Highest and Lowest-PEs (considering their own Lowest-PEs. For instance, if PE2 fails, upon receiving PE2's ES
active ES route) and then they will run the DF Election. route withdrawal, PE3 and PE1 will go through the selection of
new Highest and Lowest-PEs (considering their own active ES
route) and then they will run the DF Election.
- If a PE selects itself as new Highest or Lowest-PE and it was - If a PE selects itself as new Highest or Lowest-PE and it was
not before, the PE will then compare its operational 'in-use' not before, the PE will then compare its operational 'in-use'
Pref with its administrative Pref. If different, the PE will Pref with its administrative Pref. If different, the PE will
send an ES route update with its administrative Pref and DP send an ES route update with its administrative Pref and DP
values. In the example, PE3 will be the new Highest-PE, values. In the example, PE3 will be the new Highest-PE,
therefore it will send an ES route update with therefore it will send an ES route update with
[Pref,DP]=[300,1]. (Pref,DP)=(300,1).
- After running the DF Election, PE3 will become the new DF for - After running the DF Election, PE3 will become the new DF for
Ethernet Tag-1. No changes will occur for Ethernet Tag-2. Ethernet Tag-1. No changes will occur for Ethernet Tag-2.
Note that, irrespective of the DP bit, when a PE or ES comes back and Note that, irrespective of the DP bit, when a PE or ES comes back and
the PE advertises a DF Election Alg different than 2 (Preference the PE advertises a DF Election Alg different than 2 (Preference
algorithm), the rest of the PEs in the ES MUST fall back to the algorithm), the rest of the PEs in the ES MUST fall back to the
Default [RFC7432] Alg. Default [RFC7432] Alg.
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
skipping to change at page 13, line 35 skipping to change at page 14, line 4
and comments. and comments.
8. Contributors 8. 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:
Kiran Nagaraj, Nokia Kiran Nagaraj, Nokia
Vinod Prabhu, Nokia Vinod Prabhu, Nokia
Selvakumar Sivaraj, Juniper Selvakumar Sivaraj, Juniper
Sami Boutros, VMWare Sami Boutros, VMWare
9. References 9. References
9.1. Normative References 9.1. Normative References
[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>.
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
Rabadan, "Virtual Private Wire Service Support in Ethernet
VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
<https://www.rfc-editor.org/info/rfc8214>.
[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>.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>.
[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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References
[I-D.ietf-bess-evpn-virtual-eth-segment] [I-D.ietf-bess-evpn-virtual-eth-segment]
Sajassi, A., Brissette, P., Schell, R., Drake, J., and J. Sajassi, A., Brissette, P., Schell, R., Drake, J., and J.
Rabadan, "EVPN Virtual Ethernet Segment", draft-ietf-bess- Rabadan, "EVPN Virtual Ethernet Segment", draft-ietf-bess-
evpn-virtual-eth-segment-04 (work in progress), January evpn-virtual-eth-segment-06 (work in progress), March
2019. 2020.
9.2. Informative References
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
Rabadan, "Virtual Private Wire Service Support in Ethernet
VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
<https://www.rfc-editor.org/info/rfc8214>.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018,
<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>.
Authors' Addresses Authors' Addresses
J. Rabadan (editor) J. Rabadan (editor)
Nokia Nokia
777 Middlefield Road 777 Middlefield Road
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Email: jorge.rabadan@nokia.com Email: jorge.rabadan@nokia.com
 End of changes. 34 change blocks. 
64 lines changed or deleted 77 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/