< draft-ietf-bess-evpn-pref-df-02.txt   draft-ietf-bess-evpn-pref-df-03.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
S. Boutros T. Przygienda S. Boutros T. Przygienda
Individual W. Lin VMWare W. Lin
J. Drake J. Drake
Juniper Networks Juniper Networks
A. Sajassi A. Sajassi
S. Mohanty S. Mohanty
Cisco Systems Cisco Systems
Expires: April 25, 2019 October 22, 2018 Expires: June 24, 2019 December 21, 2018
Preference-based EVPN DF Election Preference-based EVPN DF Election
draft-ietf-bess-evpn-pref-df-02 draft-ietf-bess-evpn-pref-df-03
Abstract Abstract
The Designated Forwarder (DF) in (PBB-)EVPN networks is defined as The Designated Forwarder (DF) in Ethernet Virtual Private Networks
the PE responsible for sending broadcast, multicast and unknown (EVPN) is defined as the PE responsible for sending Broadcast,
unicast traffic (BUM) to a multi-homed device/network in the case of Unknown unicast and Broadcast traffic (BUM) to a multi-homed
an all-active multi-homing ES, or BUM and unicast in the case of device/network in the case of an all-active multi-homing Ethernet
single-active multi-homing. Segment (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
Ethernet Segment Identifier (ESI) to the EVPN network, according to same Ethernet Segment Identifier (ESI) to the EVPN network, according
the Default DF Election algorithm. to the Default DF Election algorithm.
While the Default Algorithm provides an efficient and automated way While the Default Algorithm provides an efficient and automated way
of selecting the DF across different EVIs or ISIDs in the ES, there of selecting the DF across different Ethernet Tags in the ES, there
are some use-cases where a more 'deterministic' and user-controlled are some use-cases where a more 'deterministic' and user-controlled
method is required. At the same time, Service Providers require an method is required. At the same time, Service Providers require an
easy way to force an on-demand DF switchover in order to carry out easy way to force an on-demand DF switchover in order to carry out
some maintenance tasks on the existing DF or control whether a new some maintenance tasks on the existing DF or control whether a new
active PE can preempt the existing DF PE. active PE can preempt the existing DF PE.
This document proposes an extension to the Default DF election This document proposes an extension to the Default DF election
procedures so that the above requirements can be met. procedures so that the above requirements can be met.
Status of this Memo Status of this Memo
skipping to change at page 1, line 45 skipping to change at page 2, line 4
are some use-cases where a more 'deterministic' and user-controlled are some use-cases where a more 'deterministic' and user-controlled
method is required. At the same time, Service Providers require an method is required. At the same time, Service Providers require an
easy way to force an on-demand DF switchover in order to carry out easy way to force an on-demand DF switchover in order to carry out
some maintenance tasks on the existing DF or control whether a new some maintenance tasks on the existing DF or control whether a new
active PE can preempt the existing DF PE. active PE can preempt the existing DF PE.
This document proposes an extension to the Default DF election This document proposes an extension to the Default DF election
procedures so that the above requirements can be met. procedures so that the above requirements can be met.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 25, 2018. This Internet-Draft will expire on June 24, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Solution requirements . . . . . . . . . . . . . . . . . . . . . 3 1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . 3
3. EVPN BGP Attributes for Deterministic DF Election . . . . . . . 4 1.2 Solution requirements . . . . . . . . . . . . . . . . . . . 3
4. Solution description . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions and Terminology . . . . . . . . . . . . . . . . . . 4
4.1 Use of the Preference algorithm . . . . . . . . . . . . . . 6 3. EVPN BGP Attributes Extensions . . . . . . . . . . . . . . . . 5
4.2 Use of the Preference algorithm in [RFC7432] 4. Solution description . . . . . . . . . . . . . . . . . . . . . 6
Ethernet-Segments . . . . . . . . . . . . . . . . . . . . . 7 4.1 Use of the Preference algorithm . . . . . . . . . . . . . . 7
4.3 The Non-Revertive option . . . . . . . . . . . . . . . . . . 8 4.2 Use of the Preference algorithm in [RFC7432] Ethernet
5. Conventions used in this document . . . . . . . . . . . . . . . 11 Segments . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 11 4.3 The Non-Revertive Capability . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.2 Informative References . . . . . . . . . . . . . . . . . . . 11 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2 Informative References . . . . . . . . . . . . . . . . . . . 14
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 14
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
1. Problem Statement 1. Introduction
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.
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
Ethernet Segment Identifier (ESI) to the EVPN network and according Ethernet Segment Identifier (ESI) to the EVPN network and according
to the Alg [DF]. to the DF Election Algorithm, or DF Alg as per [DF].
While the Default DF Election Algorithm provides an efficient and While the Default DF Alg [RFC7432] or HRW [DF] provide an efficient
automated way of selecting the DF across different EVIs or ISIDs in and automated way of selecting the DF across different Ethernet Tags
the ES, there are some use-cases where a more 'deterministic' and in the ES, there are some use-cases where a more 'deterministic' and
user-controlled method is required. At the same time, Service user-controlled method is required. At the same time, Service
Providers require an easy way to force an on-demand DF switchover in Providers require an easy way to force an on-demand DF switchover in
order to carry out some maintenance tasks on the existing DF or order to carry out some maintenance tasks on the existing DF or
control whether a new active PE can preempt the existing DF PE. control whether a new active PE can preempt the existing DF PE.
This document proposes an extension to the current Default DF This document proposes a new DF Alg and capability to address the
election procedures [RFC7432] so that the above requirements can be above needs.
met.
2. Solution requirements 1.2 Solution requirements
This document proposes an extension of the [RFC7432] Default DF The procedures described in this document meet the following
election Algorithm motivated by 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
DF, assuming they are all operationally ready to take over. DF, assuming they are all operationally ready to take over as DF.
b) This extension works for [RFC7432] Ethernet Segments (ES) and b) This extension works for [RFC7432] Ethernet Segments (ES) and
virtual ES, as defined in [vES]. virtual ES, as defined in [vES].
c) The user may force a PE to preempt the existing DF for a given c) The user may force a PE to preempt the existing DF for a given
EVI/ISID 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.
3. EVPN BGP Attributes for Deterministic DF Election 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
o AC - Attachment Circuit. An AC has an Ethernet Tag associated to
it.
o BUM - refers to the Broadcast, Unknown unicast and Multicast
traffic.
o DF, NDF and BDF - Designated Forwarder, Non-Designated Forwarder
and Backup Designated Forwarder.
o DF Alg - refers to Designated Forwarder Election Algorithm.
o HRW - Highest Random Weight, as per [DF].
o ES, vES and ESI - Ethernet Segment, virtual Ethernet Segment and
Ethernet Segment Identifier.
o EVI - EVPN Instance.
o ISID - refers to Service Instance Identifiers in Provider Backbone
Bridging (PBB) networks.
o MAC-VRF - A Virtual Routing and Forwarding table for Media Access
Control (MAC) addresses on a PE.
o BD - Broadcast Domain. An EVI may be comprised of one (VLAN-Based
or VLAN Bundle services) or multiple (VLAN-Aware Bundle services)
Broadcast Domains.
o EVC - Ethernet Virtual Circuit.
o DP - refers to the "Don't Preempt me" capability in the DF Election
extended community.
o OAM - refers to Operations And Maintenance protocols.
o Ethernet A-D per ES route - refers to [RFC7432] route type 1 or
Auto-Discovery per Ethernet Segment route.
o Ethernet A-D per EVI route - refers to [RFC7432] route type 1 or
Auto-Discovery per EVPN Instance route.
o Ethernet Tag - used to represent a Broadcast Domain that is
configured on a given ES for the purpose of DF election. Note that
any of the following may be used to represent a Broadcast Domain:
VIDs (including Q-in-Q tags), configured IDs, VNI (VXLAN Network
Identifiers), normalized VID, I-SIDs (Service Instance
Identifiers), etc., as long as the representation of the broadcast
domains is configured consistently across the multi-homed PEs
attached to that ES. The Ethernet Tag value MUST be different from
zero.
3. EVPN BGP Attributes Extensions
This solution reuses and extends the DF Election Extended Community This solution reuses and extends the DF Election Extended Community
defined in [DF] that is advertised along with the ES route: defined in [DF] that is advertised along with the ES route:
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)| 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 following fields are defined as follows: Where the following fields are defined as follows:
o DF Alg can have the following values: o DF Alg can have the following values:
- Alg 0 - Default, modulo based DF election as per [RFC7432]. - Alg 0 - Default DF Election algorithm, or modulus-based algorithm
- Alg 1 - HRW algorithm as per [DF] as per [RFC7432].
- Alg 2 - Preference algorithm (this document)
o Bitmap can have the following values: - Alg 1 - HRW algorithm as per [DF].
- Alg 2 - Preference algorithm (this document).
o Bitmap (2 octets) can have the following values:
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) - D bit or 'Don't Preempt' bit (DP hereafter), Community and it is defined by this document): D bit or 'Don't
determines if the PE advertising the ES route requests the remote Preempt' bit (DP hereafter), determines if the PE advertising the
PEs in the ES not to preempt it as DF. The default value is DP=0, ES route requests the remote PEs in the ES not to preempt it as
which is compatible with the 'preempt' or 'revertive' behavior in DF. The default value is DP=0, which is compatible with the
the Default Alg [RFC7432]. The DP bit SHOULD be ignored if the DF 'preempt' or 'revertive' behavior in the Default DF Alg
Alg is different than 2. [RFC7432]. The DP bit SHOULD be ignored if the DF Alg is
different than 2.
- Bit 1 - AC-DF or AC-Influenced DF Election, explained in [DF]. - Bit 1: AC-DF or AC-Influenced DF Election, as explained in [DF].
The AC-DF capability bit MAY be set along with the DP capability When set to 1, it indicates the desire to use AC-Influenced DF
and Alg 2. Election with the rest of the PEs in the ES. The AC-DF capability
bit MAY be set along with the DP capability and DF Alg 2.
o DF Preference defines a 2-octet value that indicates the PE o DF Preference (defined in this document): defines a 2-octet value
preference to become the DF in the ES. The allowed values are that indicates the PE preference to become the DF in the ES. The
within the range 0-65535, and default value MUST be 32767. This allowed values are within the range 0-65535, and the default value
value is the midpoint in the allowed Preference range of values, MUST be 32767. This value is the midpoint in the allowed Preference
which gives the operator the flexibility of choosing a significant range of values, which gives the operator the flexibility of
number of values, above or below the default Preference. The DF choosing a significant number of values, above or below the default
Preference field is specific to DF Alg 2 and does not represent any Preference. The DF Preference field is specific to DF Alg 2 and
Preference value for other Algs. does not represent any Preference value for other Algs.
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 6, line 13 skipping to change at page 7, line 34
Figure 3 - ES and Deterministic DF Election Figure 3 - ES and Deterministic DF Election
Figure 1 shows three PEs that are connecting EVCs coming from the Figure 1 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 - that spans PE1 and PE2 - and CE2 is connected to connected to vES1 - that spans PE1 and PE2 - and CE2 is connected to
vES2, that is defined in PE1, PE2 and PE3. vES2, that is defined in PE1, PE2 and PE3.
If the algorithm chosen for vES1 and vES2 is Alg 2, i.e. Preference- If the algorithm chosen for vES1 and vES2 is Alg 2, i.e. Preference-
based, the PEs may become DF irrespective of their IP address and based, the PEs may become DF irrespective of their IP address and
based on an administrative Preference value. The following sections based on an administrative Preference value. The following sections
provide some examples of the new defined procedures and how they are provide some examples of the procedures and how they are applied in
applied in the use-case in Figure 1. the use-case in Figure 1.
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 parameters Preempt Me" option) and DF Alg. We will represent these parameters
as [Pref,DP,Alg]. Let's assume vES1 is configured as [500,0,Pref] 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 as 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 PE3 [100,0,Pref], [200,0,Pref] and [300,0,Pref] in PE1, PE2 and PE3
respectively. 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 [RFC7432], each PE will wait for the DF timer to c) According to [RFC7432], each PE will run the DF election algorithm
expire before running the DF election algorithm. After the timer upon expiration of the DF Wait timer. In this case, each PE runs
expires, each PE runs the Preference-based DF election algorithm the Preference-based DF Alg for each ES as follows:
as follows:
o The PE will check the DF Alg in each ES route, and assuming all o The PE will check the DF Alg value in each ES route, and
the ES routes are consistent in this DF Alg and the value is 2 assuming all the ES routes are consistent in this DF Alg and the
(Preference-based), the PE will run the new extended procedure. value is 2 (Preference-based), the PE will run the new extended
Otherwise, the procedure will fall back to [RFC7432] Default procedure. Otherwise, the procedure will fall back to [RFC7432]
Alg. Default Alg.
o In this extended procedure, each PE builds a list of candidate o In this Preference-based Alg, each PE builds a list of candidate
PEs, ordered based on the Preference. E.g. PE1 will build a list PEs, ordered by Preference. E.g. PE1 will build a list of
of candidate PEs for vES1 ordered by the Preference, from high candidate PEs for vES1 ordered by the Preference, from high to
to low: PE1>PE2. Hence PE1 will become the DF for vES1. In the low: PE1>PE2. Hence PE1 will become the DF for vES1. In the same
same way, PE3 becomes the DF for vES2. 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
in all the PEs in the ES. E.g. vES1 could have been explicitly in all the PEs in the ES. E.g. vES1 could have been explicitly
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. Once the maintenance on PE3 is forced to take over as DF for vES2 (irrespective of the DP
over, the operator could decide to leave the existing preference capability). Once the maintenance on PE3 is over, the operator
or configure the old preference back. could decide to leave the existing preference or configure the old
preference back.
f) In case of equal Preference in two or more PEs in the ES, the tie- f) In case of equal Preference in two or more PEs in the ES, the tie-
breakers will be the DP bit and the lowest IP PE in that order. breakers will be the DP bit and the lowest IP PE in that order.
For instance: For instance:
o If vES1 parameters were [500,0,Pref] in PE1 and [500,1,Pref] in o If vES1 parameters were [500,0,Pref] in PE1 and [500,1,Pref] in
PE2, PE2 would be elected due to the DP bit. PE2, PE2 would be elected due to the DP bit.
o If vES1 parameters were [500,0,Pref] in PE1 and [500,0,Pref] in o 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 lower PE2, PE1 would be elected, assuming PE1's IP address is lower
skipping to change at page 7, line 39 skipping to change at page 9, line 12
dynamically changed based on the use of local policies. For dynamically changed based on the use of local policies. For
instance, on PE1, ES1's Preference can be lowered from 500 to 100 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% (that 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 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
dynamic Preference changes based on the PE's bandwidth dynamic Preference changes based on the PE's bandwidth
availability in the core, of specific ports going operationally availability in the core, of specific ports going operationally
down, etc. The definition of the actual local policies is out of down, etc. The definition of the actual local policies is out of
scope of this document. The default Preference value is 32767. scope of this document. The default Preference value is 32767.
4.2 Use of the Preference algorithm in [RFC7432] Ethernet-Segments The Preference Alg MAY be used along with the AC-DF capability.
Assuming all the PEs in the ES are configured consistently with
Preference Alg and AC-DF capability, a given PE in the ES is not
considered as candidate for DF Election until its corresponding
Ethernet A-D per ES and Ethernet A-D per EVI routes are not received,
as described in [DF].
The procedures in this document can be used in [RFC7432] based ES or
vES as in [vES], and including EVPN networks as in [RFC8214],
[RFC7623] or [RFC8365].
4.2 Use of the Preference algorithm in [RFC7432] Ethernet Segments
While the Preference-based DF Alg described in section 4.1 is While the Preference-based DF Alg described in section 4.1 is
typically used in virtual ES scenarios where there is normally an typically used in virtual ES scenarios where there is normally an
individual EVI per vES, the existing [RFC7432] definition of ES individual Ethernet Tag per vES, the existing [RFC7432] definition of
allows potentially up to thousands of EVIs on the same ES. If this is ES allows potentially up to thousands of Ethernet Tags on the same
the case, and the operator still wants to control who the DF is for a ES. If this is the case, and the operator still wants to control who
given EVI, the use of the Preference-based DF Alg can also provide the DF is for a given Ethernet Tag, the use of the Preference-based
the desired level of load balancing. DF Alg can also provide some level of load balancing.
In this type of scenarios, the ES is configured with an In this type of scenarios, the ES is configured with an
administrative Preference value, but then a range of EVI/ISIDs can be administrative Preference value, but then a range of Ethernet Tags
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 the Preference, however the build a list of candidate PEs ordered by Preference, however the DF
DF for a given EVI/ISID 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 (vlan/ISID-range,high_or_low), e.g. (1- be configured with (Ethernet Tag-range,high_or_low), E.g., (1-
2000,high) and (2001-4000, low). 2000,high) and (2001-4000, low).
o This will result in PE1 being DF for EVI/ISIDs 1-2000 and PE2 being o This will result in PE1 being DF for Ethernet Tags 1-2000 and PE2
DF for EVI/ISIDs 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
valid, as long as that logic is consistent in all the PEs in the ES. valid, as long as that logic is consistent in all the PEs in the ES.
4.3 The Non-Revertive option 4.3 The Non-Revertive Capability
As discussed in section 2(d), an option to NOT preempt the existing As discussed in section 1.2(d), a capability to NOT preempt the
DF for a given EVI/ISID is required and therefore added to the DF existing DF for a given Ethernet Tag is required and therefore added
Election extended community. This option will allow a non-revertive to the DF Election extended community. This option will allow a non-
behavior in the DF election. revertive behavior in the DF election.
Note that, when a given PE in an ES is taken down for maintenance Note that, when a given PE in an ES is taken down for maintenance
operations, before bringing it back, the Preference may be changed in operations, before bringing it back, the Preference may be changed in
order to provide a non-revertive behavior. The DP bit and the order to provide a non-revertive behavior. The DP bit and the
mechanism explained in this section will be used for those cases when mechanism explained in this section will be used for those cases when
a former DF comes back up without any controlled maintenance a former DF comes back up without any controlled maintenance
operation, and the non-revertive option is desired in order to avoid operation, and the non-revertive option is desired in order to avoid
service impact. service impact.
In Figure 1, we assume that based on the Highest-Pref, PE3 is the DF In Figure 1, 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" parameter 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"). with DP=1 ("Don't Preempt Me"). All the PEs in an ES SHOULD be
consistent in their configuration of the DP capability, however
this document do not enforces the consistency across all the PEs.
2) Assuming we want to avoid 'preemption', the three PEs are 2) Assuming we want to avoid 'preemption' in all the PEs in the ES,
configured with the "Don't Preempt Me" option. Note that each PE the three PEs are configured with the "Don't Preempt Me"
individually MAY be configured with different preemption value. In capability. In this example, we assume ESI2 is configured as
this example, we assume ESI2 is configured as 'DP=enabled' in the 'DP=enabled' in the three PEs.
three PEs.
3) Assuming EVI1 uses Highest-Pref in vES2 and EVI2 uses Lowest-Pref, 3) Assuming Ethernet Tag-1 uses Highest-Pref in vES2 and Ethernet
when vES2 is enabled in the three PEs, the PEs will exchange the Tag-2 uses Lowest-Pref, when vES2 is enabled in the three PEs, the
ES routes and select PE3 as DF for EVI1 (due to the Highest-Pref PEs will exchange the ES routes and select PE3 as DF for Ethernet
type), and PE1 as DF for EVI2 (due to the Lowest-Pref). Tag-1 (due to the Highest-Pref type), and PE1 as DF for 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 EVI1. No port failure or node failure), PE2 will become the DF for Ethernet
changes will occur for EVI2. 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. PE3 will then:
o Select two "reference-PEs" among the ES routes in the vES, the o 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 DP - The Highest-PE is the PE with higher Preference, using the DP
skipping to change at page 10, line 29 skipping to change at page 12, line 15
- In this example, PE3's administrative Pref=300 is higher than - In this example, PE3's administrative Pref=300 is higher than
the Highest-PE with DP=1, that is, PE2 (Pref=200). Hence PE3 the Highest-PE with DP=1, that is, PE2 (Pref=200). Hence PE3
will inherit PE2's preference and send the ES route with an will inherit PE2's preference and send the ES route with an
operational 'in-use' [Pref,DP]=[200,0]. operational 'in-use' [Pref,DP]=[200,0].
Note that, a PE will always send DP=0 as long as the advertised Note that, a PE will always send DP=0 as long as the advertised
Pref is the 'in-use' operational Pref (as opposed to the Pref is the 'in-use' operational Pref (as opposed to the
'administrative' Pref). 'administrative' Pref).
This ES route update sent by PE3 (with [200,0,PE3-IP]) will not This ES route update sent by PE3 (with [200,0,PE3-IP]) will not
cause any DF switchover for any EVI/ISID. PE2 will continue being cause any DF switchover for any Ethernet Tag. PE2 will continue
DF for EVI1. This is because the DP bit will be used as a tie- being DF for Ethernet Tag-1. This is because the DP bit will be
breaker in the DF election. That is, if a PE has two candidate PEs used as a tie-breaker in the DF election. That is, if a PE has two
with the same Pref, it will pick up the one with DP=1. There are candidate PEs with the same Pref, it will pick up the one with
no DF changes for EVI2 either. DP=1. There are no DF changes for Ethernet Tag-2 either.
6) Subsequently, if PE2 fails, upon receiving PE2's ES route 6) Subsequently, if PE2 fails, upon receiving PE2's ES route
withdrawal, PE3 and PE1 will go through the process described in withdrawal, PE3 and PE1 will go through the process described in
(5) to select new Highest and Lowest-PEs (considering their own (5) to select new Highest and Lowest-PEs (considering their own
active ES route) and then they will run the DF Election. active ES route) and then they will run the DF Election.
o If a PE selects itself as new Highest or Lowest-PE and it was o 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].
o After running the DF Election, PE3 will become the new DF for o After running the DF Election, PE3 will become the new DF for
EVI1. No changes will occur for EVI2. 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.
5. Conventions used in this document 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 ES
after running the DF Election, irrespective of the revertive or non-
revertive behavior in the PE.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 5. Security Considerations
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
6. Security Considerations This document describes a DF Election Algorithm that provides
absolute control (by configuration) over what PE is the DF for a
given Ethernet Tag. While this control is desired in many situations,
an malicious user that gets access to the configuration of a PE in
the ES may change the behavior of the network. In other DF Algs such
as HRW, the DF Election is more automated and cannot be determined by
configuration.
This section will be added in future versions. The non-revertive capability described in this document may be seen
as a security improvement over the regular EVPN revertive DF
Election: an intentional link (or node) "flapping" on a PE will only
cause service disruption once, when the PE goes to NDF state.
7. IANA Considerations 6. IANA Considerations
This document solicits the allocation of DF Alg = 2 in the registry This document solicits the allocation of the following values:
created by [DF] for the DF Alg field, and the DP bit (Bit 0) in the
[DF] Bitmap registry.
8. References o DF Alg = 2 in the [DF] "DF Alg" registry, with name "Preference
Algorithm".
8.1 Normative References o Bit 0 in the [DF] DF Election Capabilities registry, with name "D
(Don't Preempt) Capability" for Non-revertive ES.
[RFC7432]Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 7. References
7.1 Normative References
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet
VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015,
<https://www.rfc-editor.org/info/rfc7432>. <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-Drake et al., "A Network Virtualization Overlay
Solution using EVPN", RFC 8365, March 2017, <http://www.rfc-
editor.org/info/rfc8365>
[DF] Rabadan J., Mohanty S. et al. "Framework for EVPN Designated [DF] Rabadan J., Mohanty S. et al. "Framework for EVPN Designated
Forwarder Election Extensibility", draft-ietf-bess-evpn-df-election- Forwarder Election Extensibility", draft-ietf-bess-evpn-df-election-
framework-05, work-in-progress, October, 2018. framework-07, work-in-progress, December, 2018.
[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, DOI 10.17487/RFC2119, March Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March
1997, <https://www.rfc-editor.org/info/rfc2119>. 1997, <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, May 2017, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>. <https://www.rfc-editor.org/info/rfc8174>.
8.2 Informative References 7.2 Informative References
[vES] Sajassi et al. "EVPN Virtual Ethernet Segment", draft-ietf- [vES] Sajassi et al. "EVPN Virtual Ethernet Segment", draft-ietf-
bess-evpn-virtual-eth-segment-00, work-in-progress, June, 2018. bess-evpn-virtual-eth-segment-00, work-in-progress, June, 2018.
9. Acknowledgments 8. Acknowledgments
The authors would like to thank Kishore Tiruveedhula for his review The authors would like to thank Kishore Tiruveedhula for his review
and comments. and comments.
10. Contributors 9. 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
11. Authors' Addresses 10. Authors' Addresses
Jorge Rabadan Jorge Rabadan
Nokia Nokia
777 E. Middlefield Road 777 E. Middlefield Road
Mountain View, CA 94043 USA Mountain View, CA 94043 USA
Email: jorge.rabadan@nokia.com Email: jorge.rabadan@nokia.com
Senthil Sathappan Senthil Sathappan
Alcatel-Lucent Alcatel-Lucent
Email: senthil.sathappan@nokia.com Email: senthil.sathappan@nokia.com
 End of changes. 60 change blocks. 
145 lines changed or deleted 249 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/