draft-ietf-bess-evpn-vpls-seamless-integ-01.txt		draft-ietf-bess-evpn-vpls-seamless-integ-02.txt
	skipping to change at page 1, line 13 ¶		skipping to change at page 1, line 13 ¶
	INTERNET-DRAFT Ali Sajassi		INTERNET-DRAFT Ali Sajassi
	Intended Status: Standard Track Samer Salam		Intended Status: Standard Track Samer Salam
	Cisco		Cisco
	Nick Del Regno		Nick Del Regno
	Verizon		Verizon
	Jorge Rabadan		Jorge Rabadan
	Alcatel-Lucent		Alcatel-Lucent
	Expires: August 15, 2018 February 15, 2018		Expires: September 29, 2018 March 29, 2018
	(PBB-)EVPN Seamless Integration with (PBB-)VPLS		(PBB-)EVPN Seamless Integration with (PBB-)VPLS
	draft-ietf-bess-evpn-vpls-seamless-integ-01		draft-ietf-bess-evpn-vpls-seamless-integ-02
	Abstract		Abstract
	This draft discusses the backward compatibility of the (PBB-)EVPN		This draft specifies procedures for backward compatibility of the
	solution with (PBB-)VPLS and provides mechanisms for seamless		(PBB-)EVPN solution with (PBB-)VPLS and provides mechanisms for
	integration of the two technologies in the same MPLS/IP network on a		seamless integration of the two technologies in the same MPLS/IP
	per-VPN-instance basis.		network on a per-VPN-instance basis. Implementation of this draft
			enables service providers to introduce (PBB-)EVPN PEs in their
			brownfield deployments of (PBB-)VPLS networks.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF 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		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	skipping to change at page 2, line 19 ¶		skipping to change at page 2, line 22 ¶
	(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 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Specification of Requirements . . . . . . . . . . . . . . 4
	2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 5
	3 PBB-VPLS Integration with PBB-EVPN . . . . . . . . . . . . . . . 4		2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 4		3 PBB-VPLS Integration with PBB-EVPN . . . . . . . . . . . . . . . 7
	3.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 5		3.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 7
	3.3 Multicast Operation . . . . . . . . . . . . . . . . . . . . 6		3.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 7
	3.3.1 Ingress Replication . . . . . . . . . . . . . . . . . . 6		3.3 Multicast Operation . . . . . . . . . . . . . . . . . . . . 8
	3.3.2 LSM . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.3.1 Ingress Replication . . . . . . . . . . . . . . . . . . 8
	4 VPLS Integration with EVPN . . . . . . . . . . . . . . . . . . . 7		3.3.2 P2MP Tunnel . . . . . . . . . . . . . . . . . . . . . . 9
	4.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 7		4 VPLS Integration with EVPN . . . . . . . . . . . . . . . . . . . 9
	4.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 7		4.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 9
	4.3 Multicast Operation . . . . . . . . . . . . . . . . . . . . 7		4.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 9
	4.3.1 Ingress Replication . . . . . . . . . . . . . . . . . . 7		4.2.1 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . 9
	4.3.2 LSM . . . . . . . . . . . . . . . . . . . . . . . . . . 7		4.3 Multicast Operation . . . . . . . . . . . . . . . . . . . . 10
	5 VPLS Integration with PBB-EVPN . . . . . . . . . . . . . . . . . 7		4.3.1 Ingress Replication . . . . . . . . . . . . . . . . . . 10
	5.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 7		4.3.2 P2MP Tunnel - Inclusive Tree . . . . . . . . . . . . . . 10
	5.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 7		5 VPLS Integration with PBB-EVPN . . . . . . . . . . . . . . . . . 10
	5.3 Multicast Operation . . . . . . . . . . . . . . . . . . . . 8		5.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 10
	5.3.1 Ingress Replication . . . . . . . . . . . . . . . . . . 8		5.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 11
	5.3.2 LSM . . . . . . . . . . . . . . . . . . . . . . . . . . 8		5.3 Multicast Operation . . . . . . . . . . . . . . . . . . . . 11
	6 Solution Advantages . . . . . . . . . . . . . . . . . . . . . . 8		5.3.1 Ingress Replication . . . . . . . . . . . . . . . . . . 11
	7 Security Considerations . . . . . . . . . . . . . . . . . . . . 8		5.3.2 P2MP Tunnel - Inclusive Tree . . . . . . . . . . . . . . 11
	8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8		6 Solution Advantages . . . . . . . . . . . . . . . . . . . . . . 11
	9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		7 Security Considerations . . . . . . . . . . . . . . . . . . . . 11
	9.1 Normative References . . . . . . . . . . . . . . . . . . . 8		8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12
	9.2 Informative References . . . . . . . . . . . . . . . . . . 9		9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9		9.1 Normative References . . . . . . . . . . . . . . . . . . . 12
			9.2 Informative References . . . . . . . . . . . . . . . . . . 12
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	1 Introduction		1 Introduction
	VPLS and PBB-VPLS are widely-deployed L2VPN technologies. Many SPs		VPLS and PBB-VPLS are widely-deployed L2VPN technologies. Many
	who are looking at adopting EVPN and PBB-EVPN want to preserve their		Service Providers (SPs) who are looking at adopting EVPN and PBB-EVPN
	investment in the (PBB-)VPLS networks. Hence, it is required to		want to preserve their investment in the (PBB-)VPLS networks. Hence,
	provide mechanisms by which (PBB-)EVPN technology can be introduced		they require procedures by which (PBB-)EVPN technology can be
	into existing L2VPN networks without requiring a fork-lift upgrade.		introduced into their brownfield (PBB-)VPLS networks without
	This document discusses mechanisms for the seamless integration of		requiring any upgrades (software or hardware) to these networks. This
	the two technologies in the same MPLS/IP network.		document specifies procedures for the seamless integration of the two
			technologies in the same MPLS/IP network.
	VPLS PE		VPLS PE
	+---+		+---+
	|PE1|		|PE1|
	+---+		+---+
	/		/
	EVPN/VPLS PE +---------------+ EVPN/VPLS PE		EVPN/VPLS PE +---------------+ EVPN/VPLS PE
	+---+ | | +---+		+---+ | | +---+
	|PE4|----| MPLS/IP |---|PE5|		|PE4|----| MPLS/IP |---|PE5|
	+---+ | Core | +---+		+---+ | Core | +---+
	skipping to change at page 3, line 35 ¶		skipping to change at page 4, line 36 ¶
	+---------------+		+---------------+
	/ \		/ \
	+---+ +---+		+---+ +---+
	|PE2| |PE3|		|PE2| |PE3|
	+---+ +---+		+---+ +---+
	VPLS PE VPLS PE		VPLS PE VPLS PE
	Figure 1: Seamless Integration of (PBB-)EVPN PEs & (PBB-)VPLS		Figure 1: Seamless Integration of (PBB-)EVPN PEs & (PBB-)VPLS
	Section 2 provides the details of the requirements. Section 3		Section 2 provides the details of the requirements. Section 3
	discusses PBB-VPLS integration with PBB-EVPN. Section 4 discusses the		specifies procedures for the seamless integration of PBB-VPLS and
	integration of VPLS and EVPN. Section 5 discusses the integration of		PBB-EVPN networks. Section 4 specifies procedures for the seamless
	VPLS and PBB-EVPN, and finally Section 6 discusses the solution		integration of VPLS and EVPN networks. Section 5 specifies procedures
	advantages.		for the seamless integration of VPLS and PBB-EVPN networks, and
			finally Section 6 discusses the solution advantages.
	It is worth noting that the scenario where PBB-VPLS is integrated		It is worth noting that the scenario where PBB-VPLS is integrated
	with EVPN, is for future study and upon market validation. The reason		with EVPN, is not covered in this draft because there hasn't been any
			requirement from service providers for such integration. The reason
	for that is that deployments which employ PBB-VPLS typically require		for that is that deployments which employ PBB-VPLS typically require
	PBB encapsulation for various reasons. Hence, it is expected that for		PBB encapsulation for various reasons. Hence, it is expected that for
	those deployments the evolution path would be from PBB-VPLS towards		those deployments the evolution path would be from PBB-VPLS towards
	PBB-EVPN, rather than EVPN.		PBB-EVPN, rather than EVPN.
	1.1 Terminology		1.1. Specification of Requirements
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in RFC 2119 [KEYWORDS].		"OPTIONAL" in this document are to be interpreted as described in BCP
			14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
			1.2. Terms and Abbreviations
			B-MAC: Backbone MAC
			B-VID: Backbone VLAN ID
			Broadcast Domain: In a bridged network, the broadcast domain
			corresponds to a Virtual LAN (VLAN), where a VLAN is typically
			represented by a single VLAN ID (VID) but can be represented by
			several VIDs where Shared VLAN Learning (SVL) is used per
			[IEEE.802.1ah].
			Bridge Table: An instantiation of a broadcast domain on a MAC-VRF.
			CE: A Customer Edge device, e.g., a host, router, or switch.
			EVI: An EVPN Instance spanning the Provider Edge (PE) devices
			participating in that EVPN.
			MAC-VRF: A Virtual Routing and Forwarding table for Media Access
			Control (MAC) addresses on an EVPN PE.
			MAC address: Media Access Control address
			ES: When a customer site (device or network) is connected to one or
			more PEs via a set of Ethernet links, then that set of links is
			referred to as an "Ethernet Segment".
			ESI: An Ethernet Segment Identifier is a unique non-zero identifier
			that identifies an ES
			Ethernet Tag: An Ethernet Tag identifies a particular broadcast
			domain, e.g., a VLAN. An EVPN instance consists of one or more
			broadcast domains
			P2MP: Point-to-Multipoint
			PBB: Provider Backbone Bridge
			PE: Provider Edge device
			VSI: Virtual Switch Instance
			VPLS: Virtual Private LAN Service
			Single-Active Redundancy Mode: When only a single PE, among all the
			PEs attached to an Ethernet segment, is allowed to forward traffic
			to/from that Ethernet segment for a given VLAN, then the Ethernet
			segment is defined to be operating in Single-Active redundancy mode.
			All-Active Redundancy Mode: When all PEs attached to an Ethernet
			segment are allowed to forward known unicast traffic to/from that
			Ethernet segment for a given VLAN, then the Ethernet segment is
			defined to be operating in All-Active redundancy mode.
	2. Requirements		2. Requirements
	Following are the key requirements for backward compatibility between		Following are the key requirements for backward compatibility between
	(PBB-)EVPN and (PBB-)VPLS:		(PBB-)EVPN and (PBB-)VPLS:
	1. The solution MUST allow for staged migration towards (PBB-)EVPN on		1. The solution MUST allow for staged migration towards (PBB-)EVPN on
	a site-by-site basis per VPN instance - e.g., new EVPN sites to be		a site-by-site basis per VPN instance - e.g., new EVPN sites to be
	provisioned on (PBB-)EVPN PEs.		provisioned on (PBB-)EVPN PEs.
	2. The solution MUST require no changes to existing VPLS or PBB-VPLS		2. The solution MUST require no changes to existing VPLS or PBB-VPLS
	PEs, not even a software upgrade.		PEs, not even a software upgrade.
	3. The solution MUST allow for the coexistence of PE nodes running		3. The solution MUST allow for the coexistence of PEs running (PBB-
	(PBB-)EVPN and (PBB-)VPLS for the same VPN instance and single-homed		)EVPN and (PBB-)VPLS for the same VPN instance and single-homed
	segments.		segments.
	4. The solution MUST support single-active redundancy of multi-homed		4. The solution MUST support single-active redundancy of multi-homed
	networks and multi-homed devices for (PBB-)EVPN PEs.		networks and multi-homed devices for (PBB-)EVPN PEs.
	5. In case of single-active redundancy, the participant VPN instances		5. In case of single-active redundancy, the participant VPN instances
	MAY span across both (PBB-)EVPN PEs and (PBB-)VPLS PEs as long as		MAY span across both (PBB-)EVPN PEs and (PBB-)VPLS PEs as long as
	single-active redundancy is employed by (PBB-)EVPN PEs. In case of an		single-active redundancy is employed by (PBB-)EVPN PEs. In case of an
	ES link failure, the (PBB-)EVPN PEs will send a BGP mass-withdraw to		ES link failure, the (PBB-)EVPN PEs will send a BGP mass-withdraw to
	the EVPN peers OR MAC advertisement with MAC Mobility extended		the EVPN peers OR MAC advertisement with MAC Mobility extended
	community for PBB-EVPN AND an LDP MAC withdrawal to the VPLS peers.		community for PBB-EVPN AND an LDP MAC withdrawal to the VPLS peers.
	6. The solution SHOULD support all-active redundancy of multi-homed		6. The solution SHOULD support All-Active redundancy mode of multi-
	networks and multi-homed devices for (PBB-)EVPN PEs.		homed networks and multi-homed devices for (PBB-)EVPN PEs. In case of
			All-Active redundancy mode, the participant VPN instances SHOULD be
	7. In case of all-active redundancy, the participant VPN instances		confined to (PBB-)EVPN PEs only.
	SHOULD be confined to (PBB-)EVPN PEs only.
	These requirements collectively allow for the seamless insertion of		These requirements collectively allow for the seamless insertion of
	the (PBB-)EVPN technology into brown-field (PBB-)VPLS deployments.		the (PBB-)EVPN technology into brown-field (PBB-)VPLS deployments.
	3 PBB-VPLS Integration with PBB-EVPN		3 PBB-VPLS Integration with PBB-EVPN
	In order to support seamless integration with (PBB-)VPLS, the (PBB-		In order to support seamless integration with (PBB-)VPLS PEs, the
	)EVPN PEs MUST support EVPN BGP routes (EVPN SAFI) and SHOULD support		(PBB-)EVPN PEs MUST support EVPN BGP routes (EVPN SAFI) and VPLS AD
	VPLS AD route (VPLS SAFI). All the logic for the integration will		route (VPLS SAFI). All the logic for this seamless integration SHALL
	reside on the (PBB-)EVPN PEs side. However, if a VPLS instance is		reside on the (PBB-)EVPN PEs. However, if a VPLS instance is setup
	setup without the use of BGP auto-discovery, it is still possible		without the use of BGP auto-discovery, it is still possible (but
	(but cumbersome) for (PBB-)EVPN PEs to integrate into that VPLS		cumbersome) for (PBB-)EVPN PEs to integrate into that VPLS instance.
	instance.
	3.1 Capability Discovery		3.1 Capability Discovery
	The (PBB-)EVPN PEs must advertise both the BGP VPLS auto-discovery
			The (PBB-)EVPN PEs MUST advertise both the BGP VPLS auto-discovery
	(AD) route as well as the BGP EVPN Inclusive Multicast route for a		(AD) route as well as the BGP EVPN Inclusive Multicast route for a
	given VPN instance. The (PBB-)VPLS PEs only advertise the BGP VPLS AD		given VPN instance. The (PBB-)VPLS PEs only advertise the BGP VPLS AD
	route, per current standard procedures specified in [RFC4761] and		route, per current standard procedures specified in [RFC4761] and
	[RFC6074]. The operator may decide to use the same BGP RT for both		[RFC6074]. The operator may decide to use the same BGP RT to identify
	(PBB-)EVPN and (PBB-)VPLS. In this case, when a (PBB-)VPLS PE		a VPN on both (PBB-)EVPN and (PBB-)VPLS networks. In this case, when
	receives the EVPN Inclusive Multicast route, it will ignore it on the		a (PBB-)VPLS PE receives the EVPN Inclusive Multicast route, it will
	basis that it belongs to an unknown SAFI. However, the operator may		ignore it on the basis that it belongs to an unknown SAFI. However,
	use two RTs (one for (PBB-)VPLS and another for (PBB-)EVPN) and		the operator may choose to use two RTs - one to identify the VPN on
	employ RT-constraint in order to prevent EVPN BGP routes from		(PBB-)VPLS network and another for (PBB-)EVPN network and employ RT-
	reaching the (PBB-)VPLS PEs. This provides an optimization in case		constraint in order to prevent EVPN BGP routes from reaching the
	required by the scale of the network.		(PBB-)VPLS PEs.
	When a (PBB-)EVPN PE receives both a VPLS AD route as well as an EVPN		When a (PBB-)EVPN PE receives both a VPLS AD route as well as an EVPN
	Inclusive Multicast route from a given remote PE for the same VPN		Inclusive Multicast route from a given remote PE for the same VPN
	instance, it MUST give preference to the EVPN route for the purpose		instance, it MUST give preference to the EVPN route for the purpose
	of discovery. This ensures that, at the end of the route exchanges,		of discovery. This ensures that, at the end of the route exchanges,
	all (PBB-)EVPN capable PEs discover other (PBB-)EVPN capable PEs as		all (PBB-)EVPN capable PEs discover other (PBB-)EVPN capable PEs in
	well as the (PBB-)VPLS-only PEs for that VPN instance. Furthermore,		addition to the (PBB-)VPLS-only PEs for that VPN instance.
	all the (PBB-)VPLS-only PEs would discover the (PBB-)EVPN PEs as if		Furthermore, all the (PBB-)VPLS-only PEs would discover the (PBB-
	they were standard (PBB-)VPLS nodes. In other words, when the		)EVPN PEs as if they were standard (PBB-)VPLS PEs. In other words,
	discovery phase is complete, the (PBB-)EVPN PEs would have discovered		when the discovery phase is complete, the (PBB-)EVPN PEs would have
	all the PEs in the VPN instance, and their associated capability:		discovered all the PEs in the VPN instance along with their
	(PBB-)EVPN or VPLS-only. Whereas the (PBB-)VPLS PEs would have		associated capability: (PBB-)EVPN or VPLS-only. Whereas the (PBB-
	discovered all the PEs in the VPN instance, as if they were all VPLS-		)VPLS PEs would have discovered all the PEs in the VPN instance, as
	only nodes.		if they were all VPLS-only PEs.
	3.2 Forwarding Setup and Unicast Operation		3.2 Forwarding Setup and Unicast Operation
	The procedures for forwarding setup and unicast operation on the		The procedures for forwarding setup and unicast operation on the
	(PBB-)VPLS PE are per [RFC8077] and [RFC7080].		(PBB-)VPLS PE are per [RFC8077] and [RFC7080].
	The procedures for forwarding state setup and unicast operation on		The procedures for forwarding state setup and unicast operation on
	the (PBB-)EVPN PE are as follows:		the (PBB-)EVPN PE are as follows:
	- The (PBB-)EVPN PE must establish a pseudowire to a remote PE from		- The (PBB-)EVPN PE MUST establish a pseudowire to a remote PE from
	which it has received only a VPLS AD route, for the VPN instance in		which it has received only a VPLS AD route for the corresponding VPN
	question, and set up the label stack corresponding to the pseudowire		instance, and MUST set up the label stack corresponding to the
	FEC. This PW is between B-components of PBB-EVPN PE and PBB-VPLS PE		pseudowire FEC. For seamless integration between PBB-EVPN and PBB-
	per section 4 of [RFC7041].		VPLS PEs, this PW is between B-components of PBB-EVPN PE and PBB-VPLS
			PE per section 4 of [RFC7041].
	- The (PBB-)EVPN PE must set up the label stack corresponding to the		- The (PBB-)EVPN PE must set up the label stack corresponding to the
	MP2P (PBB-)VPN unicast FEC to any remote PE that has advertised EVPN		MP2P VPN unicast FEC to any remote PE that has advertised EVPN AD
	AD route.		route.
	- If a (PBB-)EVPN PE receives a VPLS AD route followed by an EVPN AD		- If a (PBB-)EVPN PE receives a VPLS AD route followed by an EVPN AD
	route from the same PE and a pseudowire is setup to that PE, then the		route from the same PE and a pseudowire is setup to that PE, then the
	(PBB-)EVPN MUST bring that pseudowire operationally down.		(PBB-)EVPN MUST bring that pseudowire operationally down.
	- If a (PBB-)EVPN PE receives an EVPN AD route followed by a VPLS AD		- If a (PBB-)EVPN PE receives an EVPN AD route followed by a VPLS AD
	route from the same PE, then the (PBB-)EVPN PE will setup the		route from the same PE, then the (PBB-)EVPN PE will setup the
	pseudowire but MUST keep it operationally down.		pseudowire but MUST keep it operationally down.
	When the (PBB-)EVPN PE receives traffic over the pseudowires, it		When the (PBB-)EVPN PE receives traffic over the pseudowires, it
	learns the associated MAC addresses in the data-plane. This is		learns the associated MAC addresses in the data-plane. This is
	analogous to dynamic learning in IEEE bridges. If the PW belongs to		analogous to dynamic learning in IEEE bridges. The MAC addresses
	the same split-horizon group as the EVPN mesh, then the MAC addresses		learned over PWs are not injected into (PBB-)EVPN MAC-VRF tables but
	learnt and associated to the PW will NOT be advertised in the control		rather they are injected into their corresponding (PBB-)VPLS VSI
	plane to any remote (PBB-)EVPN PE. The (PBB-)EVPN PE learns MAC		table. If the core-facing PW belongs to the same split-horizon group
	addresses in the control plane, via the EVPN MAC Advertisement routes		as the core-facing MP2P EVPN service tunnels, then the MAC addresses
	sent by remote (PBB-)EVPN PEs, and updates its MAC forwarding table		learned and associated to the PW will NOT be advertised in the
	accordingly. This is analogous to static learning in IEEE bridges. In		control plane to any remote (PBB-)EVPN PE. This is because every
	PBB-EVPN, a given B-MAC address can be learnt either over the BGP		(PBB-)EVPN PE can send and receive traffic directly to/from every
	control-plane from a remote PBB-EVPN PE, or in the data-plane over a		(PBB-)VPLS PE belonging to the same VPN instance.
	pseudowire from a remote PBB-VPLS PE. There is no mobility associated
	with B-MAC addresses in this context. Hence, when the same B-MAC		The MAC addresses learned over local Attachment Circuits (ACs) by a
	address shows up behind both a remote PBB-VPLS PE as well as a PBB-		(PBB-)EVPN PE are advertised in control plane using BGP EVPN routes
	EVPN PE, the local PE can deduce that there is an anomaly in the		to other (PBB-)EVPN PEs. Furthermore, the MAC addresses learned in
	network.		the control plane, via the BGP EVPN routes sent by remote (PBB-)EVPN
			PEs, are injected into the corresponding MAC-VRF table. This is
			analogous to static learning in IEEE bridges. In PBB-EVPN, a given B-
			MAC address can be learnt either over the BGP control-plane from a
			remote PBB-EVPN PE, or in the data-plane over a pseudowire from a
			remote PBB-VPLS PE. There is no mobility associated with B-MAC
			addresses in this context. Hence, when the same B-MAC address shows
			up behind both a remote PBB-VPLS PE as well as a PBB-EVPN PE, the
			local PE can deduce that it is an anomaly and notify the operator.
	3.3 Multicast Operation		3.3 Multicast Operation
	3.3.1 Ingress Replication The procedures for multicast operation on the		3.3.1 Ingress Replication The procedures for multicast operation on the
	(PBB-)VPLS PE, using ingress replication, are per [RFC4761],		(PBB-)VPLS PE, using ingress replication, are per [RFC4761],
	[RFC4762], and [RFC7080].		[RFC4762], and [RFC7080].
	The procedures for multicast operation on the PBB-EVPN PE, for		The procedures for multicast operation on the PBB-EVPN PE, for
	ingress replication, are as follows:		ingress replication, are as follows:
	- The PBB-EVPN PE builds a replication sub-list per I-SID to all the		- The PBB-EVPN PE builds a replication sub-list per I-SID to all the
	remote PBB-EVPN PEs in a given VPN instance, as a result of the		remote PBB-EVPN PEs in a given VPN instance, as a result of the
	exchange of the EVPN Inclusive multicast routes, as described in		exchange of the EVPN Inclusive multicast routes, as described in
	[RFC7623]. This will be referred to as sub-list A. It comprises MP2P		[RFC7623]. This will be referred to as sub-list A. It comprises MP2P
	tunnels used for delivering PBB-EVPN BUM traffic [RFC7432].		service tunnels used for delivering PBB-EVPN BUM traffic [RFC7432].
	- The PBB-EVPN PE builds a replication sub-list per VPN instance to		- The PBB-EVPN PE builds a replication sub-list per VPN instance to
	all the remote PBB-VPLS PEs , as a result of the exchange of the VPLS		all the remote PBB-VPLS PEs , as a result of the exchange of the VPLS
	AD routes. This will be referred to as sub-list B. It comprises		AD routes. This will be referred to as sub-list B. It comprises
	pseudowires from the PBB-EVPN PE in question to all the remote PBB-		pseudowires from the PBB-EVPN PE in question to all the remote PBB-
	VPLS PEs in the same VPN instance.		VPLS PEs in the same VPN instance.
	- The PBB-EVPN PE may further prune sub-list B, on a per I-SID basis,		- The PBB-EVPN PE may further prune sub-list B, on a per I-SID basis,
	if [MMRP] is run over the PBB-VPLS network. This will be referred to		if [MMRP] is run over the PBB-VPLS network. This will be referred to
	as sub-list C. This list comprises a pruned set of the pseudowires in		as sub-list C. This list comprises a pruned set of the pseudowires in
	sub-list B.		sub-list B.
	The replication list, maintained per I-SID, on a given PBB-EVPN PE		The replication list, maintained per I-SID, on a given PBB-EVPN PE
	will be the union of sub-list A and sub-list B if [MMRP] is NOT used,		will be the union of sub-list A and sub-list B if [MMRP] is NOT used,
	and the union of sub-list A and sub-list C if [MMRP] is used. Note		and the union of sub-list A and sub-list C if [MMRP] is used. Note
	that the PE must enable split-horizon over all the entries in the		that the PE must enable split-horizon over all the entries in the
	replication list, across both pseudowires and MP2P tunnels.		replication list, across both pseudowires and MP2P service tunnels.
	3.3.2 LSM Will be covered in a future revision of this document.		3.3.2 P2MP Tunnel The procedures for multicast operation on the PBB-EVPN
			PEs using P2MP tunnels are outside of the scope of this document.
	4 VPLS Integration with EVPN		4 VPLS Integration with EVPN
	4.1 Capability Discovery		4.1 Capability Discovery
	The procedures for capability discovery are per Section 3.1 above.		The procedures for capability discovery are per Section 3.1 above.
	4.2 Forwarding Setup and Unicast Operation		4.2 Forwarding Setup and Unicast Operation
	The operation here is largely similar to that of PBB-EVPN integration		The operation here is largely similar to that of PBB-EVPN integration
	with PBB-VPLS, with the exception of the need to handle MAC mobility,		with PBB-VPLS, with one major exception in handling MAC mobility that
	the details of which will be covered in a future revision of this		is described in the next section.
	document.
			- For seamless integration among EVPN and VPLS PEs, the PW that is
			setup between a pair of VPLS and EVPN PEs is between VSI of VPLS PE
			and MAC-VRF of EVPN PE.
			4.2.1 MAC Mobility
			Contrary to PBB-EVPN, where the association between a B-MAC and a
			PBB-EVPN PE is fixed and thus there is no B-MAC mobility, in EVPN,
			host addresses (C-MAC addresses) can move around among EVPN PEs or
			even between EVPN and VPLS PEs.
			When a MAC address moves from an EVPN PE to a VPLS PE, then as soon
			as BUM traffic is initiated from that MAC address, it is flooded to
			all other PEs (both VPLS and EVPN PEs) and the receiving PEs update
			their MAC tables (VSI or MAC-VRF). The EVPN PEs do not advertise the
			MAC address learned over PW to each other because every EVPN PE
			learns it directly over its associated PW to that VPLS PE. If only
			known-unicast traffic is initiated from the moved MAC address toward
			a known MAC, then this can result in black-holing of traffic destined
			to the MAC that has moved until the MAC age-out timer expires but
			this is the typical behavior of VPLS PEs.
			When a host MAC address moves from a VPLS PE to an EVPN PE, then as
			soon as BUM or known-unicast traffic is initiated from that MAC
			address, the MAC is learned and advertised in BGP to other EVPN PEs
			and MAC mobility procedure is exercised among EVPN PEs. For BUM
			traffic, both EVPN and VPLS PES learn the new location of the moved
			MAC address; however, if there is only known-unicast traffic, then
			only EVPN PEs learn the new location of the MAC that has moved but
			not VPLS PEs. This can result in black-holing of traffic sent from
			VPLS PEs destined to the MAC that has moved until the MAC age-out
			timer expires but this is the typical behavior of VPLS PEs.
	4.3 Multicast Operation		4.3 Multicast Operation
	4.3.1 Ingress Replication		4.3.1 Ingress Replication
	The operation is per the procedures of Section 3.3.1 above for the		The operation is per the procedures of Section 3.3.1 above for the
	scenario WITHOUT [MMRP]. The replication list is maintained per VPN		scenario WITHOUT [MMRP]. The replication list is maintained per VPN
	instance, rather than per I-SID.		instance rather than per I-SID.
	4.3.2 LSM Will be covered in a future revision of this document.		4.3.2 P2MP Tunnel - Inclusive Tree
			The procedures for multicast operation on the EVPN PEs using P2MP
			tunnels are outside of the scope of this document.
	5 VPLS Integration with PBB-EVPN		5 VPLS Integration with PBB-EVPN
	5.1 Capability Discovery		5.1 Capability Discovery
	The procedures for capability discovery are per Section 3.1 above.		The procedures for capability discovery are per Section 3.1 above.
	5.2 Forwarding Setup and Unicast Operation		5.2 Forwarding Setup and Unicast Operation
	The operation here is largely similar to that of PBB-EVPN integration		The operation here is largely similar to that of PBB-EVPN integration
	with PBB-VPLS, with a few exceptions listed below:		with PBB-VPLS, with a few exceptions listed below:
	- When a PW is setup between a PBB-EVPN PE and a VPLS PE, it gets		- When a PW is setup between a PBB-EVPN PE and a VPLS PE, it gets
	setup between the I-component of PBB-EVPN PE and the bridge component		setup between the I-component of PBB-EVPN PE and the VSI of VPLS PE.
	of VPLS PE.
	- The MAC mobility needs to be handled. The details of which will be		- The MAC mobility aspect is the same as that of VPLS network or PBB-
	covered in a future revision of this document.		VPLS network since in both cases the host MAC (C-MAC) learning over
			MPLS/IP core is done via data-plane learning.
	5.3 Multicast Operation		5.3 Multicast Operation
	5.3.1 Ingress Replication		5.3.1 Ingress Replication
	The operation is per the procedures of Section 3.3.1 above for the		The operation is per the procedures of Section 3.3.1 above for the
	scenario WITHOUT [MMRP]. The replication list is maintained per I-SID		scenario WITHOUT [MMRP]. The replication list is maintained per I-SID
	on the PBB-EVPN PEs and per VPN instance on the VPLS PEs.		on the PBB-EVPN PEs and per VPN instance on the VPLS PEs.
	5.3.2 LSM Will be covered in a future revision of this document.		5.3.2 P2MP Tunnel - Inclusive Tree
			The procedures for multicast operation on the PBB-EVPN PEs using P2MP
			tunnels are outside of the scope of this document.
	6 Solution Advantages		6 Solution Advantages
	The solution for seamless integration of (PBB-)EVPN with (PBB-)VPLS		The solution for seamless integration of (PBB-)EVPN with (PBB-)VPLS
	has the following advantages:		has the following advantages:
	- When ingress replication is used for multi-destination traffic		- When ingress replication is used for multi-destination traffic
	delivery, the solution reduces the scope of [MMRP] (which is a soft-		delivery, the solution reduces the scope of [MMRP] (which is a soft-
	state protocol) to only that of existing VPLS PEs, and uses the more		state protocol) to only that of existing VPLS PEs, and uses the more
	robust BGP-based mechanism for multicast pruning among new EVPN PEs.		robust BGP-based mechanism for multicast pruning among new EVPN PEs.
	- It is completely backward compatible.		- It is completely backward compatible.
	- New PEs can leverage the extensive multi-homing mechanisms and		- New PEs can leverage the extensive multi-homing mechanisms and
	provisioning simplifications of PBB-EVPN:		provisioning simplifications of PBB-EVPN:
	1. Auto-sensing of MHN / MHD		a. Auto-sensing of MHN / MHD
	2. Auto-discovery of redundancy group		b. Auto-discovery of redundancy group
	3.Auto-provisioning of DF election and VLAN carving		c. Auto-provisioning in DF election and VLAN carving
	7 Security Considerations		7 Security Considerations
	No new security considerations beyond those for VPLS and EVPN.		No new security considerations beyond those for VPLS and EVPN.
	8 IANA Considerations		8 IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	9 References		9 References
	9.1 Normative References		9.1 Normative References
	skipping to change at page 8, line 46 ¶		skipping to change at page 12, line 14 ¶
	No new security considerations beyond those for VPLS and EVPN.		No new security considerations beyond those for VPLS and EVPN.
	8 IANA Considerations		8 IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	9 References		9 References
	9.1 Normative References		9.1 Normative References
	[KEYWORDS] 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, March 1997.		Requirement Levels", BCP 14, RFC 2119, DOI
			10.17487/RFC2119, March <https://www.rfc-
			editor.org/info/rfc2119>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8077] Martini, et al., "Pseudowire Setup and Maintenance using		[RFC8077] Martini, et al., "Pseudowire Setup and Maintenance using
	the Label Distribution Protocol", RFC 8077, February 2017.		the Label Distribution Protocol", RFC 8077, February 2017.
	[RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", RFC 7432,		[RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", RFC 7432,
	February, 2015.		February, 2015.
	[RFC7623] Sajassi et al., "Provider Backbone Bridging Combined with		[RFC7623] Sajassi et al., "Provider Backbone Bridging Combined with
	Ethernet VPN (PBB-EVPN)", RFC 7623, September, 2015.		Ethernet VPN (PBB-EVPN)", RFC 7623, September, 2015.
	skipping to change at page 9, line 41 ¶		skipping to change at page 13, line 15 ¶
	[MMRP] Clause 10 of "IEEE Standard for Local and metropolitan area		[MMRP] Clause 10 of "IEEE Standard for Local and metropolitan area
	networks - Media Access Control (MAC) Bridges and Virtual Bridged		networks - Media Access Control (MAC) Bridges and Virtual Bridged
	Local Area Networks", IEEE Std 802.1Q, 2013.		Local Area Networks", IEEE Std 802.1Q, 2013.
	[RFC7041] Balus et al., "Extensions to VPLS PE model for Provider		[RFC7041] Balus et al., "Extensions to VPLS PE model for Provider
	Backbone Bridging", RFC 7041, November 2013.		Backbone Bridging", RFC 7041, November 2013.
	[RFC7080] Sajassi et al., "VPLS Interoperability with Provider		[RFC7080] Sajassi et al., "VPLS Interoperability with Provider
	Backbone Bridges", RFC 7080, December, 2013.		Backbone Bridges", RFC 7080, December, 2013.
			[IEEE.802.1ah] IEEE, "IEEE Standard for Local and metropolitan area
			networks - Media Access Control (MAC) Bridges and Virtual Bridged
			Local Area Networks", Clauses 25 and 26, IEEE Std 802.1Q, DOI
			10.1109/IEEESTD.2011.6009146.
	Authors' Addresses		Authors' Addresses
	Ali Sajassi		Ali Sajassi
	Cisco		Cisco
	Email: sajassi@cisco.com		Email: sajassi@cisco.com
	Samer Salam		Samer Salam
	Cisco		Cisco
	Email: ssalam@cisco.com		Email: ssalam@cisco.com
	Nick Del Regno		Nick Del Regno
	Verizon		Verizon
	Email: nick.delregno@verizon.com		Email: nick.delregno@verizon.com
	Jorge Rabadan		Jorge Rabadan
	Nokia		Nokia
End of changes. 32 change blocks.
	121 lines changed or deleted		242 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/