< draft-ietf-l2vpn-pbb-evpn-02.txt		draft-ietf-l2vpn-pbb-evpn-03.txt >
	skipping to change at page 1, line 17 ¶		skipping to change at page 1, line 17 ¶
	Florin Balus Nabil Bitar		Florin Balus Nabil Bitar
	Wim Henderickx Verizon		Wim Henderickx Verizon
	Alcatel-Lucent		Alcatel-Lucent
	Aldrin Isaac		Aldrin Isaac
	Clarence Filsfils Bloomberg		Clarence Filsfils Bloomberg
	Dennis Cai		Dennis Cai
	Cisco Lizhong Jin		Cisco Lizhong Jin
	ZTE		ZTE
	Expires: September 29, 2012 March 29, 2012		Expires: December 20, 2012 June 20, 2012
	PBB E-VPN		PBB-EVPN
	draft-ietf-l2vpn-pbb-evpn-02		draft-ietf-l2vpn-pbb-evpn-03
	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 39 ¶		skipping to change at page 2, line 39 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4.1. MAC Advertisement Route Scalability . . . . . . . . . . . 5		4.1. MAC Advertisement Route Scalability . . . . . . . . . . . 5
	4.2. C-MAC Mobility with MAC Summarization . . . . . . . . . . 5		4.2. C-MAC Mobility with MAC Summarization . . . . . . . . . . 5
	4.3. C-MAC Address Learning and Confinement . . . . . . . . . . 5		4.3. C-MAC Address Learning and Confinement . . . . . . . . . . 5
	4.4. Interworking with TRILL and 802.1aq Access Networks with		4.4. Per Site Policy Support . . . . . . . . . . . . . . . . . 6
	C-MAC Address Transparency . . . . . . . . . . . . . . . . 6		4.5. Avoiding C-MAC Address Flushing . . . . . . . . . . . . . 6
	4.5. Per Site Policy Support . . . . . . . . . . . . . . . . . 6
	4.6. Avoiding C-MAC Address Flushing . . . . . . . . . . . . . 6
	5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6		5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6
	6. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 7		6. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 7
	6.1. BGP MAC Advertisement Route . . . . . . . . . . . . . . . 7		6.1. BGP MAC Advertisement Route . . . . . . . . . . . . . . . 7
	6.2. Ethernet Auto-Discovery Route . . . . . . . . . . . . . . 8		6.2. Ethernet Auto-Discovery Route . . . . . . . . . . . . . . 7
	6.3. Per VPN Route Targets . . . . . . . . . . . . . . . . . . 8		6.3. Per VPN Route Targets . . . . . . . . . . . . . . . . . . 7
	6.4. MAC Mobility Extended Community . . . . . . . . . . . . . 8		6.4. MAC Mobility Extended Community . . . . . . . . . . . . . 7
	7. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8		7. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	7.1. MAC Address Distribution over Core . . . . . . . . . . . . 8		7.1. MAC Address Distribution over Core . . . . . . . . . . . . 8
	7.2. Device Multi-homing . . . . . . . . . . . . . . . . . . . 9		7.2. Device Multi-homing . . . . . . . . . . . . . . . . . . . 8
	7.2.1 Flow-based Load-balancing . . . . . . . . . . . . . . . 9		7.2.1 Flow-based Load-balancing . . . . . . . . . . . . . . . 8
	7.2.1.1 MES B-MAC Address Assignment . . . . . . . . . . . 9		7.2.1.1 MES B-MAC Address Assignment . . . . . . . . . . . 8
	7.2.1.2. Automating B-MAC Address Assignment . . . . . . . 11		7.2.1.2. Automating B-MAC Address Assignment . . . . . . . 10
	7.2.1.3 Split Horizon and Designated Forwarder Election . . 11		7.2.1.3 Split Horizon and Designated Forwarder Election . . 11
	7.2.2 I-SID Based Load-balancing . . . . . . . . . . . . . . . 12		7.2.2 I-SID Based Load-balancing . . . . . . . . . . . . . . . 11
	7.2.2.1 MES B-MAC Address Assignment . . . . . . . . . . . . 12		7.2.2.1 MES B-MAC Address Assignment . . . . . . . . . . . . 11
	7.2.2.2 Split Horizon and Designated Forwarder Election . . 12		7.2.2.2 Split Horizon and Designated Forwarder Election . . 12
	7.3. Network Multi-homing . . . . . . . . . . . . . . . . . . . 12		7.3. Network Multi-homing . . . . . . . . . . . . . . . . . . . 12
	7.4. Frame Forwarding . . . . . . . . . . . . . . . . . . . . . 13		7.4. Frame Forwarding . . . . . . . . . . . . . . . . . . . . . 12
	7.4.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . 13		7.4.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . 12
	7.4.2. Multicast/Broadcast . . . . . . . . . . . . . . . . . 13		7.4.2. Multicast/Broadcast . . . . . . . . . . . . . . . . . 13
	8. Minimizing ARP Broadcast . . . . . . . . . . . . . . . . . . . 14		8. Minimizing ARP Broadcast . . . . . . . . . . . . . . . . . . . 13
	9. Seamless Interworking with TRILL . . . . . . . . . . . . . . . 14		9. Seamless Interworking with IEEE 802.1aq/802.1Qbp . . . . . . . 13
	9.1 TRILL Nickname Assignment . . . . . . . . . . . . . . . . . 15		9.1 B-MAC Address Assignment . . . . . . . . . . . . . . . . . . 14
	9.2 TRILL Nickname Advertisement Route . . . . . . . . . . . . 16		9.2 IEEE 802.1aq / 802.1Qbp B-MAC Advertisement Route . . . . . 14
	9.3 Frame Format . . . . . . . . . . . . . . . . . . . . . . . . 16		9.3 Operation: . . . . . . . . . . . . . . . . . . . . . . . . . 15
	9.4 Unicast Forwarding . . . . . . . . . . . . . . . . . . . . 17		10. Solution Advantages . . . . . . . . . . . . . . . . . . . . . 15
	9.5 Handling Multicast . . . . . . . . . . . . . . . . . . . . . 18		10.1. MAC Advertisement Route Scalability . . . . . . . . . . . 15
	9.5.1 Multicast Stitching with Per-Source Load Balancing . . . 19		10.2. C-MAC Mobility with MAC Sub-netting . . . . . . . . . . . 16
	9.5.2 Multicast Stitching with Per-VLAN Load Balancing . . . . 19		10.3. C-MAC Address Learning and Confinement . . . . . . . . . 16
	9.5.3 Multicast Stitching with Per-Flow Load Balancing . . . . 20		10.4. Seamless Interworking with TRILL and 802.1aq Access
	9.5.4 Multicast Stitching with Per-Tree Load Balancing . . . . 20		Networks . . . . . . . . . . . . . . . . . . . . . . . . 16
	10. Seamless Interworking with IEEE 802.1aq/802.1Qbp . . . . . . . 21		10.5. Per Site Policy Support . . . . . . . . . . . . . . . . . 17
	10.2 B-MAC Address Assignment . . . . . . . . . . . . . . . . . 21		10.6. Avoiding C-MAC Address Flushing . . . . . . . . . . . . . 17
	10.2 IEEE 802.1aq / 802.1Qbp B-MAC Advertisement Route . . . . 21		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
	10.3 Operation: . . . . . . . . . . . . . . . . . . . . . . . . 22		12. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	11. Solution Advantages . . . . . . . . . . . . . . . . . . . . . 22		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	11.1. MAC Advertisement Route Scalability . . . . . . . . . . . 22		14. Intellectual Property Considerations . . . . . . . . . . . . 18
	11.2. C-MAC Mobility with MAC Sub-netting . . . . . . . . . . . 23		15. Normative References . . . . . . . . . . . . . . . . . . . . 18
	11.3. C-MAC Address Learning and Confinement . . . . . . . . . 23		16. Informative References . . . . . . . . . . . . . . . . . . . 18
	11.4. Seamless Interworking with TRILL and 802.1aq Access		17. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
	Networks . . . . . . . . . . . . . . . . . . . . . . . . 23
	11.5. Per Site Policy Support . . . . . . . . . . . . . . . . . 24
	11.6. Avoiding C-MAC Address Flushing . . . . . . . . . . . . . 24
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
	15. Intellectual Property Considerations . . . . . . . . . . . . 25
	16. Normative References . . . . . . . . . . . . . . . . . . . . 25
	17. Informative References . . . . . . . . . . . . . . . . . . . 25
	18. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25
	1. Introduction		1. Introduction
	[E-VPN] introduces a solution for multipoint L2VPN services, with		[E-VPN] introduces a solution for multipoint L2VPN services, with
	advanced multi-homing capabilities, using BGP for distributing		advanced multi-homing capabilities, using BGP for distributing
	customer/client MAC address reach-ability information over the core		customer/client MAC address reach-ability information over the core
	MPLS/IP network. [802.1ah] defines an architecture for Ethernet		MPLS/IP network. [802.1ah] defines an architecture for Ethernet
	Provider Backbone Bridging (PBB), where MAC tunneling is employed to		Provider Backbone Bridging (PBB), where MAC tunneling is employed to
	improve service instance and MAC address scalability in Ethernet as		improve service instance and MAC address scalability in Ethernet as
	well as VPLS networks [PBB-VPLS].		well as VPLS networks [PBB-VPLS].
	skipping to change at page 4, line 29 ¶		skipping to change at page 4, line 29 ¶
	using C-MAC aggregation and B-MAC sub-netting, confine the scope of		using C-MAC aggregation and B-MAC sub-netting, confine the scope of
	C-MAC learning to only active flows, offer per site policies and		C-MAC learning to only active flows, offer per site policies and
	avoid C-MAC address flushing on topology changes. The combined		avoid C-MAC address flushing on topology changes. The combined
	solution is referred to as PBB-EVPN.		solution is referred to as PBB-EVPN.
	2. Contributors		2. Contributors
	In addition to the authors listed above, the following individuals		In addition to the authors listed above, the following individuals
	also contributed to this document.		also contributed to this document.
	Keyur Patel Cisco		Keyur Patel, Cisco
			Sam Aldrin, Huawei
	3. Terminology		3. Terminology
	BEB: Backbone Edge Bridge		BEB: Backbone Edge Bridge
	B-MAC: Backbone MAC Address		B-MAC: Backbone MAC Address
	CE: Customer Edge		CE: Customer Edge
	C-MAC: Customer/Client MAC Address		C-MAC: Customer/Client MAC Address
	DHD: Dual-homed Device		DHD: Dual-homed Device
	DHN: Dual-homed Network		DHN: Dual-homed Network
	LACP: Link Aggregation Control Protocol		LACP: Link Aggregation Control Protocol
	skipping to change at page 6, line 6 ¶		skipping to change at page 6, line 7 ¶
	forwarding traffic to, or from, these C-MAC addresses. Even if an		forwarding traffic to, or from, these C-MAC addresses. Even if an
	implementation does not install hardware forwarding entries for C-MAC		implementation does not install hardware forwarding entries for C-MAC
	addresses that are not part of active traffic flows on that MES, the		addresses that are not part of active traffic flows on that MES, the
	device memory is still consumed by keeping record of the C-MAC		device memory is still consumed by keeping record of the C-MAC
	addresses in the routing table (RIB). In network applications with		addresses in the routing table (RIB). In network applications with
	millions of C-MAC addresses, this introduces a non-trivial waste of		millions of C-MAC addresses, this introduces a non-trivial waste of
	MES resources. As such, it is required to confine the scope of		MES resources. As such, it is required to confine the scope of
	visibility of C-MAC addresses only to those MES nodes that are		visibility of C-MAC addresses only to those MES nodes that are
	actively involved in forwarding traffic to, or from, these addresses.		actively involved in forwarding traffic to, or from, these addresses.
	4.4. Interworking with TRILL and 802.1aq Access Networks with C-MAC		4.4. Per Site Policy Support
	Address Transparency
	[TRILL] and [802.1aq] define next generation Ethernet bridging
	technologies that offer optimal forwarding using IS-IS control plane,
	and C-MAC address transparency via Ethernet tunneling technologies.
	When access networks based on TRILL or 802.1aq are interconnected
	over an MPLS/IP network, it is required to guarantee C-MAC address
	transparency on the hand-off point and the edge (i.e. MES) of the
	MPLS network. As such, solutions that require termination of the
	access data-plane encapsulation (i.e. TRILL or 802.1aq) at the hand-
	off to the MPLS network do not meet this transparency requirement,
	and expose the MPLS edge devices to the MAC address scalability
	problem.
	PBB-EVPN supports seamless interconnect with these next generation
	Ethernet solutions while guaranteeing C-MAC address transparency on
	the MES nodes.
	4.5. Per Site Policy Support
	In many applications, it is required to be able to enforce		In many applications, it is required to be able to enforce
	connectivity policy rules at the granularity of a site (or segment).		connectivity policy rules at the granularity of a site (or segment).
	This includes the ability to control which MES nodes in the network		This includes the ability to control which MES nodes in the network
	can forward traffic to, or from, a given site. PBB-EVPN is capable of		can forward traffic to, or from, a given site. PBB-EVPN is capable of
	providing this granularity of policy control. In the case where per		providing this granularity of policy control. In the case where per
	C-MAC address granularity is required, the EVI can always continue to		C-MAC address granularity is required, the EVI can always continue to
	operate in E-VPN mode.		operate in E-VPN mode.
	4.6. Avoiding C-MAC Address Flushing		4.5. Avoiding C-MAC Address Flushing
	It is required to avoid C-MAC address flushing upon link, port or		It is required to avoid C-MAC address flushing upon link, port or
	node failure for multi-homed devices and networks. This is in order		node failure for multi-homed devices and networks. This is in order
	to speed up re-convergence upon failure.		to speed up re-convergence upon failure.
	5. Solution Overview		5. Solution Overview
	The solution involves incorporating IEEE 802.1ah Backbone Edge Bridge		The solution involves incorporating IEEE 802.1ah Backbone Edge Bridge
	(BEB) functionality on the E-VPN MES nodes similar to PBB-VPLS, where		(BEB) functionality on the E-VPN MES nodes similar to PBB-VPLS, where
	BEB functionality is incorporated in the VPLS PE nodes. The MES		BEB functionality is incorporated in the VPLS PE nodes. The MES
	skipping to change at page 14, line 20 ¶		skipping to change at page 13, line 40 ¶
	This is achieved by having each MES node snoop on ARP request and		This is achieved by having each MES node snoop on ARP request and
	response messages received over the access interfaces or the MPLS		response messages received over the access interfaces or the MPLS
	core. The MES builds a cache of IP / MAC address bindings from these		core. The MES builds a cache of IP / MAC address bindings from these
	snooped messages. The MES then uses this cache to respond to ARP		snooped messages. The MES then uses this cache to respond to ARP
	requests ingress on access ports and targeting hosts that are in		requests ingress on access ports and targeting hosts that are in
	remote sites. If the MES finds a match for the IP address in its ARP		remote sites. If the MES finds a match for the IP address in its ARP
	cache, it responds back to the requesting host and drops the request.		cache, it responds back to the requesting host and drops the request.
	Otherwise, if it does not find a match, then the request is flooded		Otherwise, if it does not find a match, then the request is flooded
	over the MPLS network using either ingress replication or LSM.		over the MPLS network using either ingress replication or LSM.
	9. Seamless Interworking with TRILL		9. Seamless Interworking with IEEE 802.1aq/802.1Qbp
	PBB-EVPN enables seamless connectivity of TRILL networks over an
	MPLS/IP core while ensuring control-plane separation among these
	networks, and maintaining C-MAC address transparency on the MES
	nodes.
	Every TRILL network that is connected to the MPLS core runs an
	independent instance of the IS-IS control-plane. Each MES
	participates in the TRILL IS-IS control plane of its local site. The
	MES peers, in IS-IS protocol, with the RBridges internal to the site,
	but does not terminate the TRILL data-plane encapsulation. So, from a
	control-plane viewpoint, the MES appears as an edge RBridge; whereas,
	from a data-plane viewpoint, the MES appears as a core RBridge to the
	TRILL network. The MES nodes encapsulate TRILL frames with MPLS in
	the imposition path, and de-capsulate them in the disposition path.
	+--------------+
	| |
	+---------+ | MPLS | +---------+
	+----+ | | +----+ +----+ | | +----+
	|RB1 |--| | |MES1| |MES2| | |--| RB3|
	+----+ | TRILL |---| | | |--| TRILL | +----+
	+----+ | | +----+ +----+ | | +----+
	|RB2 |--| | | Backbone | | |--| RB4|
	+----+ +---------+ +--------------+ +---------+ +----+
	|<------ IS-IS -------->|<-----BGP----->|<------ IS-IS ------>| CP
	|<------------------------- TRILL -------------------------->| DP
	|<----MPLS----->|
	Legend: CP = Control Plane View
	DP = Data Plane View
	Figure 4: Interconnecting TRILL Networks with PBB-EVPN
	9.1 TRILL Nickname Assignment
	In TRILL, edge RBridges build forwarding tables that associate remote
	C-MAC addresses with remote edge RBridge nicknames via data-path
	learning (except if the optional ESADI function is in use). When
	different TRILL networks are interconnected over an MPLS/IP network
	using a seamless hand-off, the edge RBridges (corresponding to the
	ingress and egress RBridges of particular traffic flows) may very
	well reside in different TRILL networks. Therefore, in order to
	guarantee correct connectivity, the TRILL Nicknames must be globally
	unique across all the interconnected TRILL islands in a given EVI.
	This can be achieved, for instance, by using a hierarchical Nickname
	assignment paradigm, and encoding a Site ID in the high-order bits of
	the Nickname:
	Nickname = [Site ID : Rbridge ID ]
	The Site ID uniquely identifies a TRILL network, whereas the RBridge
	ID portion of the Nickname has local significance to a TRILL site,
	and can be reused in different sites to designate different RBridges.
	However, the fully qualified Nickname is globally unique in the
	entire domain of interconnected TRILL networks for a given EVI.
	It is worth noting here that this hierarchical Nickname encoding
	scheme guarantees that Nickname collisions do not occur between
	different TRILL islands. Therefore, there is no need to define TRILL
	Nickname collision detection/resolution mechanisms to operate across
	separate TRILL islands interconnected via PBB-EVPN.
	Another point to note is that there are proposals to achieve per-site
	Nickname significance; however, these proposals either require C-MAC
	learning on the border RBridge (i.e. violate the C-MAC address
	transparency requirement), or require a completely new encapsulation
	and associated data-path for TRILL [TRILL-PERLMAN-MULTILEVEL].
	9.2 TRILL Nickname Advertisement Route
	A new BGP route is defined to support the interconnection of TRILL
	networks over PBB-EVPN: the TRILL Nickname Advertisement' route,
	encoded as follows:
	+---------------------------------------+
	| RD (8 octets) |
	+---------------------------------------+
	|Ethernet Segment Identifier (10 octets)|
	+---------------------------------------+
	| Ethernet Tag ID (4 octets) |
	+---------------------------------------+
	| Nickname Length (1 octet) |
	+---------------------------------------+
	| RBridge Nickname (2 octets) |
	+---------------------------------------+
	| MPLS Label (n * 3 octets) |
	+---------------------------------------+
	Figure 5: TRILL Nickname Advertisement Route
	The MES uses this route to advertise the reachability of TRILL
	RBridge nicknames to other MES nodes in the EVI. The MPLS label
	advertised in this route is allocated on a per EVI basis and serves
	the purpose of identifying to the disposition MES that the MPLS-
	encapsulated packet holds an MPLS encapsulated TRILL frame.
	9.3 Frame Format
	The encapsulation for the transport of TRILL frames over MPLS is
	encoded as shown in the figure below:
	+------------------+
	| IP/MPLS Header |
	+------------------+
	| TRILL Header |
	+------------------+
	| Ethernet Header |
	+------------------+
	| Ethernet Payload |
	+------------------+
	| Ethernet FCS |
	+------------------+
	Figure 6: TRILL over MPLS Encapsulation
	It is worth noting here that while it is possible to transport
	Ethernet encapsulated TRILL frames over MPLS, that approach
	unnecessarily wastes 16 bytes per packet. That approach further
	requires either the use of well-known MAC addresses or having the MES
	nodes advertise in BGP their device MAC addresses, in order to
	resolve the TRILL next-hop L2 adjacency. To that end, it is simpler
	and more efficient to transport TRILL natively over MPLS, and this is
	the reason why a new BGP route for TRILL Nickname advertisement is
	defined.
	9.4 Unicast Forwarding
	Every MES advertises in BGP the Nicknames of all RBridges local to
	its site in the TRILL Nickname Advertisement routes. Furthermore, the
	MES advertises in IS-IS, to the local island, the Rbridge nicknames
	of all remote switches in all the other TRILL islands that the MES
	has learned via BGP. This is required since TRILL [RFC6325] currently
	does not define the concept of default routes. However, if the
	concept of default routes is added to TRILL, then the MES can
	advertise itself as a border RBridge, and all the other Rbridges in
	the TRILL network would install a default route pointing to the MES.
	The default route would be used for all unknown destination
	Nicknames. This eliminates the need to redistribute Nicknames learnt
	via BGP into TRILL IS-IS.
	Note that by having multiple MES nodes (connected to the same TRILL
	island) advertise routes to the same RBridge nickname, with equal BGP
	Local_Pref attribute, it is possible to perform active/active load-
	balancing to/from the MPLS core.
	When a MES receives an Ethernet-encapsulated TRILL frame from the
	access side, it removes the Ethernet encapsulation (i.e. outer MAC
	header), and performs a lookup on the egress RBridge nickname in the
	TRILL header to identify the next-hop. If the lookup yields that the
	next hop is a remote MES, the local MES would then encapsulate the
	TRILL frame in MPLS. The label stack comprises of the VPN label
	(advertised by the remote MES), followed by an LSP/IGP label. From
	that point onwards, regular MPLS forwarding is applied.
	On the disposition MES, assuming penultimate-hop-popping is employed,
	the MES receives the MPLS-encapsulated TRILL frame with a single
	label: the VPN label. The value of the label indicates to the
	disposition MES that this is a TRILL packet, so the label is popped,
	the TTL field (in the TRILL header) is reinitialized and normal TRILL
	processing is employed from this point onwards.
	9.5 Handling Multicast
	Each TRILL network independently builds its shared multicast trees.
	The number of these trees need not match in the different
	interconnected TRILL islands. In the MPLS/IP network, multiple
	options are available for the delivery of multicast traffic:
	- Ingress replication
	- LSM with Inclusive trees
	- LSM with Aggregate Inclusive trees
	- LSM with Selective trees
	- LSM with Aggregate Selective trees
	When LSM is used, the trees may be either P2MP or MP2MP.
	The MES nodes are responsible for stitching the TRILL multicast
	trees, on the access side, to the ingress replication tunnels or LSM
	trees in the MPLS/IP core. The stitching must ensure that the
	following characteristics are maintained at all times:
	1. Avoiding Packet Duplication: In the case where the TRILL network
	is multi-homed to multiple MES nodes, if all of the MES nodes forward
	the same multicast frame, then packet duplication would arise. This
	applies to both multicast traffic from site to core as well as from
	core to site.
	2. Avoiding Forwarding Loops: In the case of TRILL network multi-
	homing, the solution must ensure that a multicast frame forwarded by
	a given MES to the MPLS core is not forwarded back by another MES (in
	the same TRILL network) to the TRILL network of origin. The same
	applies for traffic in the core to site direction.
	3. Pacifying TRILL RPF Checks: For multicast traffic originating from
	a different TRILL network, the RPF checks must be performed against
	the disposition MES (i.e. the MES on which the traffic ingress into
	the destination TRILL network).
	There are two approaches by which the above operation can be
	guaranteed: one offers per-source load-balancing while the other
	offers per-flow load-balancing.
	9.5.1 Multicast Stitching with Per-Source Load Balancing
	The MES nodes, connected to a multi-homed TRILL network, perform BGP
	DF election to decide which MES is responsible for forwarding
	multicast traffic from a given source RBridge. An MES would only
	forward multicast traffic from source RBridges for which it is the
	DF, in both the site to core as well as core to site directions. This
	solves both the issue of avoiding packet duplication as well as the
	issue of avoiding forwarding loops.
	In addition, the MES node advertises in IS-IS the nicknames of remote
	RBridges, learnt in BGP, for which it is the elected DF. This allows
	all RBridges in the local TRILL network to build the correct RPF
	state for these remote RBridge nicknames. Note that this results in
	all unicast traffic to a given remote RBridge being forwarded to the
	DF MES only (i.e. load-balancing of unicast traffic would not be
	possible in the site to core direction).
	Alternatively, all MES nodes in a redundancy group can advertise the
	nicknames of all remote RBridges learnt in BGP. In addition, each MES
	advertises the Affinity sub-TLV, defined in [TRILL-CMT], on behalf of
	each of the remote RBridges for which it is the elected DF. This
	ensures that the RPF check state is set up correctly in the TRILL
	network, while allowing load-balancing of unicast traffic among the
	MES nodes.
	In this approach, all MES nodes in a given redundancy group can
	forward and receive traffic on all TRILL trees.
	9.5.2 Multicast Stitching with Per-VLAN Load Balancing
	The MES nodes, connected to a multi-homed TRILL network, perform BGP
	DF election to decide which MES node is responsible for forwarding
	multicast traffic associated with a given VLAN. An MES would forward
	multicast traffic for a given VLAN only when it is the DF for this
	VLAN. This forwarding rule applies in both the site to core as well
	as core to site directions.
	In addition, the MES nodes in the redundancy group partition among
	themselves the set of TRILL multicast trees so that each MES only
	sends traffic on a unique set of trees. This can be done using the RP
	Election Protocol as discussed in [TRILL-MULTILEVEL]. Alternatively,
	the BGP DF election could be used for that. Each MES, then,
	advertises to the local TRILL network a Default Affinity sub-TLV, per
	[TRILL-MULTILEVEL], listing the trees that it will be using for
	multicast traffic originating from remote RBridges.
	In this approach, each MES node in given TRILL network receives
	traffic from all TRILL trees but forwards traffic on only a dedicated
	subset of trees. Hence, the TRILL network must have at least as many
	multicast trees as the number of directly attached MES nodes.
	9.5.3 Multicast Stitching with Per-Flow Load Balancing
	This approach is similar to the per-VLAN load-balancing approach
	described above, with the difference being that the MES nodes perform
	the BGP DF election on a per-flow basis. The flow is identified by an
	N-Tuple comprising of Layer 2 and Layer 3 addresses in addition to
	Layer 4 ports. This can be done by treating the N-Tuple as a numeric
	value, and performing, for e.g., a modulo hash function against the
	number of PEs in the redundancy group in order to identify the index
	of the PE that is the DF for a given N-Tuple.
	In this approach, each MES node in given TRILL network receives
	traffic from all TRILL trees but forwards traffic on only a dedicated
	subset of trees. Hence, the TRILL network must have at least as many
	multicast trees as the number of directly attached MES nodes.
	9.5.4 Multicast Stitching with Per-Tree Load Balancing
	The MES nodes, connected to a multi-homed TRILL network, perform BGP
	DF election to decide which MES node is responsible for forwarding
	multicast traffic associated with a given TRILL multicast tree. An
	MES would forward multicast traffic with a given destination RBridge
	nickname only when it is the DF for this nickname. This forwarding
	rule applies in both the site to core as well as core to site
	directions. The outcome of the BGP DF election is then used to drive
	TRILL IS-IS advertisements: the MES advertises to the local TRILL
	network a Default Affinity sub-TLV, per [TRILL-MULTILEVEL], listing
	the trees for which it is the elected DF.
	Note that on the egress MES, the destination RBridge Nickname in
	multicast frames identifies the multicast tree of the remote TRILL
	network from which the frame originated. If the TRILL tree
	identifiers are not coordinated between sites, then the egress
	Nickname has no meaning in the directly attached (destination) TRILL
	network. So, the MES needs to select a new tree (after the MPLS
	disposition) based on a hash function, and rewrite the frame with
	this new destination Nickname before forwarding the traffic. This may
	be necessary in certain deployments to ensure complete decoupling
	between the TRILL sites connected to the MPLS core. On the other
	hand, if the TRILL tree identifiers are coordinated between sites,
	then the MES doesn't have to rewrite the destination nickname in the
	TRILL header, after the MPLS disposition.
	In this approach, each MES node in a given redundancy group forwards
	and receives traffic on a disjoint set of TRILL trees. At a minimum,
	the TRILL network must have as many multicast trees as the number of
	directly attached MES nodes.
	10. Seamless Interworking with IEEE 802.1aq/802.1Qbp
	+--------------+		+--------------+
	| |		| |
	+---------+ | MPLS | +---------+		+---------+ | MPLS | +---------+
	+----+ | | +----+ +----+ | | +----+		+----+ | | +----+ +----+ | | +----+
	|SW1 |--| | |MES1| |MES2| | |--| SW3|		|SW1 |--| | |MES1| |MES2| | |--| SW3|
	+----+ | 802.1aq |---| | | |--| 802.1aq | +----+		+----+ | 802.1aq |---| | | |--| 802.1aq | +----+
	+----+ | .1Qbp | +----+ +----+ | .1Qbp | +----+		+----+ | .1Qbp | +----+ +----+ | .1Qbp | +----+
	|SW2 |--| | | Backbone | | |--| SW4|		|SW2 |--| | | Backbone | | |--| SW4|
	+----+ +---------+ +--------------+ +---------+ +----+		+----+ +---------+ +--------------+ +---------+ +----+
	|<------ IS-IS -------->|<-----BGP----->|<------ IS-IS ------>| CP		|<------ IS-IS -------->|<-----BGP----->|<------ IS-IS ------>| CP
	|<------------------------- PBB -------------------------->| DP		|<------------------------- PBB -------------------------->| DP
	|<----MPLS----->|		|<----MPLS----->|
	Legend: CP = Control Plane View		Legend: CP = Control Plane View
	DP = Data Plane View		DP = Data Plane View
	Figure 7: Interconnecting 802.1aq/802.1Qbp Networks with PBB-EVPN		Figure 7: Interconnecting 802.1aq/802.1Qbp Networks with PBB-EVPN
	10.2 B-MAC Address Assignment		9.1 B-MAC Address Assignment
	For the same reasons cited in the TRILL section, the B-MAC addresses		For the same reasons cited in the TRILL section, the B-MAC addresses
	need to be globally unique across all the IEEE 802.1aq / 802.1Qbp		need to be globally unique across all the IEEE 802.1aq / 802.1Qbp
	networks. The same hierarchical address assignment scheme depicted		networks. The same hierarchical address assignment scheme depicted
	above is proposed for B-MAC addresses as well.		above is proposed for B-MAC addresses as well.
	10.2 IEEE 802.1aq / 802.1Qbp B-MAC Advertisement Route		9.2 IEEE 802.1aq / 802.1Qbp B-MAC Advertisement Route
	B-MAC addresses associated with 802.1aq / 802.1Qbp switches are		B-MAC addresses associated with 802.1aq / 802.1Qbp switches are
	advertised using the BGP MAC Advertisement route already defined in		advertised using the BGP MAC Advertisement route already defined in
	[E-VPN].		[E-VPN].
	The encapsulation for the transport of PBB frames over MPLS is		The encapsulation for the transport of PBB frames over MPLS is
	similar to that of classical Ethernet, albeit with the additional PBB		similar to that of classical Ethernet, albeit with the additional PBB
	header, as shown in the figure below:		header, as shown in the figure below:
	+------------------+		+------------------+
	skipping to change at page 22, line 19 ¶		skipping to change at page 15, line 19 ¶
	+------------------+		+------------------+
	| Ethernet Header |		| Ethernet Header |
	+------------------+		+------------------+
	| Ethernet Payload |		| Ethernet Payload |
	+------------------+		+------------------+
	| Ethernet FCS |		| Ethernet FCS |
	+------------------+		+------------------+
	Figure 8: PBB over MPLS Encapsulation		Figure 8: PBB over MPLS Encapsulation
	10.3 Operation:		9.3 Operation:
	When a MES receives a PBB-encapsulated Ethernet frame from the access		When a MES receives a PBB-encapsulated Ethernet frame from the access
	side, it performs a lookup on the B-MAC destination address to		side, it performs a lookup on the B-MAC destination address to
	identify the next hop. If the lookup yields that the next hop is a		identify the next hop. If the lookup yields that the next hop is a
	remote MES, the local MES would then encapsulate the PBB frame in		remote MES, the local MES would then encapsulate the PBB frame in
	MPLS. The label stack comprises of the VPN label (advertised by the		MPLS. The label stack comprises of the VPN label (advertised by the
	remote PE), followed by an LSP/IGP label. From that point onwards,		remote PE), followed by an LSP/IGP label. From that point onwards,
	regular MPLS forwarding is applied.		regular MPLS forwarding is applied.
	On the disposition MES, assuming penultimate-hop-popping is employed,		On the disposition MES, assuming penultimate-hop-popping is employed,
	the MES receives the MPLS-encapsulated PBB frame with a single label:		the MES receives the MPLS-encapsulated PBB frame with a single label:
	the VPN label. The value of the label indicates to the disposition		the VPN label. The value of the label indicates to the disposition
	MES that this is a PBB frame, so the label is popped, the TTL field		MES that this is a PBB frame, so the label is popped, the TTL field
	(in the 802.1Qbp F-Tag) is reinitialized and normal PBB processing is		(in the 802.1Qbp F-Tag) is reinitialized and normal PBB processing is
	employed from this point onwards.		employed from this point onwards.
	11. Solution Advantages		10. Solution Advantages
	In this section, we discuss the advantages of the PBB-EVPN solution		In this section, we discuss the advantages of the PBB-EVPN solution
	in the context of the requirements set forth in section 3 above.		in the context of the requirements set forth in section 3 above.
	11.1. MAC Advertisement Route Scalability		10.1. MAC Advertisement Route Scalability
	In PBB-EVPN the number of MAC Advertisement Routes is a function of		In PBB-EVPN the number of MAC Advertisement Routes is a function of
	the number of segments (sites), rather than the number of		the number of segments (sites), rather than the number of
	hosts/servers. This is because the B-MAC addresses of the MESes,		hosts/servers. This is because the B-MAC addresses of the MESes,
	rather than C-MAC addresses (of hosts/servers) are being advertised		rather than C-MAC addresses (of hosts/servers) are being advertised
	in BGP. And, as discussed above, there's a one-to-one mapping between		in BGP. And, as discussed above, there's a one-to-one mapping between
	multi-homed segments and B-MAC addresses, whereas there's a one-to-		multi-homed segments and B-MAC addresses, whereas there's a one-to-
	one or many-to-one mapping between single-homed segments and B-MAC		one or many-to-one mapping between single-homed segments and B-MAC
	addresses for a given MES. As a result, the volume of MAC		addresses for a given MES. As a result, the volume of MAC
	Advertisement Routes in PBB-EVPN is multiple orders of magnitude less		Advertisement Routes in PBB-EVPN is multiple orders of magnitude less
	than E-VPN.		than E-VPN.
	11.2. C-MAC Mobility with MAC Sub-netting		10.2. C-MAC Mobility with MAC Sub-netting
	In PBB-EVPN, if a MES allocates its B-MAC addresses from a contiguous		In PBB-EVPN, if a MES allocates its B-MAC addresses from a contiguous
	range, then it can advertise a MAC prefix rather than individual 48-		range, then it can advertise a MAC prefix rather than individual 48-
	bit addresses. It should be noted that B-MAC addresses can easily be		bit addresses. It should be noted that B-MAC addresses can easily be
	assigned from a contiguous range because MES nodes are within the		assigned from a contiguous range because MES nodes are within the
	provider administrative domain; however, CE devices and hosts are		provider administrative domain; however, CE devices and hosts are
	typically not within the provider administrative domain. The		typically not within the provider administrative domain. The
	advantage of such MAC address sub-netting can be maintained even as		advantage of such MAC address sub-netting can be maintained even as
	C-MAC addresses move from one Ethernet segment to another. This is		C-MAC addresses move from one Ethernet segment to another. This is
	because the C-MAC address to B-MAC address association is learnt in		because the C-MAC address to B-MAC address association is learnt in
	skipping to change at page 23, line 32 ¶		skipping to change at page 16, line 32 ¶
	addresses in that subnet move to other segments (e.g. due to virtual		addresses in that subnet move to other segments (e.g. due to virtual
	machine mobility), then in the worst case, N/2 additional MAC		machine mobility), then in the worst case, N/2 additional MAC
	Advertisement routes need to be sent for the MAC addresses that have		Advertisement routes need to be sent for the MAC addresses that have
	moved. This defeats the purpose of the sub-netting. With PBB-EVPN, on		moved. This defeats the purpose of the sub-netting. With PBB-EVPN, on
	the other hand, the sub-netting applies to the B-MAC addresses which		the other hand, the sub-netting applies to the B-MAC addresses which
	are statically associated with MES nodes and are not subject to		are statically associated with MES nodes and are not subject to
	mobility. As C-MAC addresses move from one segment to another, the		mobility. As C-MAC addresses move from one segment to another, the
	binding of C-MAC to B-MAC addresses is updated via data-plane		binding of C-MAC to B-MAC addresses is updated via data-plane
	learning.		learning.
	11.3. C-MAC Address Learning and Confinement		10.3. C-MAC Address Learning and Confinement
	In PBB-EVPN, C-MAC address reachability information is built via		In PBB-EVPN, C-MAC address reachability information is built via
	data-plane learning. As such, MES nodes not participating in active		data-plane learning. As such, MES nodes not participating in active
	conversations involving a particular C-MAC address will purge that		conversations involving a particular C-MAC address will purge that
	address from their forwarding tables. Furthermore, since C-MAC		address from their forwarding tables. Furthermore, since C-MAC
	addresses are not distributed in BGP, MES nodes will not maintain any		addresses are not distributed in BGP, MES nodes will not maintain any
	record of them in control-plane routing table.		record of them in control-plane routing table.
	11.4. Seamless Interworking with TRILL and 802.1aq Access Networks		10.4. Seamless Interworking with TRILL and 802.1aq Access Networks
	Consider the scenario where two access networks, one running MPLS and		Consider the scenario where two access networks, one running MPLS and
	the other running 802.1aq, are interconnected via an MPLS backbone		the other running 802.1aq, are interconnected via an MPLS backbone
	network. The figure below shows such an example network.		network. The figure below shows such an example network.
	+--------------+		+--------------+
	| |		| |
	+---------+ | MPLS | +---------+		+---------+ | MPLS | +---------+
	+----+ | | +----+ +----+ | | +----+		+----+ | | +----+ +----+ | | +----+
	| CE |--| | |MES1| |MES2| | |--| CE |		| CE |--| | |MES1| |MES2| | |--| CE |
	skipping to change at page 24, line 31 ¶		skipping to change at page 17, line 31 ¶
	addresses of all hosts/servers connected to the access networks.		addresses of all hosts/servers connected to the access networks.
	However, if the MPLS backbone network employs PBB-EVPN, then the		However, if the MPLS backbone network employs PBB-EVPN, then the
	802.1aq encapsulation can be extended over the MPLS backbone, thereby		802.1aq encapsulation can be extended over the MPLS backbone, thereby
	maintaining C-MAC address transparency on MES1. If PBB-EVPN is also		maintaining C-MAC address transparency on MES1. If PBB-EVPN is also
	extended over the MPLS access network on the right, then C-MAC		extended over the MPLS access network on the right, then C-MAC
	addresses would be transparent to MES2 as well.		addresses would be transparent to MES2 as well.
	Interoperability with TRILL access network will be described in		Interoperability with TRILL access network will be described in
	future revision of this draft.		future revision of this draft.
	11.5. Per Site Policy Support		10.5. Per Site Policy Support
	In PBB-EVPN, a unique B-MAC address can be associated with every site		In PBB-EVPN, a unique B-MAC address can be associated with every site
	(single-homed or multi-homed). Given that the B-MAC addresses are		(single-homed or multi-homed). Given that the B-MAC addresses are
	sent in BGP MAC Advertisement routes, it is possible to define per		sent in BGP MAC Advertisement routes, it is possible to define per
	site (i.e. B-MAC) forwarding policies including policies for E-TREE		site (i.e. B-MAC) forwarding policies including policies for E-TREE
	service.		service.
	11.6. Avoiding C-MAC Address Flushing		10.6. Avoiding C-MAC Address Flushing
	With PBB-EVPN, it is possible to avoid C-MAC address flushing upon		With PBB-EVPN, it is possible to avoid C-MAC address flushing upon
	topology change affecting a multi-homed device. To illustrate this,		topology change affecting a multi-homed device. To illustrate this,
	consider the example network of Figure 1. Both MES1 and MES2		consider the example network of Figure 1. Both MES1 and MES2
	advertize the same B-MAC address (BM1) to MES3. MES3 then learns the		advertize the same B-MAC address (BM1) to MES3. MES3 then learns the
	C-MAC addresses of the servers/hosts behind CE1 via data-plane		C-MAC addresses of the servers/hosts behind CE1 via data-plane
	learning. If AC1 fails, then MES3 does not need to flush any of the		learning. If AC1 fails, then MES3 does not need to flush any of the
	C-MAC addresses learnt and associated with BM1. This is because MES1		C-MAC addresses learnt and associated with BM1. This is because MES1
	will withdraw the MAC Advertisement routes associated with BM1,		will withdraw the MAC Advertisement routes associated with BM1,
	thereby leading MES3 to have a single adjacency (to MES2) for this B-		thereby leading MES3 to have a single adjacency (to MES2) for this B-
	MAC address. Therefore, the topology change is communicated to MES3		MAC address. Therefore, the topology change is communicated to MES3
	and no C-MAC address flushing is required.		and no C-MAC address flushing is required.
	12. Acknowledgements		11. Acknowledgements
	TBD.		TBD.
	13. Security Considerations		12. Security Considerations
	There are no additional security aspects beyond those of VPLS/H-VPLS		There are no additional security aspects beyond those of VPLS/H-VPLS
	that need to be discussed here.		that need to be discussed here.
	14. IANA Considerations		13. IANA Considerations
	This document requires IANA to assign a new SAFI value for L2VPN_MAC		This document requires IANA to assign a new SAFI value for L2VPN_MAC
	SAFI.		SAFI.
	15. Intellectual Property Considerations		14. Intellectual Property Considerations
	This document is being submitted for use in IETF standards		This document is being submitted for use in IETF standards
	discussions.		discussions.
	16. Normative References		15. Normative References
	[802.1ah] "Virtual Bridged Local Area Networks Amendment 7: Provider		[802.1ah] "Virtual Bridged Local Area Networks Amendment 7: Provider
	Backbone Bridges", IEEE Std. 802.1ah-2008, August 2008.		Backbone Bridges", IEEE Std. 802.1ah-2008, August 2008.
	17. Informative References		16. Informative References
	[PBB-VPLS] Sajassi et al., "VPLS Interoperability with Provider		[PBB-VPLS] Sajassi et al., "VPLS Interoperability with Provider
	Backbone Bridges", draft-ietf-l2vpn-vpls-pbb-interop-		Backbone Bridges", draft-ietf-l2vpn-vpls-pbb-interop-
	02.txt, work in progress, July, 2011.		02.txt, work in progress, July, 2011.
	[EVPN-REQ] Sajassi et al., "Requirements for Ethernet VPN (E-VPN)",		[EVPN-REQ] Sajassi et al., "Requirements for Ethernet VPN (E-VPN)",
	draft-sajassi-raggarwa-l2vpn-evpn-req-01.txt, work in		draft-sajassi-raggarwa-l2vpn-evpn-req-01.txt, work in
	progress, July, 2011.		progress, July, 2011.
	[E-VPN] Aggarwal et al., "BGP MPLS Based Ethernet VPN", draft-ietf-		[E-VPN] Aggarwal et al., "BGP MPLS Based Ethernet VPN", draft-ietf-
	l2vpn-evpn-00.txt, work in progress, February, 2012.		l2vpn-evpn-00.txt, work in progress, February, 2012.
	[TRILL-CMT] Senevirathne et al., "Coordinated Multicast Trees for		17. Authors' Addresses
	TRILL", draft-tissa-trill-cmt-00.txt, work in progress,
	January 2012.
	[TRILL-MULTILEVEL] Senevirathne et al., "Default Nickname Based
	Approach for Multilevel TRILL", draft-tissa-trill-
	multilevel-00.txt, work in progress, February 2012.
	18. Authors' Addresses
	Ali Sajassi		Ali Sajassi
	Cisco		Cisco
	170 West Tasman Drive		170 West Tasman Drive
	San Jose, CA 95134, US		San Jose, CA 95134, US
	Email: sajassi@cisco.com		Email: sajassi@cisco.com
	Samer Salam		Samer Salam
	Cisco		Cisco
	595 Burrard Street, Suite 2123		595 Burrard Street, Suite 2123
	Vancouver, BC V7X 1J1, Canada		Vancouver, BC V7X 1J1, Canada
	Email: ssalam@cisco.com		Email: ssalam@cisco.com
	Sami Boutros		Sami Boutros
	Cisco		Cisco
	170 West Tasman Drive		170 West Tasman Drive
	San Jose, CA 95134, US		San Jose, CA 95134, US
End of changes. 31 change blocks.
	404 lines changed or deleted		58 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/