< draft-ietf-pwe3-p2mp-pw-00.txt		draft-ietf-pwe3-p2mp-pw-01.txt >
	Internet Engineering Task Force Luca Martini		Internet Engineering Task Force Sami Boutros
	Internet Draft Sami Boutros		Internet Draft Luca Martini
	Expiration Date: January 2011 Siva Sivabalan		Expiration Date: August 2011 Siva Sivabalan
	Intended status: Standards Track Cisco		Intended status: Standards Track Cisco
	Maciek Konstantynowicz		Maciek Konstantynowicz
	Juniper		Juniper
	Frederic Jounay Gianni Del Vecchio		Frederic Jounay Gianni Del Vecchio
	Philippe Niger Swisscom		Philippe Niger Swisscom
	France Telecom		France Telecom
	Thomas D. Nadeau Yuji Kamite		Thomas D. Nadeau Yuji Kamite
	BT NTT Communications		BT NTT Communications
	Simon Delord Lizhong Jin		Simon Delord Lizhong Jin
	Telstra ZTE		Telstra ZTE
	Laurent Ciavaglia		Laurent Ciavaglia
	Martin Vigoureux		Martin Vigoureux
	Alcatel-Lucent		Alcatel-Lucent
	July 26, 2010		February 8, 2011
	Signaling Root-Initiated Point-to-Multipoint Pseudowires using LDP		Signaling Root-Initiated Point-to-Multipoint Pseudowires using LDP
	draft-ietf-pwe3-p2mp-pw-00.txt		draft-ietf-pwe3-p2mp-pw-01.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.
	skipping to change at page 2, line 8 ¶		skipping to change at page 2, line 8 ¶
	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 January 26, 2010		This Internet-Draft will expire on August 8, 2010
	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
	skipping to change at page 2, line 35 ¶		skipping to change at page 2, line 35 ¶
	4.2 P2MP PW FEC Element .................................. 7		4.2 P2MP PW FEC Element .................................. 7
	4.3 Group ID usage ....................................... 9		4.3 Group ID usage ....................................... 9
	4.4 Generic Label TLV .................................... 9		4.4 Generic Label TLV .................................... 9
	4.5 Transport LSP TLV .................................... 10		4.5 Transport LSP TLV .................................... 10
	5 LDP Capability Negotiation ........................... 12		5 LDP Capability Negotiation ........................... 12
	6 P2MP PW status ....................................... 13		6 P2MP PW status ....................................... 13
	7 Security Considerations .............................. 13		7 Security Considerations .............................. 13
	8 IANA Considerations .................................. 13		8 IANA Considerations .................................. 13
	8.1 FEC Type Name Space .................................. 13		8.1 FEC Type Name Space .................................. 13
	8.2 LDP TLV TYPE ......................................... 14		8.2 LDP TLV TYPE ......................................... 14
			8.3 mLDP Opaque Value Element TLV TYPE ................... 14
	9 References ........................................... 14		9 References ........................................... 14
	9.1 Normative References ................................. 14		9.1 Normative References ................................. 14
	9.2 Informative References ............................... 15		9.2 Informative References ............................... 15
	10 Author's Addresses ................................... 15		10 Author's Addresses ................................... 16
	1. Specification of Requirements		1. Specification of Requirements
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Introduction		2. Introduction
	A Point-to-Multipoint (P2MP) Pseudowire (PW) emulates the essential		A Point-to-Multipoint (P2MP) Pseudowire (PW) emulates the essential
	skipping to change at page 5, line 32 ¶		skipping to change at page 5, line 32 ¶
	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		4. Signaling the 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 [BGP-AD].		autodiscovery [RFC6074].
	Root-PE and each Leaf-PE MUST be configured with the same FEC as		Root-PE and each Leaf-PE MUST be configured with the same FEC as
	defined in the following section.		defined 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 PSN LSP set up between
	Root-PE and Leaf-PE(s). Note that the procedure to set up the P2MP		Root-PE and Leaf-PE(s). Note that the procedure to set up the P2MP
	PSN LSP is different depending on the protocol used: RSVP-TE or mLDP.		PSN 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 a Leaf-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 case of RSVP-TE the P2MP LSP is set up by the Root-PE,
	skipping to change at page 7, line 13 ¶		skipping to change at page 7, line 13 ¶
	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		4.2. P2MP PW FEC Element
	[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 a new type of FEC element called "P2MP PW FEC Element"
	whose type is 0x82 (Pending IANA Allocation) and is encoded as		whose type is 0x82 (Pending IANA Allocation) and is encoded as
	follows:		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.) ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| AII Type | Length | SAII Value |		| AII Type | Length | SAII Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ SAII Value (contd.) ~		~ SAII Value (contd.) ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0|0| Transport LSP TLV (0x0971)| Length |		|0|0| Transport LSP TLV (0x0971)| Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved |PMSI Tunnel Typ| Transport LSP ID |		| Reserved |PMSI Tunnel Typ| Transport LSP ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Transport LSP ID (contd.) ~		~ Transport LSP ID (contd.) ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 5 ¶
	Generic Label TLV contained in LDP Label Mapping Message. A Generic		Generic Label TLV contained in LDP Label Mapping Message. A Generic
	Label TLV is formatted and processed as per the rules and procedures		Label TLV is formatted and processed as per the rules and procedures
	specified in [RFC4447]. But, as mentioned above, a Label Mapping		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		Message for a P2MP PW can have up to two Generic Label TLVs; one for
	upstream-assigned label (always) and another for downstream-assigned		upstream-assigned label (always) and another for downstream-assigned
	label (optional). In the case of two Generic Label TLVs, the first		label (optional). In the case of two Generic Label TLVs, the first
	TLV (from the beginning of the message) carries upstream-assigned		TLV (from the beginning of the message) carries upstream-assigned
	label and the next generic label TLV carries the downstream-assigned		label and the next generic label TLV carries the downstream-assigned
	label as shown below:		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 |		|0|0| Generic Label (0x0200) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Upstream-assigned P2MP Label (mandatory) |		| Upstream-assigned P2MP Label (mandatory) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0|0| Generic Label (0x0200) | Length |		|0|0| Generic Label (0x0200) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Downstream-assigned P2P Label (optional) |		| Downstream-assigned P2P Label (optional) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 10, line 32 ¶		skipping to change at page 10, line 32 ¶
	P2P Label TLV.		P2P Label TLV.
	4.5. Transport LSP TLV		4.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 MUST
	contain the identity of the transport LSP. For this purpose, this		contain the identity of the transport LSP. For this purpose, this
	specification introduces a new TLV called "Transport LSP TLV" which		specification introduces a new TLV called "Transport LSP TLV" which
	has the following format:		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 4: Transport LSP TLV
	skipping to change at page 11, line 16 ¶		skipping to change at page 11, line 16 ¶
	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].
	Editor Comment: This is not finalized yet, as a new mLDP opaque		When the type is set to mLDP P2MP LSP, the Tunnel Identifier is a
	value needs to be used in place of this construct. This is		P2MP FEC Element as defined in [mLDP]. A new mLDP Opaque Value
	necessary to comply with the mLDP design principle of having a		Element type for L2VPN-MCAST application needs to be allocated.
	mLDP LDP MP Opaque Value Element type per application.
			Editor Comment: The content of the Opaque Value Element TLV is a
			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 Message.
	An Root-PE sends Label Mapping Message as soon as the transport LSP		An Root-PE sends Label Mapping Message as soon as the transport LSP
	ID associated with the P2MP PW is known (e.g., via configuration)		ID associated with the P2MP PW is known (e.g., via configuration)
	regardless of the operational state of the transport LSP. Similarly,		regardless of the operational state of the transport LSP. Similarly,
	skipping to change at page 12, line 19 ¶		skipping to change at page 12, line 19 ¶
	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].
	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 5: P2MP PW LDP Capability TLV
	Note: TLV number pending IANA allocation.		Note: TLV number pending IANA allocation.
	skipping to change at page 14, line 15 ¶		skipping to change at page 14, line 15 ¶
	8.2. LDP TLV TYPE		8.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
			This document requires allocation of a new mLDP Opaque Value Element
			Type from the LDP MP Opaque Value Element type name space defined in
			[mLDP].
			The following value is suggested for assignment:
			TLV type Description
			0x3 L2VPN-MCAST application TLV
	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 Requirement Levels", RFC 2119, March, 1997.		Indicate 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.
	skipping to change at page 15, line 15 ¶		skipping to change at page 15, line 29 ¶
	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 Capabilities", rfc5561, July 2009.		"LDP 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
	[BGP-AD] E. Rosen,W. Luo,B. Davie,V. Radoaca "Provisioning,		[RFC6074] E. Rosen,W. Luo,B. Davie,V. Radoaca "Provisioning,
	Autodiscovery, and Signaling in L2VPNs",		Auto-Discovery, and Signaling in Layer 2 Virtual Private
	draft-ietf-l2vpn-signaling-08.txt May 2006.		Networks (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 Multipoint Pseudowire",		to Multipoint Pseudowire",
	draft-ietf-pwe3-p2mp-pw-requirements-02.txt, Work in Progress,		draft-ietf-pwe3-p2mp-pw-requirements-03.txt, Work in Progress,
	January 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) - Extensions to LSP Ping",		(MPLS) - Extensions to LSP Ping",
	draft-ietf-mpls-p2mp-lsp-ping-10.txt, Work In Progress,		draft-ietf-mpls-p2mp-lsp-ping-15.txt, Work In Progress,
	March 2010.		January 2011.
	10. Author's Addresses		10. Author's Addresses
	Luca Martini		Luca Martini
	Cisco Systems, Inc.		Cisco Systems, Inc.
	9155 East Nichols Avenue, Suite 400		9155 East Nichols Avenue, Suite 400
	Englewood, CO, 80112		Englewood, CO, 80112
	e-mail: lmartini@cisco.com		e-mail: lmartini@cisco.com
	Sami Boutros		Sami Boutros
	skipping to change at page 17, line 32 ¶		skipping to change at page 18, line 4 ¶
	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		Simon Delord
	Telstra		Telstra
	242 Exhibition Street		242 Exhibition Street
	Melbourne, VIC, 3000, Australia		Melbourne, VIC, 3000, Australia
	E-mail: simon.a.delord@team.telstra.com		E-mail: simon.a.delord@team.telstra.com
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 18, line 31 ¶		skipping to change at page 18, line 41 ¶
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Acknowledgments		Acknowledgments
	The authors wish to acknowledge the contributions of Ali Sajassi.		The authors wish to acknowledge the contributions of Ali Sajassi.
	Expiration Date: January 2011		Expiration Date: August 2011
End of changes. 20 change blocks.
	30 lines changed or deleted		43 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/