< draft-allan-l2vpn-mldp-evpn-00.txt		draft-allan-l2vpn-mldp-evpn-01.txt >
	L2VPN Working Group Dave Allan, Jeff Tantsura		L2VPN Working Group Dave Allan, Jeff Tantsura
	Internet Draft Ericsson		Internet Draft Ericsson
	Intended status: Standards Track		Intended status: Standards Track
	Expires: August 2013		Expires: January 2014
	March 2013		July 2013
	mLDP extensions for integrating EVPN and multicast		mLDP extensions for integrating EVPN and multicast
	draft-allan-l2vpn-mldp-evpn-00		draft-allan-l2vpn-mldp-evpn-01
	Abstract		Abstract
	This document describes how mLDP FECs can be encoded to support both		This document describes how mLDP FECs can be encoded to support both
	service specific and shared multicast trees and describes the		service specific and shared multicast trees and describes the
	associated procedures for EVPN PEs. Thus, mLDP can implement		associated procedures for EVPN PEs. Thus, mLDP can implement
	multicast for EVPN.		multicast for EVPN.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	documents at any time. It is inappropriate to use Internet-		documents at any time. It is inappropriate to use Internet-
	Drafts as reference material or to cite them other than as "work		Drafts as reference material or to cite them other than as "work
	in progress".		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 August 2013.		This Internet-Draft will expire on January 2014.
	Copyright and License Notice		Copyright and License Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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		carefully, as they describe your rights and restrictions with
	respect to this document. Code Components extracted from this		respect to this document. Code Components extracted from this
	document must include Simplified BSD License text as described		document must include Simplified BSD License text as described
	in Section 4.e of the Trust Legal Provisions and are provided		in Section 4.e of the Trust Legal Provisions and are provided
	without warranty as described in the Simplified BSD License.		without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction..........................................2		1. Introduction...................................................2
	1.1. Authors.............................................2		1.1. Authors......................................................2
	1.2. Requirements Language.................................2		1.2. Requirements Language........................................2
	2. Conventions used in this document........................3		2. Changes since last version.....................................3
	2.1. Terminology.........................................3		3. Conventions used in this document..............................3
	3. Solution Overview......................................4		3.1. Terminology..................................................3
	4. Elements of Procedure ..................................4		4. Solution Overview..............................................4
	5. FEC Encoding..........................................5		5. Elements of Procedure..........................................4
	6. Acknowledgements.......................................7		6. FEC Encoding...................................................5
	7. Security Considerations.................................7		6.1. VLAN tagged FEC..............................................5
	8. IANA Considerations....................................7		6.2. I-SID tagged FEC.............................................6
	9. References............................................7		6.3. Shared FEC...................................................6
	9.1. Normative References..................................7		7. Acknowledgements...............................................7
	9.2. Informative References................................7		8. Security Considerations........................................7
	10. Authors' Addresses....................................8		9. IANA Considerations............................................7
			10. References....................................................7
			10.1. Normative References........................................7
			10.2. Informative References......................................8
			11. Authors' Addresses............................................8
	1. Introduction		1. Introduction
	This document describes how mLDP FECs can be encoded to permit mLDP		This document describes how mLDP FECs can be encoded to permit mLDP
	to implement multicast for EVPN. Such support can be applied to		to implement multicast for EVPN. Such support can be applied to
	interconnecting 802.1ad, 802.1ah, 802.1aq, and 802.1Qbp based		interconnecting 802.1ad, 802.1ah, 802.1aq, and 802.1Qbp based
	networks.		networks.
	1.1. Authors		1.1. Authors
	David Allan, Jeff Tantsura		David Allan, Jeff Tantsura
	1.2. Requirements Language		1.2. Requirements Language
	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", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC2119 [1].		document are to be interpreted as described in RFC2119 [1].
	2. Conventions used in this document		2. Changes since last version
	2.1. Terminology		1) Clarifications to the use of FEC encoding for RTs and VLANs
			added to section 6.
			3. Conventions used in this document
			3.1. Terminology
	BCB: Backbone Core Bridge		BCB: Backbone Core Bridge
	BEB: Backbone Edge Bridge		BEB: Backbone Edge Bridge
	BU: Broadcast/Unknown		BU: Broadcast/Unknown
	B-MAC: Backbone MAC Address		B-MAC: Backbone MAC Address
	B-VID: Backbone VLAN ID		B-VID: Backbone VLAN ID
	CE: Customer Edge		CE: Customer Edge
	C-MAC: Customer/Client MAC Address		C-MAC: Customer/Client MAC Address
	DF: Designated Forwarder		DF: Designated Forwarder
	ESI: Ethernet segment identifier		ESI: Ethernet segment identifier
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 6 ¶
	BEB-PE: Co located BEB and PE		BEB-PE: Co located BEB and PE
	PE: provider edge		PE: provider edge
	P2MP: Point to Multipoint		P2MP: Point to Multipoint
	P2P: Point to Point		P2P: Point to Point
	RD: Route Distinguisher		RD: Route Distinguisher
	SPB: Shortest path bridging		SPB: Shortest path bridging
	SPBM: Shortest path bridging MAC mode		SPBM: Shortest path bridging MAC mode
	VID: VLAN ID		VID: VLAN ID
	VLAN: Virtual LAN		VLAN: Virtual LAN
	3. Solution Overview		4. Solution Overview
	mLDP[6] permits arbitrary FEC encodings for the naming of multicast		mLDP[6] permits arbitrary FEC encodings for the naming of multicast
	trees to be defined. This property is leveraged to permit both		trees to be defined. This property is leveraged to permit both
	service specific trees and shared trees to be utilized to augment		service specific trees and shared trees to be utilized to augment
	EVPN unicast connectivity with network based multicast and avoid the		EVPN unicast connectivity with network based multicast and avoid the
	inefficiencies of edge replication.		inefficiencies of edge replication.
	The flooding of EVPN BGP NLRI and ISIS-SPB [7] provides each PE with		The flooding of EVPN BGP NLRI and ISIS-SPB [7] provides each PE with
	sufficient information to self elect as a DF, have knowledge of peer		sufficient information to self elect as a DF, have knowledge of peer
	DFs, and from that construct the identifiers for the required set of		DFs, and from that construct the identifiers for the required set of
	multicast trees to support the current service set, which can then be		multicast trees to support the current service set, which can then be
	encoded as mLDP FECs, and used to originate label mapping and label		encoded as mLDP FECs, and used to originate label mapping and label
	withdraw messages.		withdraw messages.
	Both p2mp and mp2mp trees are supported with different FEC encodings		Both p2mp and mp2mp trees are supported with different FEC encodings
	for each. Service specific tree FECs encode the VID or I-SID		for each. Service specific tree FECs encode the VID or I-SID
	associated with the service instance in the subtending network.		associated with the service instance in the subtending network.
	Shared tree FECs encode a sorted list of the IP addresses of the leaf		Shared tree FECs encode a sorted list of the IP addresses of the leaf
	DFs.		DFs.
	4. Elements of Procedure		5. Elements of Procedure
	A PE advertises whether or not it supports shared tree (actual		A PE advertises whether or not it supports shared tree (actual
	mechanism is TBD). Support of both shared and service specific trees		mechanism is TBD). Support of both shared and service specific trees
	is mandatory. Whether a PE supports shared trees is a network design		is mandatory. Whether a PE supports shared trees is a network design
	decision.		decision.
	A PE is expected to maintain a list of current multicast memberships.		A PE is expected to maintain a list of current multicast memberships.
	A PE, upon receipt of new information from BGP or ISIS-SPB:		A PE, upon receipt of new information from BGP or ISIS-SPB:
	1) Evaluates it"s DF roles (as described in .		1) Evaluates it"s DF roles (as described in [5]).
	[5]).
	2) On the basis of the PE"s DF role, determines the set of services		2) On the basis of the PE"s DF role, determines the set of services
	it needs to support.		it needs to support.
	3) Determines the set of peer DFs for each service.		3) Determines the set of peer DFs for each service.
	4) On the basis of requisite tree types and ESI multicast		4) On the basis of requisite tree types and ESI multicast
	registrations (p2mp or mp2mp/service specific or shared), determines		registrations (p2mp or mp2mp/service specific or shared), determines
	the name of the multicast tree needed for the service.		the name of the multicast tree needed for the service.
	skipping to change at page 5, line 21 ¶		skipping to change at page 5, line 24 ¶
	5) Upon completion of evaluating the set of services, de-duplicates		5) Upon completion of evaluating the set of services, de-duplicates
	the required tree membership list.		the required tree membership list.
	6) Compares the required list with the existing list, and originates		6) Compares the required list with the existing list, and originates
	the necessary label mapping and label withdraw transactions to the		the necessary label mapping and label withdraw transactions to the
	network state up to date.		network state up to date.
	7) Configures the dataplane for the appropriate service to multicast		7) Configures the dataplane for the appropriate service to multicast
	tree bindings.		tree bindings.
	5. FEC Encoding		6. FEC Encoding
	5.1. VLAN tagged FEC		6.1. VLAN tagged FEC
	VLAN tagged FEC uses the mLDP p2mp (0x06) type FEC and the mLDP mp2mp		VLAN tagged FEC uses the mLDP p2mp (0x06) type FEC and the mLDP mp2mp
	downstream (0x07) and upstream FECs (0x08)		downstream (0x07) and upstream FECs (0x08)
	The encoding of the opaque value is:		The encoding of the opaque value is:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type "x" | Length | <unused = 0> |		| Type "x" | Length | <unused = 0> |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| RT |		| RT |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Ethertype | VID | = 0 |		| Ethertype | VID | = 0 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Where:		Where:
	- RT is the route target for the EVPN instance		- RT is the route target for the EVPN instance
	- Ethertype identifies the tag type (C 0x8100, S or B 0x88a8)		- Ethertype identifies the tag type (C 0x8100, S or B 0x88a8)
	- VID is the VLAN ID tag value		- VID is the VLAN ID tag value. If the VID=0, then this is the
			default MDT for the RT and how VLAN unaware RTs are encoded, else it
			permits MDTs to be defined for VLAN aware services.
	5.2. I-SID tagged FEC		6.2. I-SID tagged FEC
	The encoding of the opaque value is:		The encoding of the opaque value is:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type "x+1" | Length | <unused = 0> |		| Type "x+1" | Length | <unused = 0> |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| RT |		| RT |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| I-SID | <unused = 0> |		| I-SID | <unused = 0> |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Where:		Where:
	- RT is the route target for the EVPN instance		- RT is the route target for the EVPN instance
	- I-SID corresponds to the I-SID that will use the tree		- I-SID corresponds to the I-SID that will use the tree
	5.3. Shared FEC		6.3. Shared FEC
	The encoding of the opaque value is:		The encoding of the opaque value is:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type "x+2" | Length | <unused = 0> |		| Type "x+2" | Length | <unused = 0> |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| RT |		| RT |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	skipping to change at page 6, line 38 ¶		skipping to change at page 7, line 4 ¶
	| Type "x+2" | Length | <unused = 0> |		| Type "x+2" | Length | <unused = 0> |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| RT |		| RT |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ <sorted list of DF ip addresses> ~		~ <sorted list of DF ip addresses> ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Where:		Where:
	- RT is the route target for the EVPN instance		- RT is the route target for the EVPN instance
	- Sorted list of DF addresses identifies the set of leaves that have		- Sorted list of DF addresses identifies the set of leaves that have
	registered interest in one or more Ethernet services (either C/S or I		registered interest in one or more Ethernet services (either C/S or I
	tagged).		tagged).
	6. Acknowledgements		7. Acknowledgements
	The authors would like to thank Panagiotis Saltsidis and Janos Farkas		The authors would like to thank Panagiotis Saltsidis, Jakob Heitz and
	for their detailed review of this draft.		Janos Farkas for their detailed review of this draft.
	7. Security Considerations		8. Security Considerations
	For a future version of this document.		For a future version of this document.
	8. IANA Considerations		9. IANA Considerations
	For a future version of this document.		For a future version of this document.
	9. References		10. References
	9.1. Normative References		10.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate		[1] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[2] Fedyk et.al. "IS-IS Extensions Supporting IEEE 802.1aq		[2] Fedyk et.al. "IS-IS Extensions Supporting IEEE 802.1aq
	Shortest Path Bridging", IETF RFC 6329, April 2012		Shortest Path Bridging", IETF RFC 6329, April 2012
	[3] Rosen et.al., "BGP/MPLS IP Virtual Private Networks		[3] Rosen et.al., "BGP/MPLS IP Virtual Private Networks
	(VPNs)", IETF RFC 4364, February 2006		(VPNs)", IETF RFC 4364, February 2006
	skipping to change at page 7, line 42 ¶		skipping to change at page 8, line 5 ¶
	in progress, draft-ietf-l2vpn-evpn-01, July 2012		in progress, draft-ietf-l2vpn-evpn-01, July 2012
	[5] Allan et.al. "802.1aq and 802.1Qbp Support over EVPN",		[5] Allan et.al. "802.1aq and 802.1Qbp Support over EVPN",
	IETF work in progress, draft-allan-l2vpn-spb-evpn-03,		IETF work in progress, draft-allan-l2vpn-spb-evpn-03,
	February 2013		February 2013
	[6] Wijnands et.al. "Label Distribution Protocol Extensions		[6] Wijnands et.al. "Label Distribution Protocol Extensions
	for Point-to-Multipoint and Multipoint-to-Multipoint Label		for Point-to-Multipoint and Multipoint-to-Multipoint Label
	Switched Paths". IETF RFC 6388, November 2011		Switched Paths". IETF RFC 6388, November 2011
	9.2. Informative References		10.2. Informative References
	[7] IEEE 802.1aq "IEEE Standard for Local and Metropolitan		[7] IEEE 802.1aq "IEEE Standard for Local and Metropolitan
	Area Networks: Bridges and Virtual Bridged Local Area		Area Networks: Bridges and Virtual Bridged Local Area
	Networks - Amendment 9: Shortest Path Bridging", June 2012		Networks - Amendment 9: Shortest Path Bridging", June 2012
	[8] IEEE 802.1Qbp "Draft IEEE Standard for Local and		[8] IEEE 802.1Qbp "Draft IEEE Standard for Local and
	Metropolitan Area Networks---Virtual Bridged Local Area		Metropolitan Area Networks---Virtual Bridged Local Area
	Networks - Amendment: Equal Cost Multiple Paths (ECMP),		Networks - Amendment: Equal Cost Multiple Paths (ECMP),
	802.1Qbp", draft 1.3, February 2013		802.1Qbp", draft 1.3, February 2013
	[9] Sajassi et.al. "PBB E-VPN", IETF work in progress, draft-		[9] Sajassi et.al. "PBB E-VPN", IETF work in progress, draft-
	ietf-l2vpn-pbb-evpn-03, June 2012		ietf-l2vpn-pbb-evpn-03, June 2012
	[10] IEEE 802.1Q-2011 "IEEE Standard for Local and metropolitan		[10] IEEE 802.1Q-2011 "IEEE Standard for Local and metropolitan
	area networks--Media Access Control (MAC) Bridges and		area networks--Media Access Control (MAC) Bridges and
	Virtual Bridged Local Area Networks", August 2011		Virtual Bridged Local Area Networks", August 2011
	10. Authors' Addresses		11. Authors' Addresses
	Dave Allan (editor)		Dave Allan (editor)
	Ericsson		Ericsson
	300 Holger Way		300 Holger Way
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: david.i.allan@ericsson.com		Email: david.i.allan@ericsson.com
	Jeff Tantsura		Jeff Tantsura
	Ericsson		Ericsson
End of changes. 23 change blocks.
	39 lines changed or deleted		50 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/