< draft-ietf-bess-evpn-pref-df-04.txt		draft-ietf-bess-evpn-pref-df-05.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
	S. Boutros T. Przygienda		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
			December 17, 2019
	Expires: December 27, 2019 June 25, 2019
	Preference-based EVPN DF Election		Preference-based EVPN DF Election
	draft-ietf-bess-evpn-pref-df-04		draft-ietf-bess-evpn-pref-df-05
	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		Unknown unicast and Broadcast traffic (BUM) to a multi-homed device/
	device/network in the case of an all-active multi-homing Ethernet		network in the case of an all-active multi-homing Ethernet Segment
	Segment (ES), or BUM and unicast in the case of single-active multi-		(ES), or BUM and unicast in the case of single-active multi-homing.
	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
	same Ethernet Segment Identifier (ESI) to the EVPN network, according		same Ethernet Segment Identifier (ESI) to the EVPN network, according
	to 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 Ethernet Tags 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
	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). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		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."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on June 19, 2020.
	http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html
	This Internet-Draft will expire on December 27, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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		(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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		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. Conventions 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 . . . . . . . . . . . . . . . . . . . 12
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
	7.1 Normative References . . . . . . . . . . . . . . . . . . . . 13		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
	7.2 Informative References . . . . . . . . . . . . . . . . . . . 14		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . 13
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14		9.2. Informative References . . . . . . . . . . . . . . . . . 14
	10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction
	1.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 DF Election Algorithm, or DF Alg as per [DF].		to the DF Election Algorithm, or DF Alg as per [RFC8584].
	While the Default DF Alg [RFC7432] or HRW [DF] provide an efficient		While the Default DF Alg [RFC7432] or HRW [RFC8584] provide an
	and automated way of selecting the DF across different Ethernet Tags		efficient and automated way of selecting the DF across different
	in the ES, there are some use-cases where a more 'deterministic' and		Ethernet Tags in the ES, there are some use-cases where a more
	user-controlled method is required. At the same time, Service		'deterministic' and user-controlled method is required. At the same
	Providers require an easy way to force an on-demand DF switchover in		time, Service Providers require an easy way to force an on-demand DF
	order to carry out some maintenance tasks on the existing DF or		switchover in order to carry out some maintenance tasks on the
	control whether a new active PE can preempt the existing DF PE.		existing DF or control whether a new active PE can preempt the
			existing DF PE.
	This document proposes a new DF Alg and capability to address the		This document proposes a new DF Alg and capability to address the
	above needs.		above needs.
	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
	DF, assuming they are all operationally ready to take over as DF.		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 and virtual
	virtual ES, as defined in [vES].		ES, as defined in [I-D.ietf-bess-evpn-virtual-eth-segment].
	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
	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. Conventions 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 - refers to Designated Forwarder Election Algorithm.
	o HRW - Highest Random Weight, as per [DF].		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.
	o MAC-VRF - A Virtual Routing and Forwarding table for Media Access		o MAC-VRF - A Virtual Routing and Forwarding table for Media Access
	Control (MAC) addresses on a PE.		Control (MAC) addresses on a PE.
	o BD - Broadcast Domain. An EVI may be comprised of one (VLAN-Based		o BD - Broadcast Domain. An EVI may be comprised of one (VLAN-Based
	or VLAN Bundle services) or multiple (VLAN-Aware Bundle services)		or VLAN Bundle services) or multiple (VLAN-Aware Bundle services)
	Broadcast Domains.		Broadcast Domains.
	o EVC - Ethernet Virtual Circuit.		o EVC - Ethernet Virtual Circuit.
	o DP - refers to the "Don't Preempt me" capability in the DF Election		o DP - refers to the "Don't Preempt me" capability in the DF
	extended community.		Election extended community.
	o OAM - refers to Operations And Maintenance protocols.		o OAM - refers to Operations And Maintenance protocols.
	o Ethernet A-D per ES route - refers to [RFC7432] route type 1 or		o Ethernet A-D per ES route - refers to [RFC7432] route type 1 or
	Auto-Discovery per Ethernet Segment route.		Auto-Discovery per Ethernet Segment route.
	o Ethernet A-D per EVI route - refers to [RFC7432] route type 1 or		o Ethernet A-D per EVI route - refers to [RFC7432] route type 1 or
	Auto-Discovery per EVPN Instance route.		Auto-Discovery per EVPN Instance route.
	o Ethernet Tag - used to represent a Broadcast Domain that is		o Ethernet Tag - used to represent a Broadcast Domain that is
	configured on a given ES for the purpose of DF election. Note that		configured on a given ES for the purpose of DF election. Note
	any of the following may be used to represent a Broadcast Domain:		that any of the following may be used to represent a Broadcast
	VIDs (including Q-in-Q tags), configured IDs, VNI (VXLAN Network		Domain: VIDs (including Q-in-Q tags), configured IDs, VNI (VXLAN
	Identifiers), normalized VID, I-SIDs (Service Instance		Network Identifiers), normalized VID, I-SIDs (Service Instance
	Identifiers), etc., as long as the representation of the broadcast		Identifiers), etc., as long as the representation of the broadcast
	domains is configured consistently across the multi-homed PEs		domains is configured consistently across the multi-homed PEs
	attached to that ES. The Ethernet Tag value MUST be different from		attached to that ES. The Ethernet Tag value MUST be different
	zero.		from zero.
	3. EVPN BGP Attributes Extensions		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 [RFC8584] 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)| 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 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 DF Election algorithm, or modulus-based algorithm		- Alg 0 - Default DF Election algorithm, or modulus-based
	as per [RFC7432].		algorithm as per [RFC7432].
	- Alg 1 - HRW algorithm as per [DF].		- Alg 1 - HRW algorithm as per [RFC8584].
	- Alg 2 - Preference algorithm (this document).
	o Bitmap (2 octets) can have the following values:		- 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 and it is defined by this document): D bit or 'Don't		Community and it is defined by this document): D bit or 'Don't
	Preempt' bit (DP hereafter), determines if the PE advertising the		Preempt' bit (DP hereafter), determines if the PE advertising
	ES route requests the remote PEs in the ES not to preempt it as		the ES route requests the remote PEs in the ES not to preempt
	DF. The default value is DP=0, which is compatible with the		it as DF. The default value is DP=0, which is compatible with
	'preempt' or 'revertive' behavior in the Default DF Alg		the 'preempt' or 'revertive' behavior in the Default DF Alg
	[RFC7432]. The DP bit SHOULD be ignored if the DF Alg is		[RFC7432]. The DP bit SHOULD be ignored if the DF Alg is
	different than 2.		different than 2.
	- Bit 1: AC-DF or AC-Influenced DF Election, as explained in [DF].		- Bit 1: AC-DF or AC-Influenced DF Election, as explained in
	When set to 1, it indicates the desire to use AC-Influenced DF		[RFC8584]. When set to 1, it indicates the desire to use AC-
	Election with the rest of the PEs in the ES. The AC-DF capability		Influenced DF Election with the rest of the PEs in the ES. The
	bit MAY be set along with the DP capability and DF Alg 2.		AC-DF capability bit MAY be set along with the DP capability
			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 Preference		MUST be 32767. This value is the midpoint in the allowed
	range of values, which gives the operator the flexibility of		Preference range of values, which gives the operator the
	choosing a significant number of values, above or below the default		flexibility of choosing a significant number of values, above or
	Preference. The DF Preference field is specific to DF Alg 2 and		below the default Preference. The DF Preference field is specific
	does not represent any Preference value for other Algs.		to DF Alg 2 and 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---+
	| <-----ESI2,100 | |===||=== |		| <-----ESI2,100 | |===||=== |
	| | |===||== \ vES1 | +----+		| | |===||== \ vES1 | +----+
	skipping to change at page 7, line 24 ¶		skipping to change at page 7, line 24 ¶
	| | | X |		| | | X |
	| <---ESI1,255 +-----+============ \ |		| <---ESI1,255 +-----+============ \ |
	| <-----ESI2,200 | PE2 |========== \ vES2 | +----+		| <-----ESI2,200 | PE2 |========== \ vES2 | +----+
	| +-----+ | \ ----------+CE2 |		| +-----+ | \ ----------+CE2 |
	| | | --------------| |		| | | --------------| |
	| +-----+ ----------------------+ |		| +-----+ ----------------------+ |
	| <-----ESI2,300 | PE3 +--/ | | +----+		| <-----ESI2,300 | PE3 +--/ | | +----+
	| +-----+ +--------------+		| +-----+ +--------------+
	--------------------+		--------------------+
	Figure 3 - ES and Deterministic DF Election		Figure 3: Preference-based DF Election
	Figure 1 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 - 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 procedures and how they are applied in		provide some examples of the procedures and how they are applied in
	the use-case in Figure 1.		the use-case of Figure 3.
	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
	as [Pref,DP,Alg]. Let's assume vES1 is configured as [500,0,Pref]		parameters as [Pref,DP,Alg]. Let's assume vES1 is configured as
	in PE1, and [255,0,Pref] in PE2. vES2 is configured as		[500,0,Pref] in PE1, and [255,0,Pref] in PE2. vES2 is configured
	[100,0,Pref], [200,0,Pref] and [300,0,Pref] in PE1, PE2 and PE3		as [100,0,Pref], [200,0,Pref] and [300,0,Pref] in PE1, PE2 and
	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 [RFC7432], each PE will run the DF election algorithm		c. According to [RFC8584], each PE will run the DF election
	upon expiration of the DF Wait timer. In this case, each PE runs		algorithm upon expiration of the DF Wait timer. In this case,
	the Preference-based DF Alg for each ES as follows:		each PE runs the Preference-based DF Alg for each ES as follows:
	o 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 the		assuming all the ES routes are consistent in this DF Alg and
	value is 2 (Preference-based), the PE will run the new extended		the value is 2 (Preference-based), the PE will run the new
	procedure. Otherwise, the procedure will fall back to [RFC7432]		extended procedure. Otherwise, the procedure will fall back
	Default Alg.		to [RFC7432] Default Alg.
	o In this Preference-based Alg, each PE builds a list of candidate		- In this Preference-based Alg, each PE builds a list of
	PEs, ordered by Preference. E.g. PE1 will build a list of		candidate PEs, ordered by Preference. E.g. PE1 will build a
	candidate PEs for vES1 ordered by the Preference, from high to		list of candidate PEs for vES1 ordered by the Preference, from
	low: PE1>PE2. Hence PE1 will become the DF for vES1. In the same		high to low: PE1>PE2. Hence PE1 will become the DF for vES1.
	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
	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 (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 old		could decide to leave the existing preference or configure the
	preference back.		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
	breakers will be the DP bit and the lowest IP PE in that order.		tie-breakers will be the DP bit and the lowest IP PE, in that
	For instance:		order. For instance:
	o If vES1 parameters were [500,0,Pref] in PE1 and [500,1,Pref] in		- If vES1 parameters were [500,0,Pref] in PE1 and [500,1,Pref]
	PE2, PE2 would be elected due to the DP bit.		in 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		- If vES1 parameters were [500,0,Pref] in PE1 and [500,0,Pref]
	PE2, PE1 would be elected, assuming PE1's IP address is lower		in PE2, PE1 would be elected, assuming PE1's IP address is
	than PE2's.		lower than PE2's.
	g) The Preference is an administrative option that MUST be configured		g. The Preference is an administrative option that MUST be
	on a per-ES basis from the management plane, but MAY also be		configured on a per-ES basis from the management plane, but MAY
	dynamically changed based on the use of local policies. For		also be dynamically changed based on the use of local policies.
	instance, on PE1, ES1's Preference can be lowered from 500 to 100		For instance, on PE1, ES1's Preference can be lowered from 500 to
	in case the bandwidth on the ENNI port is decreased a 50% (that		100 in case the bandwidth on the ENNI port is decreased a 50%
	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
	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, 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.
	The Preference Alg MAY be used along with the AC-DF capability.		The Preference Alg MAY be used along with the AC-DF capability.
	Assuming all the PEs in the ES are configured consistently with		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		Preference Alg and AC-DF capability, a given PE in the ES is not
	considered as candidate for DF Election until its corresponding		considered as candidate for DF Election until its corresponding
	Ethernet A-D per ES and Ethernet A-D per EVI routes are not received,		Ethernet A-D per ES and Ethernet A-D per EVI routes are not received,
	as described in [DF].		as described in [RFC8584].
	The procedures in this document can be used in [RFC7432] based ES or		The procedures in this document can be used in [RFC7432] based ES or
	vES as in [vES], and including EVPN networks as in [RFC8214],		vES as in [I-D.ietf-bess-evpn-virtual-eth-segment], and including
	[RFC7623] or [RFC8365].		EVPN networks as in [RFC8214], [RFC7623] or [RFC8365].
	4.2 Use of the Preference algorithm in [RFC7432] Ethernet Segments		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 Ethernet Tag per vES, the existing [RFC7432] definition of		individual Ethernet Tag per vES, the existing [RFC7432] definition of
	ES allows potentially up to thousands of Ethernet Tags on the same		ES allows potentially up to thousands of Ethernet Tags on the same
	ES. If this is the case, and the operator still wants to control who		ES. If this is the case, and the operator still wants to control who
	the DF is for a given Ethernet Tag, the use of the Preference-based		the DF is for a given Ethernet Tag, the use of the Preference-based
	DF Alg can also provide some 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 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., (1-		be configured with (Ethernet Tag-range,high_or_low), E.g.,
	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
	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 Capability		4.3. The Non-Revertive Capability
	As discussed in section 1.2(d), a capability to NOT preempt the		As discussed in Section 1.2 (d), a capability to NOT preempt the
	existing DF for a given Ethernet Tag is required and therefore added		existing DF for a given Ethernet Tag is required and therefore added
	to the DF Election extended community. This option will allow a non-		to the DF Election extended community. This option will allow a non-
	revertive 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 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 enforces the consistency across all the PEs.
	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, the		Tag-2 uses Lowest-Pref, when vES2 is enabled in the three PEs,
	PEs will exchange the ES routes and select PE3 as DF for Ethernet		the PEs will exchange the ES routes and select PE3 as DF for
	Tag-1 (due to the Highest-Pref type), and PE1 as DF for Ethernet		Ethernet Tag-1 (due to the Highest-Pref type), and PE1 as DF for
	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 Ethernet		port failure or node failure), PE2 will become the DF for
	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. PE3 will then:
	o 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 DP		* The Highest-PE is the PE with higher Preference, using the
	bit first (with DP=1 being better) and, after that, the lower		DP bit first (with DP=1 being better) and, after that, the
	PE-IP address as tie-breakers. PE3 will select PE2 as Highest-		lower PE-IP address as tie-breakers. PE3 will select PE2
	PE over PE1, since, when comparing [Pref,DP,PE-IP],		as Highest-PE over PE1, since, when comparing [Pref,DP,PE-
	[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 lower		bit first (with DP=1 being better) and, after that, the
	PE-IP address as tie-breakers. PE3 will select PE1 as Lowest-		lower PE-IP address as tie-breakers. PE3 will select PE1
	PE over PE2, since [100,1,PE1-IP] wins over [200,1,PE2-IP].		as Lowest-PE over PE2, since [100,1,PE1-IP] wins over
			[200,1,PE2-IP].
	- Note that if there were only one remote PE in the ES, Lowest		* Note that if there were only one remote PE in the ES,
	and Highest PE would be the same PE.		Lowest and Highest PE would be the same PE.
	o 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 route		routes. Depending on this comparison PE3 will send the ES
	with a [Pref,DP] that may be different from its administrative		route with a [Pref,DP] that may be different from its
	[Pref,DP]:		administrative [Pref,DP]:
	- If PE3's Pref value is higher than the Highest-PE's, PE3 will		* If PE3's Pref value is higher than the Highest-PE's, PE3
	send the ES route with an 'in-use' operational Pref equal to		will send the ES route with an 'in-use' operational Pref
	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 than		* In this example, PE3's administrative Pref=300 is higher
	the Highest-PE with DP=1, that is, PE2 (Pref=200). Hence PE3		than the Highest-PE with DP=1, that is, PE2 (Pref=200).
	will inherit PE2's preference and send the ES route with an
	operational 'in-use' [Pref,DP]=[200,0].
	Note that, a PE will always send DP=0 as long as the advertised		Hence PE3 will inherit PE2's preference and send the ES
	Pref is the 'in-use' operational Pref (as opposed to the		route with an operational 'in-use' [Pref,DP]=[200,0].
	'administrative' Pref).
	This ES route update sent by PE3 (with [200,0,PE3-IP]) will not		- Note that, a PE will always send DP=0 as long as the
	cause any DF switchover for any Ethernet Tag. PE2 will continue		advertised Pref is the 'in-use' operational Pref (as opposed
	being DF for Ethernet Tag-1. This is because the DP bit will be		to the 'administrative' Pref).
	used as a tie-breaker in the DF election. That 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 Ethernet Tag-2 either.
	6) Subsequently, if PE2 fails, upon receiving PE2's ES route		- This ES route update sent by PE3 (with [200,0,PE3-IP]) will
	withdrawal, PE3 and PE1 will go through the process described in		not cause any DF switchover for any Ethernet Tag. PE2 will
	(5) to select new Highest and Lowest-PEs (considering their own		continue being DF for Ethernet Tag-1. This is because the DP
	active ES route) and then they will run the DF Election.		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
			pick up the one with DP=1. There are no DF changes for
			Ethernet Tag-2 either.
	o If a PE selects itself as new Highest or Lowest-PE and it was		6. Subsequently, if PE2 fails, upon receiving PE2's ES route
	not before, the PE will then compare its operational 'in-use'		withdrawal, PE3 and PE1 will go through the process described in
	Pref with its administrative Pref. If different, the PE will		(5) to select new Highest and Lowest-PEs (considering their own
	send an ES route update with its administrative Pref and DP		active ES route) and then they will run the DF Election.
	values. In the example, PE3 will be the new Highest-PE,
	therefore it will send an ES route update with
	[Pref,DP]=[300,1].
	o After running the DF Election, PE3 will become the new DF for		- If a PE selects itself as new Highest or Lowest-PE and it was
	Ethernet Tag-1. No changes will occur for Ethernet Tag-2.		not before, the PE will then compare its operational 'in-use'
			Pref with its administrative Pref. If different, the PE will
			send an ES route update with its administrative Pref and DP
			values. In the example, PE3 will be the new Highest-PE,
			therefore it will send an ES route update with
			[Pref,DP]=[300,1].
			- After running the DF Election, PE3 will become the new DF for
			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
	Ethernet A-D per EVI routes [RFC8214] advertised by the PEs in the ES		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-		after running the DF Election, irrespective of the revertive or non-
	revertive behavior in the PE.		revertive behavior in the PE.
	5. Security Considerations		5. Security Considerations
	This document describes a DF Election Algorithm that provides		This document describes a DF Election Algorithm that provides
	absolute control (by configuration) over what PE is the DF for a		absolute control (by configuration) over what PE is the DF for a
	given Ethernet Tag. While this control is desired in many situations,		given Ethernet Tag. While this control is desired in many situations,
	a malicious user that gets access to the configuration of a PE in the		a 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		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		HRW, the DF Election is more automated and cannot be determined by
	configuration.		configuration.
	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 DF		as a security improvement over the regular EVPN revertive DF
	Election: an intentional link (or node) "flapping" on a PE will only		Election: an intentional link (or node) "flapping" on a PE will only
	cause service disruption once, when the PE goes to NDF state.		cause service disruption once, when the PE goes to NDF state.
	6. IANA Considerations		6. IANA Considerations
	This document solicits the allocation of the following values:		This document solicits the allocation of the following values:
	o DF Alg = 2 in the [DF] "DF Alg" registry, with name "Preference		o DF Alg = 2 in the [RFC8584] "DF Alg" registry, with name
	Algorithm".		"Preference Algorithm".
	o Bit 0 in the [DF] DF Election Capabilities registry, with name "D		o Bit 0 in the [RFC8584] DF Election Capabilities registry, with
	(Don't Preempt) Capability" for Non-revertive ES.		name "D (Don't Preempt) Capability" for Non-revertive ES.
	7. References		7. Acknowledgments
	7.1 Normative References		The authors would like to thank Kishore Tiruveedhula for his review
			and comments.
			8. Contributors
			In addition to the authors listed, the following individuals also
			contributed to this document:
			Kiran Nagaraj, Nokia
			Vinod Prabhu, Nokia
			Selvakumar Sivaraj, Juniper
			Sami Boutros, VMWare
			9. 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 Ethernet		Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
	VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015,		Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
	<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.		[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
	Rabadan, "Virtual Private Wire Service Support in Ethernet VPN", RFC		Rabadan, "Virtual Private Wire Service Support in Ethernet
	8214, DOI 10.17487/RFC8214, August 2017, <https://www.rfc-		VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
	editor.org/info/rfc8214>.		<https://www.rfc-editor.org/info/rfc8214>.
	[RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W.		[RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W.
	Henderickx, "Provider Backbone Bridging Combined with Ethernet VPN		Henderickx, "Provider Backbone Bridging Combined with
	(PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, September 2015,		Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623,
	<https://www.rfc-editor.org/info/rfc7623>.		September 2015, <https://www.rfc-editor.org/info/rfc7623>.
	[RFC8365] Sajassi-Drake et al., "A Network Virtualization Overlay		[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
	Solution using EVPN", RFC 8365, March 2017, <http://www.rfc-		Uttaro, J., and W. Henderickx, "A Network Virtualization
	editor.org/info/rfc8365>		Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
			DOI 10.17487/RFC8365, March 2018,
			<https://www.rfc-editor.org/info/rfc8365>.
	[DF] Rabadan J., Mohanty S. et al. "Framework for EVPN Designated		[RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake,
	Forwarder Election Extensibility", draft-ietf-bess-evpn-df-election-		J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet
	framework-07, work-in-progress, December, 2018.		VPN Designated Forwarder Election Extensibility",
			RFC 8584, DOI 10.17487/RFC8584, April 2019,
			<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, DOI 10.17487/RFC2119, March		Requirement Levels", BCP 14, RFC 2119,
	1997, <https://www.rfc-editor.org/info/rfc2119>.		DOI 10.17487/RFC2119, March 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,
	<https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	7.2 Informative References		9.2. Informative References
	[vES] Sajassi et al. "EVPN Virtual Ethernet Segment", draft-ietf-		[I-D.ietf-bess-evpn-virtual-eth-segment]
	bess-evpn-virtual-eth-segment-00, work-in-progress, June, 2018.		Sajassi, A., Brissette, P., Schell, R., Drake, J., and J.
			Rabadan, "EVPN Virtual Ethernet Segment", draft-ietf-bess-
			evpn-virtual-eth-segment-04 (work in progress), January
			2019.
	8. Acknowledgments		Authors' Addresses
	The authors would like to thank Kishore Tiruveedhula for his review		J. Rabadan (editor)
	and comments.		Nokia
			777 Middlefield Road
			Mountain View, CA 94043
			USA
	9. Contributors		Email: jorge.rabadan@nokia.com
			S. Sathappan
			Nokia
	In addition to the authors listed, the following individuals also		Email: senthil.sathappan@nokia.com
	contributed to this document:
	Kiran Nagaraj, Nokia		T. Przygienda
	Vinod Prabhu, Nokia		Juniper Networks
	Selvakumar Sivaraj, Juniper
	10. Authors' Addresses		Email: prz@juniper.net
	Jorge Rabadan		W. Lin
	Nokia		Juniper Networks
	777 E. Middlefield Road
	Mountain View, CA 94043 USA
	Email: jorge.rabadan@nokia.com
	Senthil Sathappan		Email: wlin@juniper.net
	Nokia
	Email: senthil.sathappan@nokia.com
	Tony Przygienda		J. Drake
	Juniper Networks, Inc.		Juniper Networks
	Email: prz@juniper.net
	John Drake
	Juniper Networks, Inc.
	Email: jdrake@juniper.net		Email: jdrake@juniper.net
	Wen Lin
	Juniper Networks, Inc.
	Email: wlin@juniper.net
	Ali Sajassi		A. Sajassi
	Cisco Systems, Inc.		Cisco Systems
	Email: sajassi@cisco.com		Email: sajassi@cisco.com
	Satya Ranjan Mohanty		S. Mohanty
	Cisco Systems, Inc.		Cisco Systems
	Email: satyamoh@cisco.com
	Sami Boutros		Email: satyamoh@cisco.com
	Email: boutros.sami@gmail.com
End of changes. 132 change blocks.
	356 lines changed or deleted		371 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/