< draft-ietf-nvo3-evpn-applicability-01.txt		draft-ietf-nvo3-evpn-applicability-02.txt >
	NVO3 Workgroup J. Rabadan, Ed.		NVO3 Workgroup J. Rabadan, Ed.
	Internet Draft M. Bocci		Internet Draft M. Bocci
	Intended status: Informational Nokia		Intended status: Informational Nokia
	S. Boutros		S. Boutros
	WMware		VMware
	A. Sajassi		A. Sajassi
	Cisco		Cisco
	Expires: April 25, 2019 October 22, 2018		Expires: January 9, 2020 July 8, 2019
	Applicability of EVPN to NVO3 Networks		Applicability of EVPN to NVO3 Networks
	draft-ietf-nvo3-evpn-applicability-01		draft-ietf-nvo3-evpn-applicability-02
	Abstract		Abstract
	In NVO3 networks, Network Virtualization Edge (NVE) devices sit at		In NVO3 networks, Network Virtualization Edge (NVE) devices sit at
	the edge of the underlay network and provide Layer-2 and Layer-3		the edge of the underlay network and provide Layer-2 and Layer-3
	connectivity among Tenant Systems (TSes) of the same tenant. The NVEs		connectivity among Tenant Systems (TSes) of the same tenant. The NVEs
	need to build and maintain mapping tables so that they can deliver		need to build and maintain mapping tables so that they can deliver
	encapsulated packets to their intended destination NVE(s). While		encapsulated packets to their intended destination NVE(s). While
	there are different options to create and disseminate the mapping		there are different options to create and disseminate the mapping
	table entries, NVEs may exchange that information directly among		table entries, NVEs may exchange that information directly among
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	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, 2019.		This Internet-Draft will expire on January 9, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 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		(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
	skipping to change at page 3, line 14 ¶		skipping to change at page 3, line 14 ¶
	4.7.4. Ingress Replication (IR) Optimization For BUM Traffic . 18		4.7.4. Ingress Replication (IR) Optimization For BUM Traffic . 18
	4.7.5. EVPN Multi-homing . . . . . . . . . . . . . . . . . . . 19		4.7.5. EVPN Multi-homing . . . . . . . . . . . . . . . . . . . 19
	4.7.6. EVPN Recursive Resolution for Inter-Subnet Unicast		4.7.6. EVPN Recursive Resolution for Inter-Subnet Unicast
	Forwarding . . . . . . . . . . . . . . . . . . . . . . 20		Forwarding . . . . . . . . . . . . . . . . . . . . . . 20
	4.7.7. EVPN Optimized Inter-Subnet Multicast Forwarding . . . 21		4.7.7. EVPN Optimized Inter-Subnet Multicast Forwarding . . . 21
	4.7.8. Data Center Interconnect (DCI) . . . . . . . . . . . . 21		4.7.8. Data Center Interconnect (DCI) . . . . . . . . . . . . 21
	5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 22		5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	6. Conventions used in this document . . . . . . . . . . . . . . . 22		6. Conventions used in this document . . . . . . . . . . . . . . . 22
	7. Security Considerations . . . . . . . . . . . . . . . . . . . . 22		7. Security Considerations . . . . . . . . . . . . . . . . . . . . 22
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 22		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	9.1 Normative References . . . . . . . . . . . . . . . . . . . . 23		9.1 Normative References . . . . . . . . . . . . . . . . . . . . 23
	9.2 Informative References . . . . . . . . . . . . . . . . . . . 23		9.2 Informative References . . . . . . . . . . . . . . . . . . . 23
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
	11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
	12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25		12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26
	1. Introduction		1. Introduction
	In NVO3 networks, Network Virtualization Edge (NVE) devices sit at		In NVO3 networks, Network Virtualization Edge (NVE) devices sit at
	the edge of the underlay network and provide Layer-2 and Layer-3		the edge of the underlay network and provide Layer-2 and Layer-3
	connectivity among Tenant Systems (TSes) of the same tenant. The NVEs		connectivity among Tenant Systems (TSes) of the same tenant. The NVEs
	need to build and maintain mapping tables so that they can deliver		need to build and maintain mapping tables so that they can deliver
	encapsulated packets to their intended destination NVE(s). While		encapsulated packets to their intended destination NVE(s). While
	there are different options to create and disseminate the mapping		there are different options to create and disseminate the mapping
	table entries, NVEs may exchange that information directly among		table entries, NVEs may exchange that information directly among
	themselves via a control-plane protocol, such as EVPN. EVPN provides		themselves via a control-plane protocol, such as EVPN. EVPN provides
	an efficient, flexible and unified control-plane option that can be		an efficient, flexible and unified control-plane option that can be
	used for Layer-2 and Layer-3 Virtual Network (VN) service		used for Layer-2 and Layer-3 Virtual Network (VN) service
	connectivity.		connectivity.
	In this document, we assume that the EVPN control-plane module		In this document, we assume that the EVPN control-plane module
	resides in the NVEs. The NVEs can be virtual switches in hypervisors,		resides in the NVEs. The NVEs can be virtual switches in hypervisors,
	TOR/Leaf switches or Data Center Gateways. Note that Network		TOR/Leaf switches or Data Center Gateways. As described in [RFC7365],
	Virtualization Authorities (NVAs) may be used to provide the		Network Virtualization Authorities (NVAs) may be used to provide the
	forwarding information to the NVEs, and in that case, EVPN could be		forwarding information to the NVEs, and in that case, EVPN could be
	used to disseminate the information across multiple federated NVAs.		used to disseminate the information across multiple federated NVAs.
	The applicability of EVPN would then be similar to the one described		The applicability of EVPN would then be similar to the one described
	in this document. However, for simplicity, the description assumes		in this document. However, for simplicity, the description assumes
	control-plane communication among NVE(s).		control-plane communication among NVE(s).
	2. EVPN and NVO3 Terminology		2. EVPN and NVO3 Terminology
	o EVPN: Ethernet Virtual Private Networks, as described in [RFC7432].		o EVPN: Ethernet Virtual Private Networks, as described in [RFC7432].
	skipping to change at page 6, line 34 ¶		skipping to change at page 6, line 34 ¶
	o PTA: Provider Multicast Service Interface Tunnel Attribute.		o PTA: Provider Multicast Service Interface Tunnel Attribute.
	o RT-1, RT-2, RT-3, etc.: they refer to Route Type followed by the		o RT-1, RT-2, RT-3, etc.: they refer to Route Type followed by the
	type number as defined in the IANA registry for EVPN route types.		type number as defined in the IANA registry for EVPN route types.
	o TS: Tenant System.		o TS: Tenant System.
	o ARP and ND: they refer to Address Resolution Protocol and Neighbor		o ARP and ND: they refer to Address Resolution Protocol and Neighbor
	Discovery protocol.		Discovery protocol.
			o Ethernet Tag: Used to represent a BD 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 BD: VIDs (including Q-in-Q tags),
			configured IDs, VNIs (Virtual Extensible Local Area Network (VXLAN)
			Network Identifiers), normalized VIDs, I-SIDs (Service Instance
			Identifiers), etc., as long as the representation of the BDs is
			configured consistently across the multihomed PEs attached to that
			ES. The Ethernet Tag value MUST be different from zero.
	3. Why Is EVPN Needed In NVO3 Networks?		3. Why Is EVPN Needed In NVO3 Networks?
	Data Centers have adopted NVO3 architectures mostly due to the issues		Data Centers have adopted NVO3 architectures mostly due to the issues
	discussed in [RFC7364]. The architecture of a Data Center is nowadays		discussed in [RFC7364]. The architecture of a Data Center is nowadays
	based on a CLOS design, where every Leaf is connected to a layer of		based on a CLOS design, where every Leaf is connected to a layer of
	Spines, and there is a number of ECMP paths between any two leaf		Spines, and there is a number of ECMP paths between any two leaf
	nodes. All the links between Leaf and Spine nodes are routed links,		nodes. All the links between Leaf and Spine nodes are routed links,
	forming what we also know as an underlay IP Fabric. The underlay IP		forming what we also know as an underlay IP Fabric. The underlay IP
	Fabric does not have issues with loops or flooding (like old Spanning		Fabric does not have issues with loops or flooding (like old Spanning
	Tree Data Center designs did), convergence is fast and ECMP provides		Tree Data Center designs did), convergence is fast and ECMP provides
	skipping to change at page 9, line 26 ¶		skipping to change at page 9, line 26 ¶
	| |Ethernet Tag |setup |		| |Ethernet Tag |setup |
	+----+------------------------+-------------------------------------+		+----+------------------------+-------------------------------------+
	|4 |Ethernet Segment |Multi-homing: ES auto-discovery and |		|4 |Ethernet Segment |Multi-homing: ES auto-discovery and |
	| | |DF Election |		| | |DF Election |
	+----+------------------------+-------------------------------------+		+----+------------------------+-------------------------------------+
	|5 |IP Prefix |IP Prefix dissemination |		|5 |IP Prefix |IP Prefix dissemination |
	+----+------------------------+-------------------------------------+		+----+------------------------+-------------------------------------+
	|6 |Selective Multicast |Indicate interest for a multicast |		|6 |Selective Multicast |Indicate interest for a multicast |
	| |Ethernet Tag |S,G or *,G |		| |Ethernet Tag |S,G or *,G |
	+----+------------------------+-------------------------------------+		+----+------------------------+-------------------------------------+
	|7 |IGMP Join Synch |Multi-homing: S,G or *,G state synch |		|7 |Multicast Join Synch |Multi-homing: S,G or *,G state synch |
	+----+------------------------+-------------------------------------+		+----+------------------------+-------------------------------------+
	|8 |IGMP Leave Synch |Multi-homing: S,G or *,G leave synch |		|8 |Multicast Leave Synch |Multi-homing: S,G or *,G leave synch |
	+----+------------------------+-------------------------------------+		+----+------------------------+-------------------------------------+
	|9 |Per-Region I-PMSI A-D |BUM tree creation across regions |		|9 |Per-Region I-PMSI A-D |BUM tree creation across regions |
	+----+------------------------+-------------------------------------+		+----+------------------------+-------------------------------------+
	|10 |S-PMSI A-D |Multicast tree for S,G or *,G states |		|10 |S-PMSI A-D |Multicast tree for S,G or *,G states |
	+----+------------------------+-------------------------------------+		+----+------------------------+-------------------------------------+
	|11 |Leaf A-D |Used for responses to explicit |		|11 |Leaf A-D |Used for responses to explicit |
	| | |tracking |		| | |tracking |
	+----+------------------------+-------------------------------------+		+----+------------------------+-------------------------------------+
	Table 1 EVPN route types		Table 1 EVPN route types
	skipping to change at page 10, line 40 ¶		skipping to change at page 10, line 40 ¶
	o BD1 is an EVPN Broadcast Domain for a given tenant and TS1, TS2 and		o BD1 is an EVPN Broadcast Domain for a given tenant and TS1, TS2 and
	TS3 are connected to it. The five represented NVEs are attached to		TS3 are connected to it. The five represented NVEs are attached to
	BD1 and are connected to the same underlay IP network. That is,		BD1 and are connected to the same underlay IP network. That is,
	each NVE learns the remote NVEs' loopback addresses via underlay		each NVE learns the remote NVEs' loopback addresses via underlay
	routing protocol.		routing protocol.
	o NVE1 is deployed as a virtual switch in a Hypervisor with IP-A as		o NVE1 is deployed as a virtual switch in a Hypervisor with IP-A as
	underlay loopback IP address. The rest of the NVEs in Figure 1 are		underlay loopback IP address. The rest of the NVEs in Figure 1 are
	physical switches and TS2/TS3 are multi-homed to them. TS1 is a		physical switches and TS2/TS3 are multi-homed to them. TS1 is a
	virtual machine, identified by MAC1 and IP1.		virtual machine, identified by MAC1 and IP1. TS2 and TS3 are
			physically dual-connected to NVEs, hence they are normally not
			considered virtual machines.
	4.2.1. Auto-Discovery and Auto-Provisioning of ES, Multi-Homing PEs and		4.2.1. Auto-Discovery and Auto-Provisioning of ES, Multi-Homing PEs and
	NVE services		NVE services
	Auto-discovery is one of the basic capabilities of EVPN. The		Auto-discovery is one of the basic capabilities of EVPN. The
	provisioning of EVPN components in NVEs is significantly automated,		provisioning of EVPN components in NVEs is significantly automated,
	simplifying the deployment of services and minimizing manual		simplifying the deployment of services and minimizing manual
	operations that are prone to human error.		operations that are prone to human error.
	These are some of the Auto-Discovery and Auto-Provisioning		These are some of the Auto-Discovery and Auto-Provisioning
	skipping to change at page 20, line 7 ¶		skipping to change at page 20, line 7 ¶
	and then the TS. As an example, in Figure 1, assuming NVE4 is the		and then the TS. As an example, in Figure 1, assuming NVE4 is the
	DF for ES-2 in BD1, BUM frames sent from TS3 to NVE5 will be		DF for ES-2 in BD1, BUM frames sent from TS3 to NVE5 will be
	received at NVE4 and, since NVE4 is the DF for DB1, it will		received at NVE4 and, since NVE4 is the DF for DB1, it will
	forward them back to TS3. Split-horizon allows NVE4 (and any		forward them back to TS3. Split-horizon allows NVE4 (and any
	multi-homed NVE for that matter) to identify if an EVPN BUM frame		multi-homed NVE for that matter) to identify if an EVPN BUM frame
	is coming from the same ES or different, and if the frame belongs		is coming from the same ES or different, and if the frame belongs
	to the same ES2, NVE4 will not forward the BUM frame to TS3, in		to the same ES2, NVE4 will not forward the BUM frame to TS3, in
	spite of being the DF.		spite of being the DF.
	While [RFC7432] describes the default algorithm for the DF Election,		While [RFC7432] describes the default algorithm for the DF Election,
	[DF] and [PREF-DF] specify other algorithms and procedures that		[RFC8584] and [PREF-DF] specify other algorithms and procedures that
	optimize the DF Election.		optimize the DF Election.
	The Split-horizon function is specified in [RFC7432] and it is		The Split-horizon function is specified in [RFC7432] and it is
	carried out by using a special ESI-label that it identifies in the		carried out by using a special ESI-label that it identifies in the
	data path, all the BUM frames being originated from a given NVE and		data path, all the BUM frames being originated from a given NVE and
	ES. Since the ESI-label is an MPLS label, it cannot be used in all		ES. Since the ESI-label is an MPLS label, it cannot be used in all
	the non-MPLS NVO3 encapsulations, therefore [RFC8365] defines a		the non-MPLS NVO3 encapsulations, therefore [RFC8365] defines a
	modified Split-horizon procedure that is based on the IP SA of the		modified Split-horizon procedure that is based on the IP SA of the
	NVO3 tunnel, known as "Local-Bias". It is worth noting that Local-		NVO3 tunnel, known as "Local-Bias". It is worth noting that Local-
	Bias only works for all-active multi-homing, and not for single-		Bias only works for all-active multi-homing, and not for single-
	skipping to change at page 22, line 37 ¶		skipping to change at page 22, line 37 ¶
	6. Conventions used in this document		6. Conventions used in this document
	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 BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	7. Security Considerations		7. Security Considerations
	This section will be added in future versions.		This document does not introduce any new procedure or additional
			signaling in EVPN, and relies on the security considerations of the
			individual specifications used as a reference throughout the
			document. In particular, and as mentioned in [RFC7432], control plane
			and forwarding path protection are aspects to secure in any EVPN
			domain, when applied to NVO3 networks.
			[RFC7432] mentions security techniques such as those discussed in
			[RFC5925] to authenticate BGP messages, and those included in
			[RFC4271], [RFC4272] and [RFC6952] to secure BGP are relevant for
			EVPN in NVO3 networks as well.
	8. IANA Considerations		8. IANA Considerations
	None.		None.
	9. References		9. References
	9.1 Normative References		9.1 Normative References
	[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,		[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
	Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet		Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet
	VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <http://www.rfc-		VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <http://www.rfc-
	editor.org/info/rfc7432>.		editor.org/info/rfc7432>.
	[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.		[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
	Rekhter, "Framework for Data Center (DC) Network Virtualization",		Rekhter, "Framework for Data Center (DC) Network Virtualization",
	RFC 7365, DOI 10.17487/RFC7365, October 2014, <http://www.rfc-		RFC 7365, DOI 10.17487/RFC7365, October 2014, <http://www.rfc-
	skipping to change at page 23, line 33 ¶		skipping to change at page 23, line 40 ¶
	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		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
	RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May		RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May
	2017, <https://www.rfc-editor.org/info/rfc8174>.		2017, <https://www.rfc-editor.org/info/rfc8174>.
	9.2 Informative References		9.2 Informative References
	[IP-PREFIX] Rabadan et al., "IP Prefix Advertisement in EVPN",		[IP-PREFIX] Rabadan et al., "IP Prefix Advertisement in EVPN",
	draft-ietf-bess-evpn-prefix-advertisement-11, work in progress, May,		draft-ietf-bess-evpn-prefix-advertisement-11, work in progress, May,
	2018		2018.
	[INTER-SUBNET] Sajassi et al., "IP Inter-Subnet Forwarding in EVPN",		[INTER-SUBNET] Sajassi et al., "IP Inter-Subnet Forwarding in EVPN",
	draft-ietf-bess-evpn-inter-subnet-forwarding-05, work in progress,		draft-ietf-bess-evpn-inter-subnet-forwarding-08, work in progress,
	July, 2018		March, 2019.
	[RFC8365] Sajassi-Drake et al., "A Network Virtualization Overlay		[RFC8365] Sajassi-Drake et al., "A Network Virtualization Overlay
	Solution using EVPN", RFC 8365, March 2017, <http://www.rfc-		Solution using EVPN", RFC 8365, March 2017, <http://www.rfc-
	editor.org/info/rfc8365>		editor.org/info/rfc8365>.
	[GENEVE] Gross et al., "Geneve: Generic Network Virtualization		[GENEVE] Gross et al., "Geneve: Generic Network Virtualization
	Encapsulation", draft-ietf-nvo3-geneve-08, work in progress, October		Encapsulation", draft-ietf-nvo3-geneve-13, work in progress, March
	2018		2019.
	[NVO3-ENCAP] Boutros et al., "NVO3 Encapsulation Considerations",		[NVO3-ENCAP] Boutros et al., "NVO3 Encapsulation Considerations",
	draft-ietf-nvo3-encap-02, work in progress, September 2018		draft-ietf-nvo3-encap-03, work in progress, July 2019.
	[TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation		[TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation
	Attribute", draft-ietf-idr-tunnel-encaps-10, work in progress, August		Attribute", draft-ietf-idr-tunnel-encaps-12, work in progress, May
	2018		2019.
	[EVPN-LSP-PING] Jain et al., "LSP-Ping Mechanisms for EVPN and PBB-		[EVPN-LSP-PING] Jain et al., "LSP-Ping Mechanisms for EVPN and PBB-
	EVPN", draft-jain-bess-evpn-lsp-ping-07, work in progress, June 2018		EVPN", draft-ietf-bess-evpn-lsp-ping-00, work in progress, May 2019.
	[LOOP] Rabadan et al., "Loop Protection in EVPN networks", draft-		[LOOP] Rabadan et al., "Loop Protection in EVPN networks", draft-
	snr-bess-evpn-loop-protect-02, work in progress, August 2018		snr-bess-evpn-loop-protect-02, work in progress, August 2018.
	[PROXY-ARP-ND] Rabadan et al., "Operational Aspects of Proxy-ARP/ND		[PROXY-ARP-ND] Rabadan et al., "Operational Aspects of Proxy-ARP/ND
	in EVPN Networks", draft-ietf-bess-evpn-proxy-arp-nd-05, work in		in EVPN Networks", draft-ietf-bess-evpn-proxy-arp-nd-07, work in
	progress, October 2018		progress, July 2019.
	[IGMP-MLD-PROXY] Sajassi et al., "IGMP and MLD Proxy for EVPN",		[IGMP-MLD-PROXY] Sajassi et al., "IGMP and MLD Proxy for EVPN",
	draft-ietf-bess-evpn-igmp-mld-proxy-02, work in progress, June 2018		draft-ietf-bess-evpn-igmp-mld-proxy-03, work in progress, June 2019.
	[PIM-PROXY] Rabadan et al., "PIM Proxy in EVPN Networks", draft-skr-		[PIM-PROXY] Rabadan et al., "PIM Proxy in EVPN Networks", draft-skr-
	bess-evpn-pim-proxy-01, work in progress, October 2017		bess-evpn-pim-proxy-01, work in progress, October 2017.
	[OPT-IR] Rabadan et al., "Optimized Ingress Replication solution for		[OPT-IR] Rabadan et al., "Optimized Ingress Replication solution for
	EVPN", draft-ietf-bess-evpn-optimized-ir-06, work in progress,		EVPN", draft-ietf-bess-evpn-optimized-ir-06, work in progress,
	October 2018		October 2018.
	[DF] Rabadan-Mohanty et al., "Framework for EVPN Designated		[RFC8584] Rabadan-Mohanty et al., "Framework for EVPN Designated
	Forwarder Election Extensibility", draft-ietf-bess-evpn-df-election-		Forwarder Election Extensibility", <https://rfc-
	04, work in progress, October 2018		editor.org/rfc/rfc8584.txt>, April 2019.
	[PREF-DF] Rabadan et al., "Preference-based EVPN DF Election",		[PREF-DF] Rabadan et al., "Preference-based EVPN DF Election",
	draft-ietf-bess-evpn-pref-df-02, work in progress, October 2018		draft-ietf-bess-evpn-pref-df-04, work in progress, June 2019.
	[OISM] Lin at al., "EVPN Optimized Inter-Subnet Multicast (OISM)		[OISM] Lin at al., "EVPN Optimized Inter-Subnet Multicast (OISM)
	Forwarding", draft-ietf-bess-evpn-irb-mcast-01, work in progress,		Forwarding", draft-ietf-bess-evpn-irb-mcast-02, work in progress,
	July 2018		January 2019.
	[EVPN-DCI] Rabadan et al., "Interconnect Solution for EVPN Overlay		[EVPN-DCI] Rabadan et al., "Interconnect Solution for EVPN Overlay
	networks", draft-ietf-bess-dci-evpn-overlay-10, work in progress,		networks", draft-ietf-bess-dci-evpn-overlay-10, work in progress,
	March 2018		March 2018.
	[BUM-UPDATE] Zhang et al., "Updates on EVPN BUM Procedures", draft-		[BUM-UPDATE] Zhang et al., "Updates on EVPN BUM Procedures", draft-
	ietf-bess-evpn-bum-procedure-updates-04, work in progress, June 2018		ietf-bess-evpn-bum-procedure-updates-06, work in progress, June 2019.
	[EVPN-IPVPN] Rabadan-Sajassi et al., "EVPN Interworking with IPVPN",		[EVPN-IPVPN] Rabadan-Sajassi et al., "EVPN Interworking with IPVPN",
	draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-01, work in		draft-ietf-sajassi-bess-evpn-ipvpn-interworking-01, work in progress,
	progress, July 2018		March 2019.
	[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,		[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
	L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible		L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible
	Local Area Network (VXLAN): A Framework for Overlaying Virtualized		Local Area Network (VXLAN): A Framework for Overlaying Virtualized
	Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI		Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI
	10.17487/RFC7348, August 2014, <http://www.rfc-		10.17487/RFC7348, August 2014, <http://www.rfc-
	editor.org/info/rfc7348>.		editor.org/info/rfc7348>.
	[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,		[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
	"Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April		"Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April
	skipping to change at page 25, line 22 ¶		skipping to change at page 25, line 29 ¶
	[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private		[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
	Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006,		Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006,
	<http://www.rfc-editor.org/info/rfc4364>.		<http://www.rfc-editor.org/info/rfc4364>.
	[CLOS1953] Clos, C., "A Study of Non-Blocking Switching Networks",		[CLOS1953] Clos, C., "A Study of Non-Blocking Switching Networks",
	The Bell System Technical Journal, Vol. 32(2), DOI 10.1002/j.1538-		The Bell System Technical Journal, Vol. 32(2), DOI 10.1002/j.1538-
	7305.1953.tb01433.x, March 1953.		7305.1953.tb01433.x, March 1953.
	[EVPN-GENEVE] Boutros et al., "EVPN control plane for Geneve",		[EVPN-GENEVE] Boutros et al., "EVPN control plane for Geneve",
	draft-boutros-bess-evpn-geneve-03, work in progress, September 2018.		draft-boutros-bess-evpn-geneve-04, work in progress, March 2019.
	[EVPN-MVPN] Sajassi et al., "Seamless Multicast Interoperability		[EVPN-MVPN] Sajassi et al., "Seamless Multicast Interoperability
	between EVPN and MVPN PEs", draft-sajassi-bess-evpn-mvpn-seamless-		between EVPN and MVPN PEs", draft-sajassi-bess-evpn-mvpn-seamless-
	interop-02, work in progress, July 2018.		interop-04, work in progress, July 2019.
			[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
			Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010,
			<https://www.rfc-editor.org/info/rfc5925>.
			[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
			Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271,
			January 2006, <https://www.rfc-editor.org/info/rfc4271>.
			[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
			4272, DOI 10.17487/RFC4272, January 2006, <https://www.rfc-
			editor.org/info/rfc4272>.
			[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
			BGP, LDP, PCEP, and MSDP Issues According to the Keying and
			Authentication for Routing Protocols (KARP) Design Guide", RFC 6952,
			DOI 10.17487/RFC6952, May 2013, <https://www.rfc-
			editor.org/info/rfc6952>.
	10. Acknowledgments		10. Acknowledgments
	The authors want to thank Aldrin Isaac for his comments.		The authors want to thank Aldrin Isaac for his comments.
	11. Contributors		11. Contributors
	12. Authors' Addresses		12. Authors' Addresses
	Jorge Rabadan (Editor)		Jorge Rabadan (Editor)
	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
	Sami Boutros		Sami Boutros
	VMware		VMware
	Email: sboutros@vmware.com		Email: boutross@vmware.com
	Matthew Bocci		Matthew Bocci
	Nokia		Nokia
	Email: matthew.bocci@nokia.com		Email: matthew.bocci@nokia.com
	Ali Sajassi		Ali Sajassi
	Cisco		Cisco
	Email: sajassi@cisco.com		Email: sajassi@cisco.com
End of changes. 36 change blocks.
	46 lines changed or deleted		86 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/