< draft-ietf-pwe3-p2mp-pw-02.txt		draft-ietf-pwe3-p2mp-pw-03.txt >
	Internet Engineering Task Force Sami Boutros		Network Working Group Siva Sivabalan (Ed.)
	Internet Draft Luca Martini		Internet Draft Sami Boutros (Ed.)
	Expiration Date: September 2011 Siva Sivabalan		Intended status: Standards Track Luca Martini
	Intended status: Standards Track Cisco		Expires: April 15, 2012 Cisco Systems
	Maciek Konstantynowicz
	Juniper
	Frederic Jounay Gianni Del Vecchio		Frederic Jounay Maciek Konstantynowicz
	Philippe Niger Swisscom		Philippe Niger Juniper
	France Telecom		France Telecom
	Thomas D. Nadeau Yuji Kamite		Thomas D. Nadeau Gianni Del Vecchio
	Huawei NTT Communications		CA Technologies Swisscom
	Simon Delord Lizhong Jin		Simon Delord Yuji Kamite
	Telstra ZTE		Telstra NTT Communications
	Laurent Ciavaglia		Laurent Ciavaglia Lizhong Jin
	Martin Vigoureux		Martin Vigoureux ZTE
	Alcatel-Lucent		Alcatel-Lucent
	March 2, 2011		October 27, 2011
	Signaling Root-Initiated Point-to-Multipoint Pseudowires using LDP
	draft-ietf-pwe3-p2mp-pw-02.txt		Signaling Root-Initiated Point-to-Multipoint Pseudowire using LDP
			draft-ietf-pwe3-p2mp-pw-03.txt
	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 Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html
	This Internet-Draft will expire on September 2, 2010		This Internet-Draft will expire on April 27, 2012.
	Abstract		Abstract
	This document specifies a mechanism to signal Point-to-Multipoint		This document specifies a mechanism to signal Point-to-Multipoint
	(P2MP) Pseudowires (PW) tree using LDP. Such a mechanism is suitable		(P2MP) Pseudowires (PW) tree using LDP. Such a mechanism is suitable
	for any Layer 2 VPN service requiring P2MP connectivity over an IP or		for any Layer 2 VPN service requiring P2MP connectivity over an IP or
	MPLS-enabled PSN. A P2MP PW established via the proposed mechanism is		MPLS enabled PSN. A P2MP PW established via the proposed mechanism is
	root initiated.		root initiated.
	Table of Contents		Table of Contents
	1 Specification of Requirements ........................ 3		1. Introduction...................................................2
	2 Introduction ......................................... 3		2. Terminology....................................................4
	3 Terminology .......................................... 4		3. Signaling P2MP PW..............................................5
	4 Signaling the P2MP PW ................................ 5		3.1. PW ingress to egress incompatibility issues...............6
	4.1 PW ingress to egress incompatibility issues .......... 6		3.2. P2MP PW FEC...............................................7
	4.2 P2MP PW FEC Element .................................. 7		3.3. Group ID usage...........................................11
	4.3 Group ID usage ....................................... 9		3.4. Generic Label TLV........................................11
	4.4 Generic Label TLV .................................... 9		3.5. Transport LSP TLV........................................12
	4.5 Transport LSP TLV .................................... 10		4. LDP Capability Negotiation....................................13
	5 LDP Capability Negotiation ........................... 12		5. P2MP PW Status................................................15
	6 P2MP PW status ....................................... 13		6. Security Considerations.......................................15
	7 Security Considerations .............................. 13		7. IANA Considerations...........................................15
	8 IANA Considerations .................................. 13		7.1. FEC Type Name Space......................................15
	8.1 FEC Type Name Space .................................. 13		7.2. LDP TLV Type.............................................16
	8.2 LDP TLV TYPE ......................................... 14		7.3. mLDP Opaque Value Element TLV Type.......................16
	8.3 mLDP Opaque Value Element TLV TYPE ................... 14		7.4. Selective Tree Interface Parameter sub-TLV Type..........16
	9 References ........................................... 14		8. Acknowledgment................................................17
	9.1 Normative References ................................. 14		9. References....................................................17
	9.2 Informative References ............................... 15		9.1. Normative References.....................................17
	10 Author's Addresses ................................... 16		9.2. Informative References...................................18
			Full Copyright Statement.........................................21
	1. Specification of Requirements		Intellectual Property Statement..................................21
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].
	2. Introduction		1. Introduction
	A Point-to-Multipoint (P2MP) Pseudowire (PW) emulates the essential		A Point-to-Multipoint (P2MP) Pseudowire (PW) emulates the
	attributes of a unidirectional P2MP Telecommunications service such		essential attributes of a unidirectional P2MP Telecommunications
	as P2MP ATM over PSN. A major difference between a Point-to-Point		service such as P2MP ATM over PSN. A major difference between a
	(P2P) PW outlined in [RFC3985] and a P2MP PW is that the former is		Point-to-Point (P2P) PW outlined in [RFC3985] and a P2MP PW is that
	intended for bidirectional service whereas the latter is intended for		the former is intended for bidirectional service whereas the latter
	both unidirectional, or optionally bidirectional service.		is intended for both unidirectional and bidirectional services.
	Requirements for P2MP PW are described in [P2MP-PW-REQ].		Requirements for P2MP PW are described in [P2MP-PW-REQ].
	P2MP PW can be constructed as either Single Segment (P2MP SS-PW) or		A P2MP PW can be constructed as either Single Segment (P2MP SS-PW)
	Multi Segment (P2MP MS-PW) Pseudowires as mentioned in [P2MP-PW-REQ].		or Multi Segment (P2MP MS-PW) Pseudowire as mentioned in [P2MP-PW-
	P2MP MS-PW is outside the scope of this document. A reference model		REQ]. P2MP MS-PW is outside the scope of this document. A reference
	for P2MP PW is depicted in Figure 1 below. A transport LSP associated		model for P2MP PW is depicted in Figure 1 below. A transport LSP
	with a P2MP SS-PW SHOULD be a P2MP MPLS LSP (i.e., P2MP TE tunnel		associated with a P2MP SS-PW SHOULD be a P2MP MPLS LSP (i.e., P2MP
	established via RSVP-TE [RFC4875] or P2MP LSP established via mLDP		TE tunnel established via RSVP-TE [RFC4875] or P2MP LSP established
	[mLDP]) spanning from the Root-PE to the Leaf-PE(s) of the P2MP SS-PW		via mLDP [mLDP]) spanning from the Root-PE (R-PE) to the Leaf-PE(s)
	tree. For example, in Figure 1, PW1 can be associated with a P2MP TE		(L-PEs) of the P2MP SS-PW tree. For example, in Figure 1, PW1 can be
	tunnel or P2MP LSP setup using [mLDP] originating from PE1 and		associated with a P2MP TE tunnel or P2MP LSP setup using [mLDP]
	terminating at PE2 and PE3.		originating from T-PE1 and terminating at T-PE2 and T-PE3.
			Mechanisms for establishing P2P SS-PW using LDP are described in
			[RFC4447]. In this document, we specify a method to signal P2MP PW
			using LDP. In particular, we define new TLVs, parameters, and status
			codes to facilitate LDP to signal and maintain P2MP PWs.
	|<--------------P2MP PW---------------->|		|<--------------P2MP PW---------------->|
	Native | | Native		Native | | Native
	Service | |<--PSN1->| |<--PSN2->| | Service		Service | |<--PSN1->| |<--PSN2->| | Service
	(AC) V V V V V V (AC)		(AC) V V V V V V (AC)
	| +-----+ +------+ +------+ |		| +-----+ +------+ +------+ |
	| | | | P1 |=========|T-PE2 |AC3 | +---+		| | | | P1 |=========|T-PE2 |AC3 | +---+
	| | | | .......PW1.........>|-------->|CE3|		| | | | .......PW1.........>|-------->|CE3|
	| |T-PE1|=========| . |=========| | | +---+		| |T-PE1|=========| . |=========| | | +---+
	| | .......PW1........ | +------+ |		| | .......PW1........ | +------+ |
	skipping to change at page 4, line 27 ¶		skipping to change at page 4, line 5 ¶
	|CE1|------->|... | | |=========| | | +---+		|CE1|------->|... | | |=========| | | +---+
	+---+ | | . | +------+ +------+ |		+---+ | | . | +------+ +------+ |
	| | . | +------+ +------+ |		| | . | +------+ +------+ |
	| | . |=========| P2 |=========|T-PE4 |AC5 | +---+		| | . |=========| P2 |=========|T-PE4 |AC5 | +---+
	| | .......PW1..............PW1.........>|-------->|CE5|		| | .......PW1..............PW1.........>|-------->|CE5|
	| | |=========| |=========| | | +---+		| | |=========| |=========| | | +---+
	| +-----+ +------+ +------+ |		| +-----+ +------+ +------+ |
	Figure 1: P2MP PW		Figure 1: P2MP PW
	Mechanisms for establishing P2P SS-PW using LDP are described in		As outlined in [P2MP-PW-REQ], even though the traffic flow from an
	[RFC4447]. In this document, we specify a method to signal P2MP PW		R-PE to L-PEs is P2MP in nature, it may be desirable for any L-PE to
	using LDP. In particular, we define new TLVs, parameters, and status		send unidirectional P2P traffic destined only to the R-PE. The
	codes to facilitate LDP to signal and maintain P2MP PWs.		proposed mechanism takes such option into consideration.
	Note that even though the traffic flow from a Root-PE to Leaf-PE(s)		A P2MP PW requires an MPLS LSP to carry the PW traffic, and the MPLS
	is P2MP in nature, it may be desirable for any Leaf-PE to send		packets carried over the PW will be encapsulated according to the
	unidirectional P2P traffic destined only to the Root-PE. The proposed		methods described in [RFC5332].
	mechanism takes such an option into consideration.
	The P2MP PW requires an MPLS LSP to carry the PW traffic. the PW MPLS		Conventions used in this document
	packet will be encapsulated according to the methods described in
	[RFC5332].
	3. Terminology		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in RFC-2119 [RFC2119].
	FEC: Forwarding Equivance Class		2. Terminology
			FEC: Forwarding Equivalence Class
	LDP: Label Distribution Protocol		LDP: Label Distribution Protocol
	mLDP: Label Distribution Protocol for P2MP LSP		mLDP: Label Distribution Protocol for P2MP LSP
	LSP: Label Switching Path		LSP: Label Switching Path
	MS-PW: Multi-Segment Pseudowire		MS-PW: Multi-Segment Pseudowire
	P2P: Point to Point		P2P: Point to Point
	P2MP: Point to Multipoint		P2MP: Point to Multipoint
	PE: Provider Edge		PE: Provider Edge
	PSN: Packet Switched Network		PSN: Packet Switched Network
	skipping to change at page 5, line 19 ¶		skipping to change at page 5, line 4 ¶
	PE: Provider Edge		PE: Provider Edge
	PSN: Packet Switched Network		PSN: Packet Switched Network
	PW: Pseudowire		PW: Pseudowire
	SS-PW: Single-Segment Pseudowire		SS-PW: Single-Segment Pseudowire
	S-PE: Switching Provider Edge Node of MS-PW		S-PE: Switching Provider Edge Node of MS-PW
	TE: Traffic Engineering		TE: Traffic Engineering
	R-PE: Root-PE - ingress PE, PE initiating P2MP PW setup.		R-PE: Root-PE - ingress PE, PE initiating P2MP PW setup.
	L-PE: Leaf-PE - egress PE.		L-PE: Leaf-PE - egress PE.
	4. Signaling the P2MP PW		3. Signaling P2MP PW
	In order to advertise labels as well as exchange PW related LDP		In order to advertise labels as well as exchange PW related LDP
	messages, PEs must establish LDP sessions among themselves using the		messages, PEs must establish LDP sessions among themselves using the
	Extended Discovery Mechanisms. A PE discovers other PEs that are to		Extended Discovery Mechanisms. A PE discovers other PEs that are to
	be connected via P2MP PWs either via manual configuration or		be connected via P2MP PWs either via manual configuration or
	autodiscovery [RFC6074].		autodiscovery [RFC6074].
	Root-PE and each Leaf-PE MUST be configured with the same FEC as		R-PE and each L-PE MUST be configured with the same FEC as defined
	defined in the following section.		in the following section.
	P2MP PW requires that there is an active P2MP PSN LSP set up between		P2MP PW requires that there is an active P2MP transport LSP set up
	Root-PE and Leaf-PE(s). Note that the procedure to set up the P2MP		between R-PE and L-PE(s). The procedure to set up the P2MP transport
	PSN LSP is different depending on the protocol used: RSVP-TE or mLDP.		LSP is different depending on the protocol used (RSVP-TE or mLDP).
	In case of mLDP a Leaf-PE can decide to join the P2MP LSP at any		In case of mLDP, an L-PE can decide to join the P2MP LSP at any
	time, while in case of RSVP-TE the P2MP LSP is set up by the Root-PE,		time, while in the case of RSVP-TE the P2MP transport LSP is set up
	generally at the initial service provisioning time. It should be		by the R-PE, generally at the initial service provisioning time. It
	noted that local policy can override any decision to join, add or		should be noted that local policy can override any decision to add
	prune existing or new Leaf-PE(s) from the tree.		or prune existing or new L-PE(s) to/from the tree. In any case, the
			PW setup can ignore these differences, and simply assume that the
			P2MP transport LSP is available when needed.
	In any case the PW setup can ignore these differences, and simply		A P2MP PW signaling is initiated by the R-PE simply by sending a
	assume that the P2MP tunnel is available when needed.		P2MP-PW LDP label mapping message to the L-PE(s) belonging to that
			P2MP PW. This label mapping message will contain the following:
	The P2MP PW is initiated by the root (source) Provider Edge router		1. A P2MP Upstream PW FEC element.
	(R-PE), by simply sending an P2MP-PW LDP label mapping message to all		2. An Interface Parameters TLV, as described in [RFC4447].
	the Leaf Provider Edge routers L-PEs. This label mapping message will		3. A PW Grouping TLV as described in [RFC4447].
	contain the following:		4. A Transport LSP TLV.
	-i. P2MP PW FEC element.		5. A label TLV for the upstream-assigned label used by R-PE
	-ii. an Interface Parameters TLV, as described in [RFC4447] sec		for the traffic going from R-PE to L-PE(s).
	5.3.2.1
	-iii. a PW Grouping TLV, as described in [RFC4447] sec 5.3.2.2
	-iv. a Transport LSP TLV.
	-v. a label TLV for the upstream-assigned label R-PE to L-PE
	direction.
	-vi. MAY contain a downstream-assigned label for the L-PE to R-PE
	direction.
	The LDP liberal label retention mode is used, and per [RFC5036]		The R-PE imposes the upstream-assigned label on the outbound packets
	requirement the label request message MUST also be supported.		sent over the P2MP-PW, and using this label an L-PE identifies the
			inbound packets arriving over the P2MP PW.
	The Upstream-assigned label is allocated according to the rules in		Additionally, the R-PE MAY send label mapping message(s) to one or
	[RFC5331].		more L-PE(s) to signal unidirectional P2P PW(s). The L-PE(s) can use
			such PW(s) to send traffic to the R-PE. This optional label mapping
			message will contain the following:
	When a Leaf-PE receives a PW Label Mapping Message, it MUST verify		1. P2P Downstream PW FEC element.
	the associated P2MP transport LSP is in place.		2. A label TLV for the down-stream assigned label used by the
			corresponding L-PE to send traffic to the R-PE.
	If the associated transport P2MP LSP is not in place, and the		The LDP liberal label retention mode is used, and per requirements
	transport LSP TLV type is LDP P2MP LSP, a Leaf-PE SHOULD attempt to		specified in [RFC5036], the label request message MUST also be
	join the P2MP transport associated with the P2MP PW.		supported.
	If the associated transport P2MP LSP is not in place, and the		The upstream-assigned label is allocated according to the rules in
	transport LSP TLV type is RSVP-TE P2MP LSP, a Leaf-PE SHOULD await		[RFC5331].
	RSVP-TE P2MP LSP signaling from the Root-PE.
	4.1. PW ingress to egress incompatibility issues		When an L-PE receives a PW Label Mapping Message, it MUST verify
			that the associated P2MP transport LSP is in place. If the
			associated P2MP transport LSP is not in place, and its type is LDP
			P2MP LSP, the L-PE SHOULD attempt to join the P2MP LSP. If the P2MP
			transport LSP is not in place, and its type is RSVP-TE P2MP LSP, the
			L-PE SHOULD wait till the P2MP transport LSP is signaled.
	If a Root-PE signals a PW with a pw type, CW mode, or interface		3.1. PW ingress to egress incompatibility issues
	parameters that a particular Leaf-PE cannot accept, then the L-PE
	must simply not enable the PW, and notify the user. In this case a PW		If an R-PE signals a PW with a pw type, CW mode, or interface
	status message of 0x00000001 - Pseudowire Not Forwarding MUST also be		parameters that a particular L-PE cannot accept, then the L-PE must
	sent to the R-PE.		not enable the PW, and notify the user. In this case, a PW status
			message of 0x00000001 (Pseudowire Not Forwarding) MUST also be sent
			to the R-PE.
	Note that this procedure does not apply if the L-PE had not been		Note that this procedure does not apply if the L-PE had not been
	provisioned with this particular P2MP PW. In this case according to		provisioned with this particular P2MP PW. In this case according to
	the LDP liberal label retention rules, no action is taken.		the LDP liberal label retention rules, no action is taken.
	4.2. P2MP PW FEC Element		3.2. P2MP PW FEC
	[RFC4447] specifies two types of LDP FEC elements called "PWid FEC		[RFC4447] specifies two types of LDP FEC elements called "PWid FEC
	Element" and "Generalized PWid FEC Element" used to signal P2P PWs.		Element" and "Generalized PWid FEC Element" used to signal P2P PWs.
	We define a new type of FEC element called "P2MP PW FEC Element"		We define two new types of FEC element called "P2MP Upstream PW FEC
	whose type is 0x82 (Pending IANA Allocation) and is encoded as		Element" and "P2P Downstream PW FEC Element". These FEC elements are
	follows:		associated with a mandatory upstream assigned label and an optional
			downstream assigned label respectively.
			FEC type of the P2MP Upstream PW FEC Element is 0x82 (pending IANA
			allocation) and is encoded as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|FEC Type = 0x82|C| PW Type | PW Info Length|		|FEC Type = 0x82|C| PW Type | PW Info Length|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| AGI Type | Length | AGI Value |		| AGI Type | Length | AGI Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ AGI Value (contd.) ~		~ AGI Value (contd.) ~
	| |		| |
	skipping to change at page 7, line 40 ¶		skipping to change at page 7, line 44 ¶
	| Reserved |PMSI Tunnel Typ| Transport LSP ID |		| Reserved |PMSI Tunnel Typ| Transport LSP ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Transport LSP ID (contd.) ~		~ Transport LSP ID (contd.) ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Optional Parameters |		| Optional Parameters |
	~ ~		~ ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: P2MP PW FEC Element		Figure 2: P2MP Upstream PW FEC Element
	* PW Type:		* PW Type:
	15-bit representation of PW type, and the assigned values are		15-bit representation of PW type, and the assigned values are
	assigned by IANA.		assigned by IANA.
	* C bit:		* C bit:
	A value of 1 or 0 indicates whether control word is present or		A value of 1 or 0 indicates whether control word is present or
	absent for the P2MP PW.		absent for the P2MP PW.
	* PW Info Length:		* PW Info Length:
			Sum of the lengths of AGI, SAII and Optional Parameters field in
	Sum of the lengths of AGI, SAII and Optional Parameters field in		octets. If this value is 0, then it references all PWs using the
	octets. If this value is 0, then it references all PWs using the		specified grouping ID. In this case, there are neither other FEC
	specified grouping ID. In this case, there are no other FEC		element fields (AGI, SAII, etc.) present, nor any interface
	element fields (AGI, SAII, etc.) present, nor any interface		parameters TLVs.
	parameters TLVs.
	* AGI:		* AGI:
	Attachment Group Identifier can be used to uniquely identify VPN		Attachment Group Identifier can be used to uniquely identify VPN
	or VPLS instance associated with the P2MP PW. This has the same		or VPLS instance associated with the P2MP PW. This has the same
	format as that of the Generalized PWid FEC element [RFC4447].		format as the Generalized PWid FEC element [RFC4447].
	* SAII:		* SAII:
	Source Attachment Individual Identifier is used to identify the		Source Attachment Individual Identifier is used to identify the
	root of the P2MP PW. The root is represented using AII type 2		root of the P2MP PW. The root is represented using AII type 2
	format specified in [RFC5003]. Note that the SAII can be omitted		format specified in [RFC5003]. Note that the SAII can be omitted
	by simply setting the length and type to zero.		by simply setting the length and type to zero.
	P2MP PW is identified by the Source Attachment Identifier (SAI).		P2MP PW is identified by the Source Attachment Identifier (SAI).
	If the AGI is non-null, the SAI is the combination of the SAII		If the AGI is non-null, the SAI is the combination of the SAII
	and the AGI, if the AGI is null, the SAI is the SAII.		and the AGI, if the AGI is null, the SAI is the SAII.
	* Transport LSP TLV:		* Transport LSP TLV:
	A P2MP PW MUST be associated with a transport LSP. The Transport		A P2MP PW MUST be associated with a transport LSP. The Transport
	LSP TLV contains the information required to identify the		LSP TLV contains the information required to identify the
	transport LSP. Note that the Transport LSP TLV MUST immediately		transport LSP. Transport LSP TLV MUST immediately follow the FEC,
	follow the FEC , but is not part of the FEC, and SHOULD NOT be		but is not part of the FEC, and SHOULD NOT be used in other
	used in other messages where the FEC is used.		messages where the FEC is used.
	* Optional Parameters:		* Optional Parameters:
	The Optional Parameter field can contain some TLVs that are not		The Optional Parameter field can contain some TLVs that are not
	part of the FEC, but are necessary for the operation of the PW.		part of the FEC, but are necessary for the operation of the PW.
	This document defines two such parameters: Interface Parameters		This proposed mechanism uses two such TVLs: Interface Parameters
	TLV, and Group ID TLV.		TLV and Group ID TLV.
	The Interface Parameters TLV and Group ID TLV specified in [RFC4447]		The Interface Parameters TLV and Group ID TLV specified in
	can also be used in conjunction with P2MP PW FEC. For Group ID TLV		[RFC4447] can also be used in conjunction with P2MP PW FEC. For
	the sender and receiver of these TLVs should follow the same rules		Group ID TLV the sender and receiver of these TLVs should follow
	and procedures specified in [RFC4447]. For Interface Parameters TLV		the same rules and procedures specified in [RFC4447]. For
	the procedure differs from the one specified in [RFC4447] due to		Interface Parameters TLV the procedure differs from the one
	specifics of P2MP connectivity. When the interface parameters are		specified in [RFC4447] due to specifics of P2MP connectivity. When
	signaled by the Root-PE, the Leaf-PE must check if its configured		the interface parameters are signaled by an R-PE, each L-PE must
	value(s) is less than or equal to the threshold value provided by the		check if its configured value(s) is less than or equal to the
	Root-PE (e.g. MTU size (Ethernet), max number of concatenated ATM		threshold value provided by the R-PE (e.g., MTU size (Ethernet),
	cells, etc)). For other interface parameters like CEP/TDM Payload		max number of concatenated ATM cells, etc)). For other interface
	bytes (TDM), the value MUST match exactly the the one signaled by the		parameters like CEP/TDM Payload bytes (TDM), the value MUST
	Root-PE.		exactly match the values signaled by the R-PE.
	Note that since the LDP label mapping message is only sent by the R-		Multicast traffic stream associated with a P2MP PW can be
	PE to all the L-PEs it is not possible to negotiate any interface		selective or inclusive. To support the former, this document
	parameters.		defines a new optional Selective Tree Interface Parameter sub-TLV
			(type is pending IANA allocation) according to the format
			described in [RFC4447]. The value of the sub-TLV contains the
			source and the group for a given multicast tree as shown in Figure
			3. This is similar to the way (S, G) is defined in [VPLS-MCAST].
			Also, if a P2MP PW is associated with multiple selective trees,
			the corresponding label mapping message will carry more than one
			instances of this Sub-TLV. Furthermore, in the absence of this
			sub-TLV, the P2MP PW is associated with all multicast traffic
			stream originating from the root.
	4.3. Group ID usage		+----------------------------------------- +
			| Multicast Source Length (1 Octet) |
			+----------------------------------------- +
			| Multicast Source (variable length) |
			+----------------------------------------- +
			| Multicast Group Length (1 Octet) |
			+----------------------------------------- +
			| Multicast Group (variable length) |
			+----------------------------------------- +
	The Grouping TLV as defined in [RFC4447] contains a group ID capable		Figure 3: Selective Tree Interface Parameter Sub-TLV Value
	of indicating an arbitrary group membership of a P2MP-PW. This group
	ID can be used in LDP "wild card" status, and withdraw label
	messages, as described in [RFC4447].
	4.4. Generic Label TLV		The Multicast Source field contains the address of the multicast
			source. The Multicast Source field contains an IPv4 address or IPv6
			address depending on whether the Multicast Source Length is 32 or
			128. The Multicast Source Length can be set to 0 to indicate
			wildcard.
	For a given P2MP PW, a single upstream-assigned label is allocated by		The Multicast Group field contains the address of the multicast
	the Root-PE, and is advertised to all Leaf-PEs using the Generic		group. The Multicast Group field contains an IPv4 address or IPv6
	Label TLV in the label mapping message containing the P2MP PW FEC		address depending on whether the Multicast Group Length is 32 or
	element. The Root-PE imposes the upstream-assigned label on the		128. The Multicast Group Length can be set to 0 to indicate
	outbound packets sent over the P2MP-PW, and using this label a Leaf-		wildcard.
	PE identifies the inbound packets arriving over the P2MP PW. Even
	though the P2MP PW is unidirectional, it may be possible for a Root-
	PE to receive traffic from any Leaf-PE using a unidirectional P2P PW
	in the reverse direction as outlined in [P2MP-PW-REQ]. For this
	purpose, the Root-PE can also allocate a unique downstream-assigned
	label for each Leaf-PE from which it is intended to receive P2P
	traffic. In other words, Label Mapping Message for a P2MP PW from a
	Root-PE to a Leaf-PE MUST carry a upstream-assigned label and MAY
	carry an OPTIONAL downstream-assigned label.
	As in the case of P2P PW signaling, P2MP PW labels are carried within		Note that since the LDP label mapping message is only sent by an R-
	Generic Label TLV contained in LDP Label Mapping Message. A Generic		PE to all the L-PEs, it is not possible to negotiate any interface
	Label TLV is formatted and processed as per the rules and procedures		parameters.
	specified in [RFC4447]. But, as mentioned above, a Label Mapping
	Message for a P2MP PW can have up to two Generic Label TLVs; one for		The type of optional P2P Downstream PW FEC Element is 0x83 (pending
	upstream-assigned label (always) and another for downstream-assigned		IANA allocation), and is encoded as follows:
	label (optional). In the case of two Generic Label TLVs, the first
	TLV (from the beginning of the message) carries upstream-assigned
	label and the next generic label TLV carries the downstream-assigned
	label as shown below:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0|0| Generic Label (0x0200) | Length |		|FEC Type = 0x83|C| PW Type | PW Info Length|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Upstream-assigned P2MP Label (mandatory) |		| AGI Type | Length | AGI Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0|0| Generic Label (0x0200) | Length |		~ AGI Value (contd.) ~
			| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Downstream-assigned P2P Label (optional) |		| AII Type | Length | SAII Value |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			~ SAII Value (contd.) ~
			| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Generic Label TLVs in P2MP PW Label Mapping Message		Figure 4: P2P Downstream PW FEC Element
	Note that other type of TLVs may appear between the above generic		The definition of the fields in the P2P Downstream PW FEC Element is
	label TLVs, however any other generic label TLV MUST NOT appear		the same as those of P2MP Upstream PW FEC Element.
	between the upstream-assigned P2MP Label TLV, and downstream-assigned
	P2P Label TLV.
	4.5. Transport LSP TLV		3.3. Group ID usage
			The Grouping TLV as defined in [RFC4447] contains a group ID capable
			of indicating an arbitrary group membership of a P2MP-PW. This group
			ID can be used in LDP "wild card" status, and withdraw label
			messages, as described in [RFC4447].
			3.4. Generic Label TLV
			As in the case of P2P PW signaling, P2MP PW labels are carried
			within Generic Label TLV contained in LDP Label Mapping Message. A
			Generic Label TLV is formatted and processed as per the rules and
			procedures specified in [RFC4447]. For a given P2MP PW, a single
			upstream-assigned label is allocated by the R-PE, and is advertised
			to all the L-PEs using the Generic Label TLV in label mapping
			message containing the P2MP Upstream PW FEC element.
			The R-PE MAY also allocate a unique label for each L-PE from which
			it intends to receive P2P traffic. Such a label is advertised to the
			L-PE using Generic Label TLV in label mapping message.
			3.5. Transport LSP TLV
	A P2MP PW MUST be associated with a transport LSP which can be		A P2MP PW MUST be associated with a transport LSP which can be
	established using RSVP-TE or mLDP. Thus, a Label Mapping Message MUST		established using RSVP-TE or mLDP. Thus, a Label Mapping Message
	contain the identity of the transport LSP. For this purpose, this		MUST contain the identity of the transport LSP. For this purpose,
	specification introduces a new TLV called "Transport LSP TLV" which		this specification introduces a new TLV called "Transport LSP TLV"
	has the following format:		which has the following format:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0|0| Transport LSP TLV (0x0971)| Length |		|0|0| Transport LSP TLV (0x0971)| Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved |PMSI Tunnel Typ| Tunnel Identifier |		| Reserved |PMSI Tunnel Typ| Tunnel Identifier |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Tunnel Identifier (contd.) ~		~ Tunnel Identifier (contd.) ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: Transport LSP TLV		Figure 5: Transport LSP TLV
	Note: TLV number pending IANA allocation.		Note: TLV number pending IANA allocation.
	* Reserved Flags:		* Reserved Flags:
	Reserved bits Must be set to 0 when transmitting the message, and		Reserved bits Must be set to 0 when transmitting the message, and
	ignored on receiving the message.		ignored on receiving the message.
	* PMSI Tunnel Type:		* PMSI Tunnel Type:
	The Transport LSP Type identifies the type of technology used to		The Transport LSP Type identifies the type of technology used to
	establish a transport LSP. The PMSI tunnel type is defined in		establish a transport LSP. The PMSI tunnel type is defined in
	[L3VPN-MCAST].		[L3VPN-MCAST].
	When the type is set to mLDP P2MP LSP, the Tunnel Identifier is a		When the type is set to mLDP P2MP LSP, the Tunnel Identifier is
	P2MP FEC Element as defined in [mLDP]. A new mLDP Opaque Value		a P2MP FEC Element as defined in [mLDP]. A new mLDP Opaque Value
	Element type for L2VPN-MCAST application needs to be allocated.		Element type for L2VPN-MCAST application needs to be allocated.
	Editor Comment: The content of the Opaque Value Element TLV is a		Editor Comment: The content of the Opaque Value Element TLV is a
	TBD.		TBD.
	* Tunnel Identifier:		* Tunnel Identifier:
	The Tunnel containing the Transport LSP is identified by the		The Tunnel containing the Transport LSP is identified by the
	Tunnel Identifier which is defined in [L3VPN-MCAST].		Tunnel Identifier which is defined in [L3VPN-MCAST].
	Transport LSP TLV MUST be present only in the Label Mapping Message.		Transport LSP TLV MUST be present only in the Label Mapping
	An Root-PE sends Label Mapping Message as soon as the transport LSP		Message. An R-PE sends Label Mapping Message as soon as the
	ID associated with the P2MP PW is known (e.g., via configuration)		transport LSP ID associated with the P2MP PW is known (e.g., via
	regardless of the operational state of the transport LSP. Similarly,		configuration) regardless of the operational state of that
	a Root-PE does not withdraw the labels when the corresponding		transport LSP. Similarly, an R-PE does not withdraw the labels
	transport LSP goes down. Furthermore, a Leaf-PE retains the P2MP PW		when the corresponding transport LSP goes down. Furthermore, an
	labels regardless of the operational status of the transport LSP.		L-PE retains the P2MP PW labels regardless of the operational
			status of the transport LSP.
	Note that a given transport LSP can be associated with more than one		Note that a given transport LSP can be associated with more than one
	P2MP PW and all P2MP PWs will be sharing the same Root-PE and Leaf-		P2MP PWs and all P2MP PWs will be sharing the same R-PE and L-PE(s).
	PE(s).
	In the case of LDP P2MP LSP, when a Leaf-PE receives the Label		In the case of LDP P2MP LSP, when an L-PE receives the Label
	Mapping Message, it can initiate the process of joining the P2MP LSP		Mapping Message, it can initiate the process of joining the P2MP LSP
	tree associated with the P2MP PW.		tree associated with the P2MP PW.
	In the case of RSVP-TE P2MP LSP, only the Root-PE initiates the		In the case of RSVP-TE P2MP LSP, only the R-PE initiates the
	signaling of P2MP LSP.		signaling of P2MP LSP.
	5. LDP Capability Negotiation		4. LDP Capability Negotiation
	The capability of supporting P2MP PW must be advertised to all LDP		The capability of supporting P2MP PW must be advertised to all LDP
	peers. This is achieved by using the methods in [RFC5561] and		peers. This is achieved by using the methods in [RFC5561] and
	advertising the P2MP PW LDP capability TLV. If an LDP peer supports		advertising the P2MP PW LDP capability TLV. If an LDP peer supports
	the dynamic capability advertisement, this can be done by sending a		the dynamic capability advertisement, this can be done by sending a
	new capability message with the S bit set for the P2MP PW capability		new capability message with the S bit set for the P2MP PW capability
	TLV. If the peer does not support dynamic capability advertisement,		TLV. If the peer does not support dynamic capability advertisement,
	then the P2MP PW TLV MUST be included in the LDP initialization		then the P2MP PW TLV MUST be included in the LDP initialization
	procedures in the capability parameter [RFC5561].		procedures in the capability parameter [RFC5561]. An LSR having P2MP
			PW capability MUST recognize both P2MP Upstream FEC Element and P2P
			Downstream FEC Element in LDP Label Binding Message.
	In line with requirements listed in [RFC5561] the following TLV is		In line with requirements listed in [RFC5561] the following TLV is
	defined to indicate the P2MP PW capability:		defined to indicate the P2MP PW capability:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|U|F| TLV Code Point=0x703 | Length |		|U|F| TLV Code Point=0x703 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|S| Reserved | Reserved |		|S| Reserved | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 5: P2MP PW LDP Capability TLV		Figure 6: P2MP PW LDP Capability TLV
	Note: TLV number pending IANA allocation.		Note: TLV number pending IANA allocation.
	* U-bit:		* U-bit:
	SHOULD be 1 (ignore if not understood).		SHOULD be 1 (ignore if not understood).
	* F-bit:		* F-bit:
	SHOULD be 0 (don't forward if not understood).		SHOULD be 0 (don't forward if not understood).
	* TLV Code Point:		* TLV Code Point:
	The TLV type, which identifies a specific capability. The P2MP PW		The TLV type identifies a specific capability. The P2MP PW
	capability code point is requested in the IANA allocation section		capability code point is requested in the IANA allocation section
	below.		below.
	* S-bit:		* S-bit:
	The State Bit indicates whether the sender is advertising or		The State Bit indicates whether the sender is advertising or
	withdrawing the P2MP PW capability. The State bit is used as		withdrawing the P2MP PW capability. The State bit is used as
	follows:		follows:
	1 - The TLV is advertising the capability specified by the		1 - The TLV is advertising the capability specified by the
	TLV Code Point.		TLV Code Point.
	0 - The TLV is withdrawing the capability specified by the		0 - The TLV is withdrawing the capability specified by the
	TLV Code Point.		TLV Code Point.
	6. P2MP PW status		5. P2MP PW Status
	In order to support the proposed mechanism, a node MUST be capable of		In order to support the proposed mechanism, a node MUST be capable
	handling PW status. As such, PW status negotiation procedure		of handling PW status. As such, PW status negotiation procedure
	described in [RFC4447] is not applicable to P2MP PW.		described in [RFC4447] is not applicable to P2MP PW.
	Once a Leaf-PE successfully process a Label Mapping Message for a		Once an L-PE successfully processes a Label Mapping Message for a
	P2MP PW, it MUST send appropriate PW status according to the		P2MP PW, it MUST send appropriate PW status according to the
	procedure specified [RFC4447] to notify the PW status. If there is no		procedure specified [RFC4447] to notify the PW status. If there is
	PW status notification required, then no PW status notification is		no PW status notification required, then no PW status notification
	sent. (for example if the P2MP PW is established and operational with		is sent (for example if the P2MP PW is established and operational
	a status 0f 0x00000000 no pw status message is necessary).		with a status of 0x00000000, pw status message is not necessary). PW
			status message sent from any L-PE to R-PE contains P2P Downstream PW
			FEC to identify the PW.
	PW status message sent from any Leaf-PE to Root-PE contains P2MP PW		An R-PE also sends PW status to L-PE(s) to reflect its view of a
	FEC to identify the PW. Finally, a Root-PE also sends PW status to		P2MP PW state. Such PW status message contains P2MP Upstream PW FEC
	Leaf-PE(s) to reflect its view of a P2MP PW state.		to identify the PW.
	Connectivity status of the underlying P2MP LSP that P2MP PW is		Connectivity status of the underlying P2MP LSP that P2MP PW is
	associated with, can be verified using LSP Ping and Traceroute		associated with, can be verified using LSP Ping and Traceroute
	procedures described in [P2MP-LSP-PING].		procedures described in [P2MP-LSP-PING].
	7. Security Considerations		6. Security Considerations
	The security measures described in [RFC4447] is adequate for the		The security measures described in [RFC4447] is adequate for the
	proposed mechanism.		proposed mechanism.
	8. IANA Considerations		7. IANA Considerations
	8.1. FEC Type Name Space		7.1. FEC Type Name Space
	This document uses a new FEC element types, number 0x82 will be		This document uses two new FEC element types, number 0x82 and 0x83
	requested as an allocation from the registry "FEC Type Name Space"		will be requested as an allocation from the registry "FEC Type Name
	for the Label Distribution Protocol (LDP RFC5036):		Space" for the Label Distribution Protocol (RFC5036):
	Value Hex Name Reference		Value Hex Name Reference
	------- ----- ----------------------------- ---------		------- ----- ----------------------------- ---------
	130 0x82 P2MP PW FEC Element RFCxxxx		130 0x82 P2MP PW Upstream FEC Element RFCxxxx
			131 0x83 P2MP PW Downstream FEC Element RFCxxxx
	8.2. LDP TLV TYPE		7.2. LDP TLV Type
	This document uses a new LDP TLV types, IANA already maintains a		This document uses a new LDP TLV types, IANA already maintains a
	registry of name "TLV TYPE NAME SPACE" defined by RFC5036. The		registry of name "TLV TYPE NAME SPACE" defined by RFC5036. The
	following values are suggested for assignment:		following values are suggested for assignment:
	TLV type Description		TLV type Description:
	0x0971 Transport LSP TLV		0x0971 Transport LSP TLV
	0x0703 P2MP PW Capability TLV		0x0703 P2MP PW Capability TLV
	8.3. mLDP Opaque Value Element TLV TYPE		7.3. mLDP Opaque Value Element TLV Type
	This document requires allocation of a new mLDP Opaque Value Element		This document requires allocation of a new mLDP Opaque Value Element
	Type from the LDP MP Opaque Value Element type name space defined in		Type from the LDP MP Opaque Value Element type name space defined in
	[mLDP].		[mLDP].
	The following value is suggested for assignment:		The following value is suggested for assignment:
	TLV type Description		TLV type Description
	0x3 L2VPN-MCAST application TLV		0x3 L2VPN-MCAST application TLV
			7.4. Selective Tree Interface Parameter sub-TLV Type
			This document requires allocation of a sub-TLV from the registry
			"Pseudowire Interface Parameters Sub-TLV Type".
			The following value is suggested for assignment:
			TLV type Description
			0x0D Selective Tree Interface Parameter.
			8. Acknowledgment
			Authors would like thank Kamran Raza, Andre Pelletier, and Parag
			Jain for their valuable suggestions.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC2119] Bradner. S, "Key words for use in RFCs to		[RFC2119] Bradner. S, "Key words for use in RFCs to Indicate
	Indicate Requirement Levels", RFC 2119, March, 1997.		Requirement Levels", RFC 2119, March, 1997.
	[RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L.,		[RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L.,
	et al., rfc4447 April 2006.		et al., rfc4447 April 2006.
	[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP		[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
	Specification", RFC 5036, October 2007.		Specification", RFC 5036, October 2007.
	[RFC5003] C. Metz, L. Martini, F. Balus, J. Sugimoto, "Attachment		[RFC5003] C. Metz, L. Martini, F. Balus, J. Sugimoto, "Attachment
	Individual Identifier (AII) Types for Aggregation", RFC5003,		Individual Identifier (AII) Types for Aggregation", RFC5003,
	September 2007.		September 2007.
	[RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label		[RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label
	Assignment and Context-Specific Label Space", rfc5331,		Assignment and Context-Specific Label Space", rfc5331, August 2008.
	August 2008.
	[RFC5332] T. Eckert, E. Rosen, Ed.,R. Aggarwal, Y. Rekhter,		[RFC5332] T. Eckert, E. Rosen, Ed.,R. Aggarwal, Y. Rekhter, "MPLS
	"MPLS Multicast Encapsulations", rfc5332, August 2008.		Multicast Encapsulations", rfc5332, August 2008.
	[mLDP] I. Minei, K. Kompella, I. Wijnands, B. Thomas, "Label		[mLDP] I. Minei, K. Kompella, I. Wijnands, B. Thomas, "Label
	Distribution Protocol Extensions for Point-to-Multipoint and		Distribution Protocol Extensions for Point-to-Multipoint and
	Multipoint-to-Multipoint Label Switched Paths",		Multipoint-to-Multipoint Label Switched Paths", draft-ietf-mpls-ldp-
	draft-ietf-mpls-ldp-p2mp-06, Work In Progress, April 2009.		p2mp-06, Work In Progress, April 2009.
	[RFC4875]		[RFC4875] R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed.,
	R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed.,		"Extensions to Resource Reservation Protocol - Traffic Engineering
	"Extensions to Resource Reservation Protocol - Traffic		(RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs).",
	Engineering (RSVP-TE) for Point-to-Multipoint TE Label		rfc4875, May 2007.
	Switched Paths (LSPs).", rfc4875, May 2007.
	[L3VPN-MCAST] R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter,		[L3VPN-MCAST] R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, "BGP
	"BGP Encodings and Procedures for Multicast in MPLS/BGP IP		Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", draft-
	VPNs", draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt,		ietf-l3vpn-2547bis-mcast-bgp-08.txt, Work in Progress, October 2009.
	Work in Progress, October 2009.
	[RFC5561] B.Thomas, K.Raza, S.Aggarwal, R.Agarwal, JL. Le Roux,		[RFC5561] B.Thomas, K.Raza, S.Aggarwal, R.Agarwal, JL. Le Roux, "LDP
	"LDP Capabilities", rfc5561, July 2009.		Capabilities", rfc5561, July 2009.
	9.2. Informative References		9.2. Informative References
	[RFC3985] Stewart Bryant, et al., "PWE3 Architecture",		[RFC3985] Stewart Bryant, et al., "PWE3 Architecture", RFC3985
	RFC3985
	[RFC6074] E. Rosen,W. Luo,B. Davie,V. Radoaca "Provisioning,		[RFC6074] E. Rosen,W. Luo,B. Davie,V. Radoaca "Provisioning, Auto-
	Auto-Discovery, and Signaling in Layer 2 Virtual Private		Discovery, and Signaling in Layer 2 Virtual Private Networks
	Networks (L2VPNs)", RFC6074, January 2011.		(L2VPNs)", RFC6074, January 2011.
	[P2MP-PW-REQ] F. Jounay, et. al, "Requirements for Point		[P2MP-PW-REQ] F. Jounay, et. al, "Requirements for Point to
	to Multipoint Pseudowire",		Multipoint Pseudowire", draft-ietf-pwe3-p2mp-pw-requirements-03.txt,
	draft-ietf-pwe3-p2mp-pw-requirements-03.txt, Work in Progress,		Work in Progress, August 2010.
	August 2010.
	[P2MP-LSP-PING] A. Farrel, S. Yasukawa, "Detecting Data Plane		[P2MP-LSP-PING] A. Farrel, S. Yasukawa, "Detecting Data Plane
	Failures in Point-to-Multipoint Multiprotocol Label Switching		Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS)
	(MPLS) - Extensions to LSP Ping",		- Extensions to LSP Ping", draft-ietf-mpls-p2mp-lsp-ping-15.txt,
	draft-ietf-mpls-p2mp-lsp-ping-15.txt, Work In Progress,		Work In Progress, January 2011.
	January 2011.
	10. Author's Addresses		[VPLS-MCAST] R. Aggarwal, Y. Kamite, L. Fang, and Y. Rekhter,
			"Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-09.txt, Work In
			Progress, July 2011.
	Luca Martini		Author's Addresses
			Siva Sivabalan
	Cisco Systems, Inc.		Cisco Systems, Inc.
	9155 East Nichols Avenue, Suite 400		2000 Innovation Drive
	Englewood, CO, 80112		Kanata, Ontario, K2K 3E8
	e-mail: lmartini@cisco.com		Canada
			Email: msiva@cisco.com
	Sami Boutros		Sami Boutros
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 West Tasman Drive		3750 Cisco Way
	San Jose, CA 95134		San Jose, California 95134
	e-mail: sboutros@cisco.com		USA
			Email: sboutros@cisco.com
	Siva Sivabalan		Luca Martini
	2000 Innovation Drive		Cisco Systems, Inc.
	Kanata, ONTARIO K2K 3E8		9155 East Nichols Avenue, Suite 400
	CANADA		Englewood, CO, 80112
	e-mail: msiva@cisco.com		United States
			Email: lmartini@cisco.com
	Maciek Konstantynowicz		Maciek Konstantynowicz
	Juniper Networks		Juniper Networks
	UNITED KINGDOM		UNITED KINGDOM
	e-mail: maciek@juniper.net		Email: maciek@juniper.net
	Gianni Del Vecchio		Gianni Del Vecchio
	Swisscom (Schweiz) AG		Swisscom (Schweiz) AG
	Zentweg 9		Zentweg 9
	CH-3006 Bern		CH-3006 Bern
	Switzerland		Switzerland
	e-mail: Gianni.DelVecchio@swisscom.com		Email: Gianni.DelVecchio@swisscom.com
	Thomas D. Nadeau		Thomas D. Nadeau
	Huawei Technologies		CA Technologies
	2330 Central Expy		273 Corporate Drive
	Santa Clara, CA 95050		Portsmouth, NH 03801
	USA		USA
	e-mail: thomas.nadeau@huawei.com		Email: thomas.nadeau@ca.com
	Frederic Jounay		Frederic Jounay
	France Telecom		France Telecom
	2, avenue Pierre-Marzin		2, avenue Pierre-Marzin
	22307 Lannion Cedex		22307 Lannion Cedex
	FRANCE		FRANCE
	Email: frederic.jounay@orange-ftgroup.com		Email: frederic.jounay@orange-ftgroup.com
	Philippe Niger		Philippe Niger
	France Telecom		France Telecom
	2, avenue Pierre-Marzin		2, avenue Pierre-Marzin
	skipping to change at page 18, line 4 ¶		skipping to change at page 20, line 36 ¶
	Nozay, 91620		Nozay, 91620
	France		France
	Email: martin.vigoureux@alcatel-lucent.com		Email: martin.vigoureux@alcatel-lucent.com
	Laurent Ciavaglia		Laurent Ciavaglia
	Alcatel-Lucent		Alcatel-Lucent
	Route de Villejust		Route de Villejust
	Nozay, 91620		Nozay, 91620
	France		France
	Email: Laurent.Ciavaglia@alcatel-lucent.com		Email: Laurent.Ciavaglia@alcatel-lucent.com
	Simon Delord
	Alcatel-Lucent
			Simon Delord
			Telstra
	E-mail: simon.a.delord@team.telstra.com		E-mail: simon.a.delord@team.telstra.com
	Copyright Notice		Full Copyright Statement
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	This document may contain material from IETF Documents or IETF		All IETF Documents and the information contained therein are provided
	Contributions published or made publicly available before November		on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	10, 2008. The person(s) controlling the copyright in some of this		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
	material may not have granted the IETF Trust the right to allow		IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
	modifications of such material outside the IETF Standards Process.		WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
	Without obtaining an adequate license from the person(s) controlling		WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
	the copyright in such materials, this document may not be modified		ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
	outside the IETF Standards Process, and derivative works of it may		FOR A PARTICULAR PURPOSE.
	not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other
	than English.
	Acknowledgments		Intellectual Property Statement
	The authors wish to acknowledge the contributions of Ali Sajassi.		The IETF takes no position regarding the validity or scope of any
			Intellectual Property Rights or other rights that might be claimed to
			pertain to the implementation or use of the technology described in
			this document or the extent to which any license under such rights
			might or might not be available; nor does it represent that it has
			made any independent effort to identify any such rights.
	Expiration Date: September 2011		Copies of Intellectual Property disclosures made to the IETF
			Secretariat and any assurances of licenses to be made available, or
			the result of an attempt made to obtain a general license or
			permission for the use of such proprietary rights by implementers or
			users of this specification can be obtained from the IETF on-line IPR
			repository at http://www.ietf.org/ipr.
			The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights that may cover technology that may be required to implement
			any standard or specification contained in an IETF Document. Please
			address the information to the IETF at ietf-ipr@ietf.org.
			The definitive version of an IETF Document is that published by, or
			under the auspices of, the IETF. Versions of IETF Documents that are
			published by third parties, including those that are translated into
			other languages, should not be considered to be definitive versions
			of IETF Documents. The definitive version of these Legal Provisions
			is that published by, or under the auspices of, the IETF. Versions of
			these Legal Provisions that are published by third parties, including
			those that are translated into other languages, should not be
			considered to be definitive versions of these Legal Provisions.
			For the avoidance of doubt, each Contributor to the UETF Standards
			Process licenses each Contribution that he or she makes as part of
			the IETF Standards Process to the IETF Trust pursuant to the
			provisions of RFC 5378. No language to the contrary, or terms,
			conditions or rights that differ from or are inconsistent with the
			rights and licenses granted under RFC 5378, shall have any effect and
			shall be null and void, whether published or posted by such
			Contributor, or included with or in such Contribution.
			Acknowledgment
			Funding for the RFC Editor function is currently provided by the
			Internet Society.
End of changes. 123 change blocks.
	347 lines changed or deleted		407 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/