draft-ietf-mpls-mp-ldp-reqs-08.txt		rfc6348.txt
	MPLS J. Le Roux, Ed.		Internet Engineering Task Force (IETF) J. Le Roux, Ed.
	Internet-Draft T. Morin, Ed.		Request for Comments: 6348 T. Morin, Ed.
	Intended status: Historic France Telecom - Orange		Category: Historic France Telecom - Orange
	Expires: November 27, 2011 May 26, 2011		ISSN: 2070-1721 September 2011
	Requirements for Point-To-Multipoint Extensions to the Label		Requirements for Point-to-Multipoint Extensions
	Distribution Protocol		to the Label Distribution Protocol
	draft-ietf-mpls-mp-ldp-reqs-08
	Abstract		Abstract
	This document lists a set of functional requirements that served as		This document lists a set of functional requirements that served as
	input to the design of Label Distribution Protocol (LDP) extensions		input to the design of Label Distribution Protocol (LDP) extensions
	for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP),		for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP),
	in order to deliver point-to-multipoint applications over a Multi		in order to deliver point-to-multipoint applications over a
	Protocol Label Switching (MPLS) infrastructure.		Multiprotocol Label Switching (MPLS) infrastructure.
	Status of this Memo		This work was overtaken by the protocol solution developed by the
			MPLS working group, but that solution did not closely follow the
			requirements documented here. This document is published as a
			historic record of the ideas and requirements that shaped the
			protocol work.
	This Internet-Draft is submitted in full conformance with the		Status of This Memo
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		This document is not an Internet Standards Track specification; it is
	Task Force (IETF). Note that other groups may also distribute		published for the historical record.
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document defines a Historic Document for the Internet community.
	and may be updated, replaced, or obsoleted by other documents at any		This document is a product of the Internet Engineering Task Force
	time. It is inappropriate to use Internet-Drafts as reference		(IETF). It represents the consensus of the IETF community. It has
	material or to cite them other than as "work in progress."		received public review and has been approved for publication by the
			Internet Engineering Steering Group (IESG). Not all documents
			approved by the IESG are a candidate for any level of Internet
			Standard; see Section 2 of RFC 5741.
	This Internet-Draft will expire on November 27, 2011.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc6348.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 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
	skipping to change at page 3, line 8		skipping to change at page 3, line 8
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	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.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 4		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
	1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4		1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
	1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5		1.3. Context and Motivations . . . . . . . . . . . . . . . . . 6
	1.4. Context and Motivations . . . . . . . . . . . . . . . . . 6		1.4. Document Scope . . . . . . . . . . . . . . . . . . . . . . 7
	1.5. Document Scope . . . . . . . . . . . . . . . . . . . . . . 7
	2. Requirements Overview . . . . . . . . . . . . . . . . . . . . 7		2. Requirements Overview . . . . . . . . . . . . . . . . . . . . 7
	3. Application Scenario . . . . . . . . . . . . . . . . . . . . . 8		3. Application Scenario . . . . . . . . . . . . . . . . . . . . . 8
	4. Detailed Requirements . . . . . . . . . . . . . . . . . . . . 9		4. Detailed Requirements . . . . . . . . . . . . . . . . . . . . 9
	4.1. P2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 9		4.1. P2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.2. P2MP LSP FEC . . . . . . . . . . . . . . . . . . . . . . . 9		4.2. P2MP LSP FEC . . . . . . . . . . . . . . . . . . . . . . . 10
	4.3. P2MP LDP Routing . . . . . . . . . . . . . . . . . . . . . 10		4.3. P2MP LDP Routing . . . . . . . . . . . . . . . . . . . . . 10
	4.4. Setting Up, Tearing Down and Modifying P2MP LSPs . . . . . 10		4.4. Setting Up, Tearing Down, and Modifying P2MP LSPs . . . . 10
	4.5. Label Advertisement . . . . . . . . . . . . . . . . . . . 10		4.5. Label Advertisement . . . . . . . . . . . . . . . . . . . 10
	4.6. Data Duplication . . . . . . . . . . . . . . . . . . . . . 10		4.6. Data Duplication . . . . . . . . . . . . . . . . . . . . . 11
	4.7. Detecting and Avoiding Loops . . . . . . . . . . . . . . . 11		4.7. Detecting and Avoiding Loops . . . . . . . . . . . . . . . 11
	4.8. P2MP LSP Re-routing . . . . . . . . . . . . . . . . . . . 11		4.8. P2MP LSP Rerouting . . . . . . . . . . . . . . . . . . . . 11
	4.9. Support for Multi-Access Networks . . . . . . . . . . . . 12		4.9. Support for Multi-Access Networks . . . . . . . . . . . . 12
	4.10. Support for Encapsulation in P2P and P2MP TE Tunnels . . . 12		4.10. Support for Encapsulation in P2P and P2MP TE Tunnels . . . 12
	4.11. Label Spaces . . . . . . . . . . . . . . . . . . . . . . . 13		4.11. Label Spaces . . . . . . . . . . . . . . . . . . . . . . . 13
	4.12. IPv4/IPv6 Support . . . . . . . . . . . . . . . . . . . . 13		4.12. IPv4/IPv6 Support . . . . . . . . . . . . . . . . . . . . 13
	4.13. Multi-Area/AS LSPs . . . . . . . . . . . . . . . . . . . . 13		4.13. Multi-Area/AS LSPs . . . . . . . . . . . . . . . . . . . . 13
	4.14. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 13		4.14. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	4.15. Graceful Restart and Fault Recovery . . . . . . . . . . . 13		4.15. Graceful Restart and Fault Recovery . . . . . . . . . . . 14
	4.16. Robustness . . . . . . . . . . . . . . . . . . . . . . . . 13		4.16. Robustness . . . . . . . . . . . . . . . . . . . . . . . . 14
	4.17. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14		4.17. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14
	4.18. Backward Compatibility . . . . . . . . . . . . . . . . . . 14		4.18. Backward Compatibility . . . . . . . . . . . . . . . . . . 14
	5. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 14		5. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 15
	5.1. Requirements for MP2MP LSPs . . . . . . . . . . . . . . . 15		5.1. Requirements for MP2MP LSPs . . . . . . . . . . . . . . . 15
	6. Evaluation Criteria . . . . . . . . . . . . . . . . . . . . . 16		6. Evaluation Criteria . . . . . . . . . . . . . . . . . . . . . 16
	6.1. Performance . . . . . . . . . . . . . . . . . . . . . . . 16		6.1. Performance . . . . . . . . . . . . . . . . . . . . . . . 16
	6.2. Complexity and Risks . . . . . . . . . . . . . . . . . . . 17		6.2. Complexity and Risks . . . . . . . . . . . . . . . . . . . 17
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 17		7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 17		9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	10.2. Informative References . . . . . . . . . . . . . . . . . . 18		9.2. Informative References . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19		Contributing Authors . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	This document lists a set of functional requirements that served as		This document lists a set of functional requirements that served as
	input to the design of Label Distribution Protocol (LDP) extensions		input to the design of Label Distribution Protocol (LDP) extensions
	for setting up point-to-multipoint (P2MP) Label Switched Paths		for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP)
	(LSP)[I-D.ietf-mpls-ldp-p2mp], in order to deliver point-to-		[MLDP], in order to deliver point-to-multipoint applications over a
	multipoint applications over a Multi-Protocol Label Switching (MPLS)		Multiprotocol Label Switching (MPLS) infrastructure.
	infrastructure. It is published with Historic status with the
	perspective of documenting the work done.
	The document is structured as follows:
	o Section 2 is an overview of the requirements;
	o Section 3 illustrates an application scenario;
	o Section 4 addresses detailed requirements for P2MP LSPs;
	o Section 5 finally discusses requirements for shared trees and
	MultiPoint-to-MultiPoint (MP2MP) LSPs.
	1.1. Contributing Authors
	The following people contributed to the text and content of this
	document:
	o Shane Amante, Level 3 Communications, LLC		This work was overtaken by the protocol solution developed by the
			MPLS working group and documented in [MLDP]. That solution did not
			closely follow the requirements documented here, and it was
			recognized that this document had served its purpose in driving
			discussions of how the solution should be designed. At this point,
			no further action is planned to update this document in line with the
			protocol solution, and this document is published simply as a
			historic record of the ideas and requirements that shaped the
			protocol work.
	o Luyuan Fang, Cisco Systems		The document is structured as follows:
	o Yuji Kamite, NTT Communications Corporation		o Section 2 is an overview of the requirements.
	o Jean-Louis Le Roux, France Telecom - Orange		o Section 3 illustrates an application scenario.
	o Thomas Morin, France Telecom - Orange		o Section 4 addresses detailed requirements for P2MP LSPs.
	o Vincent Parfait, France Telecom - Orange, Orange Business Services		o Section 5 discusses requirements for shared trees and multipoint-
			to-multipoint (MP2MP) LSPs.
	o Lei Wang, Telenor		o Section 6 presents criteria against which a solution can be
			evaluated.
	1.2. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		This document is a historic requirements document. To clarify
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		statement of requirements, key words are used as follows. The key
	document are to be interpreted as described in [RFC2119].		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].
	1.3. Definitions		1.2. Definitions
	1.3.1. Acronyms		1.2.1. Acronyms
	P2P: Point-To-Point		P2P: Point-to-Point
	MP2P: Multipoint-to-Point		MP2P: Multipoint-to-Point
			P2MP: Point-to-Multipoint
	P2MP: Point-To-MultiPoint		MP2MP: Multipoint-to-Multipoint
	MP2MP: MultiPoint-To-Multipoint
	LSP: Label Switched Path		LSP: Label Switched Path
	LSR: Label Switching Router		LSR: Label Switching Router
	PE: Provider Edge router		PE: Provider Edge
	P: Provider router		P: Provider
	IGP: Interior Gateway Protocol		IGP: Interior Gateway Protocol
	AS: Autonomous System		AS: Autonomous System
	1.3.2. Terminology		1.2.2. Terminology
	The reader is assumed to be familiar with the terminology in		The reader is assumed to be familiar with the terminology in
	[RFC3031], [RFC5036], and [RFC4026].		[RFC3031], [RFC5036], and [RFC4026].
	Ingress LSR:		Ingress LSR:
	Router acting as a sender of an LSP		Router acting as a sender of an LSP
	Egress LSR:		Egress LSR:
	Router acting as a receiver of an LSP		Router acting as a receiver of an LSP
	P2P LSP:		P2P LSP:
	An LSP that has one unique Ingress LSR and one unique Egress LSR		An LSP that has one unique Ingress LSR and one unique Egress LSR
	MP2P LSP:		MP2P LSP:
	An LSP that has one or more Ingress LSRs and one unique Egress LSR		An LSP that has one or more Ingress LSRs and one unique Egress LSR
	P2MP LSP:		P2MP LSP:
	An LSP that has one unique Ingress LSR and one or more Egress LSRs		An LSP that has one unique Ingress LSR and one or more Egress LSRs
	MP2MP LSP:		MP2MP LSP:
	An LSP that as one or more Leaf LSRs acting indifferently as		An LSP that has one or more Leaf LSRs acting indifferently as
	Ingress or Egress LSR		Ingress or Egress LSR
	Leaf LSR:		Leaf LSR:
	An Egress LSR of a P2MP LSP or an Ingress/Egress LSR of a MP2MP		An Egress LSR of a P2MP LSP or an Ingress/Egress LSR of an MP2MP
	LSP		LSP
	Transit LSR:		Transit LSR:
	An LSR of a P2MP or MP2MP LSP that has one or more Downstream LSRs		An LSR of a P2MP or MP2MP LSP that has one or more downstream LSRs
	Branch LSR:		Branch LSR:
	An LSR of a P2MP or MP2MP LSP that has more than one downstream		An LSR of a P2MP or MP2MP LSP that has more than one downstream
	LSR		LSR
	Bud LSR:		Bud LSR:
	An LSR of a P2MP or MP2MP LSP that is an egress but also has one		An LSR of a P2MP or MP2MP LSP that is an Egress but also has one
	or more directly connected downstream LSR(s)		or more directly connected downstream LSR(s)
	P2MP tree:		P2MP tree:
	The ordered set of LSRs and links that comprise the path of a P2MP		The ordered set of LSRs and links that comprise the path of a P2MP
	LSP from its ingress LSR to all of its egress LSRs.		LSP from its Ingress LSR to all of its Egress LSRs.
	1.4. Context and Motivations		1.3. Context and Motivations
	LDP [RFC5036] has been deployed for setting up point-to-point (P2P)		LDP [RFC5036] has been deployed for setting up point-to-point (P2P)
	and multipoint-to-point (MP2P) LSPs, in order to offer point-to-point		and multipoint-to-point (MP2P) LSPs, in order to offer point-to-point
	services in MPLS backbones.		services in MPLS backbones.
	There are emerging requirements for supporting delivery of point-to-		There are emerging requirements for supporting delivery of point-to-
	multipoint applications in MPLS backbones, such as those defined in		multipoint applications in MPLS backbones, such as those defined in
	[RFC4834] and [RFC5501].		[RFC4834] and [RFC5501].
	For various reasons, including consistency with P2P applications, and		For various reasons, including consistency with P2P applications, and
	taking full advantages of MPLS network infrastructure, it would be		taking full advantages of MPLS network infrastructure, it would be
	highly desirable to use MPLS LSPs for the delivery of multicast		highly desirable to use MPLS LSPs for the delivery of multicast
	traffic. This could be implemented by setting up a group of P2P or		traffic. This could be implemented by setting up a group of P2P or
	MP2P LSPs, but such an approach may be inefficient since it would		MP2P LSPs, but such an approach may be inefficient since it would
	result in data replication at the ingress LSR and duplicate data		result in data replication at the Ingress LSR and duplicate data
	traffic within the network. Hence new mechanisms are required that		traffic within the network.
	would allow traffic from an Ingress LSR to be efficiently delivered
	to a number of Egress LSRs in an MPLS backbone on a point-to-
	multipoint LSP (P2MP LSP), avoiding duplicate copies of a packet on a
	given link and with MPLS traffic replication at some Branch LSRs.
	RSVP-TE extensions for setting up Point-To-Multipoint Traffic		Hence, new mechanisms are required that would allow traffic from an
	Engineered LSPs (P2MP TE LSPs), have been defined in [RFC4875]. They		Ingress LSR to be efficiently delivered to a number of Egress LSRs in
	meet requirements expressed in [RFC4461]. This approach is useful,		an MPLS backbone on a point-to-multipoint LSP (P2MP LSP), avoiding
	in network environments where P2MP Traffic Engineering capabilities		duplicate copies of a packet on a given link and relying on MPLS
	are needed (Optimization, QoS, Fast recovery).		traffic replication at some Branch LSRs.
	However for operators who want to support point-to-multipoint traffic		Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
	delivery on an MPLS backbone, without Traffic Engineering needs, and		extensions for setting up point-to-multipoint Traffic Engineered LSPs
	who have already deployed LDP for P2P traffic, an interesting and		(P2MP TE LSPs) have been defined in [RFC4875]. They meet
	useful approach would be to rely on LDP extensions in order to setup		requirements expressed in [RFC4461]. This approach is useful in
	point-to-multipoint (P2MP) LSPs. This would bring consistency with		network environments where P2MP Traffic Engineering capabilities are
	P2P MPLS applications and would ease the delivery of point-to-		needed (optimization, QoS, fast recovery).
	multipoint services in an MPLS backbone.
	1.5. Document Scope		However, for operators who want to support point-to-multipoint
			traffic delivery on an MPLS backbone, without Traffic Engineering
			needs, and who have already deployed LDP for P2P traffic, an
			interesting and useful approach would be to rely on LDP extensions in
			order to set up point-to-multipoint (P2MP) LSPs. This would bring
			consistency with P2P MPLS applications and would ease the delivery of
			point-to-multipoint services in an MPLS backbone.
			1.4. Document Scope
	This document focuses on the LDP approach for setting up P2MP LSPs.		This document focuses on the LDP approach for setting up P2MP LSPs.
	It lists a detailed set of requirements for P2MP extensions to LDP,		It lists a detailed set of requirements for P2MP extensions to LDP,
	so as to deliver P2MP traffic over a LDP-enabled MPLS infrastructure.		so as to deliver P2MP traffic over an LDP-enabled MPLS
	The original intent was that these requirements should be used as		infrastructure. The original intent was that these requirements
	guidelines when specifying LDP extensions.		should be used as guidelines when specifying LDP extensions.
	Note that generic requirements for P2MP extensions to MPLS are out of		Note that generic requirements for P2MP extensions to MPLS are out of
	the scope of this document. Rather this document describes solution		the scope of this document. Rather, this document describes
	specific requirements related to LDP extensions in order to set up		solution-specific requirements related to LDP extensions in order to
	P2MP LSPs.		set up P2MP LSPs.
	Note also that other mechanisms could be used for setting up P2MP		Note also that other mechanisms could be used for setting up P2MP
	LSPs, such as for instance PIM extensions, but these are out of the		LSPs (for instance, PIM extensions), but these are out of the scope
	scope of this document. The objective is not to compare these		of this document. The objective is not to compare these mechanisms
	mechanisms but rather to focus on the requirements for an LDP		but rather to focus on the requirements for an LDP extension
	extension approach.		approach.
	2. Requirements Overview		2. Requirements Overview
	The P2MP LDP mechanism MUST support setting up P2MP LSPs, i.e. LSPs		The P2MP LDP mechanism MUST support setting up P2MP LSPs, i.e., LSPs
	with one Ingress LSR and one or more Egress LSRs, with traffic		with one Ingress LSR and one or more Egress LSRs, with traffic
	replication at some Branch LSRs.		replication at some Branch LSRs.
	The P2MP LDP mechanism MUST allow the addition or removal of leaves		The P2MP LDP mechanism MUST allow the addition or removal of leaves
	associated with a P2MP LSP.		associated with a P2MP LSP.
	The P2MP LDP mechanism MUST co-exist with current LDP mechanisms and		The P2MP LDP mechanism MUST coexist with current LDP mechanisms and
	inherit its capability sets from [RFC5036]. It is of paramount		inherit its capability sets from [RFC5036]. It is of paramount
	importance that the P2MP LDP mechanism MUST NOT impede the operation		importance that the P2MP LDP mechanism MUST NOT impede the operation
	of existing P2P/MP2P LDP LSPs. Also the P2MP LDP mechanism MUST co-		of existing P2P/MP2P LDP LSPs. Also, the P2MP LDP mechanism MUST
	exist with P2P and P2MP RSVP-TE mechanisms [RFC3209], [RFC4875]. It		coexist with P2P and P2MP RSVP-TE mechanisms [RFC3209] [RFC4875]. It
	is of paramount importance that the P2MP LDP mechanism MUST NOT		is of paramount importance that the P2MP LDP mechanism MUST NOT
	impede the operation of existing P2P and P2MP RSVP-TE LSPs.		impede the operation of existing P2P and P2MP RSVP-TE LSPs.
	The P2MP LDP mechanism MAY also allow setting up multipoint-to-		The P2MP LDP mechanism MAY also allow setting up multipoint-to-
	multipoint (MP2MP) LSPs connecting a group of Leaf LSRs acting		multipoint (MP2MP) LSPs connecting a group of Leaf LSRs acting
	indifferently as Ingress LSR or Egress LSR. This may allow a		indifferently as Ingress LSR or Egress LSR. This may allow a
	reduction in the amount of LDP state that needs to be maintained by a		reduction in the amount of LDP state that needs to be maintained by
	LSR.		an LSR.
	3. Application Scenario		3. Application Scenario
	Figure 1 below illustrates an LDP enabled MPLS provider network, used		Figure 1 below illustrates an LDP-enabled MPLS provider network, used
	to carry both unicast and multicast traffic of VPN customers		to carry both unicast and multicast traffic of VPN customers
	following for instance the architecture defined in		following, for instance, the architecture defined in [MVPN] for BGP/
	[I-D.ietf-l3vpn-2547bis-mcast] for BGP/MPLS VPNs, or the one defined		MPLS VPNs or the one defined in [VPLS-MCAST].
	in [I-D.ietf-l2vpn-vpls-mcast].
	In this example, a set of MP2P LDP LSPs are setup between Provider		In this example, a set of MP2P LDP LSPs is set up between Provider
	Edge (PE) routers to carry unicast VPN traffic within the MPLS		Edge (PE) routers to carry unicast VPN traffic within the MPLS
	backbone.		backbone (not represented in Figure 1).
	And in this example a set of P2MP LDP LSPs are setup between PE		In this example, a set of P2MP LDP LSPs is set up between PE routers
	routers acting as Ingress LSRs and PE routers acting as Egress LSRs,		acting as Ingress LSRs and PE routers acting as Egress LSRs, so as to
	so as to support multicast VPN traffic delivery within the MPLS		support multicast VPN traffic delivery within the MPLS backbone.
	backbone.
	For instance, a P2MP LDP LSP is setup between Ingress LSR PE1 and		For instance, a P2MP LDP LSP is set up between Ingress LSR PE1 and
	Egress LSRs PE2, PE3, and PE4. It is used to transport multicast		Egress LSRs PE2, PE3, and PE4. It is used to transport multicast
	traffic from PE1 to PE2, PE3 and PE4. P1 is a Branch LSR, it		traffic from PE1 to PE2, PE3, and PE4. P1 is a Branch LSR; it
	replicates MPLS traffic sent by PE1 to P2, P3 and PE2. P2 and P3 are		replicates MPLS traffic sent by PE1 to P2, P3, and PE2. P2 and P3
	non-branch transit LSRs, they forward MPLS traffic sent by P1 to PE3		are non-Branch Transit LSRs; they forward MPLS traffic sent by P1 to
	and PE4 respectively.		PE3 and PE4, respectively.
	PE1		PE1
	*| *** P2MP LDP LSP		*| *** P2MP LDP LSP
	*|*****		*|*****
	P1-----PE2		P1-----PE2
	*/ \*		*/ \*
	*/ \*		*/ \*
	*****/ \******		*****/ \******
	PE3----P2 P3----PE4		PE3----P2 P3----PE4
	| |		| |
	| |		| |
	| |		| |
	PE5 PE6		PE5 PE6
	Figure 1: P2MP LSP from PE1 to PE2, PE3, PE4.		Figure 1: P2MP LSP from PE1 to PE2, PE3, PE4
	If later there are new receivers attached to PE5 and PE6, then PE5		If later there are new receivers attached to PE5 and PE6, then PE5
	and PE6 join the P2MP LDP LSP. P2 and P3 become Branch LSRs and		and PE6 join the P2MP LDP LSP. P2 and P3 become Branch LSRs and
	replicate traffic received from P1, to PE3 and PE5, and to PE4 and		replicate traffic received from P1 to PE3 and PE5 and to PE4 and PE6,
	PE6 respectively (see Figure 2 below).		respectively (see Figure 2 below).
	PE1		PE1
	*| *** P2MP LDP LSP		*| *** P2MP LDP LSP
	*|*****		*|*****
	P1-----PE2		P1-----PE2
	*/ \*		*/ \*
	*/ \*		*/ \*
	*****/ \******		*****/ \******
	PE3----P2 P3----PE4		PE3----P2 P3----PE4
	*| |*		*| |*
	*| |*		*| |*
	*| |*		*| |*
	PE5 PE6		PE5 PE6
	Figure 2: Attachment of PE5 and PE6.		Figure 2: Attachment of PE5 and PE6
	The above example is provided for the sake of illustration. Note		The above example is provided for the sake of illustration. Note
	that P2MP LSPs ingress and egress LSRs may not necessarily be PE		that P2MP LSPs Ingress and Egress LSRs may not necessarily be PE
	routers. Also branch LSRs may not necessarily be P routers.		routers. Also, Branch LSRs may not necessarily be P routers.
	4. Detailed Requirements		4. Detailed Requirements
	4.1. P2MP LSPs		4.1. P2MP LSPs
	The P2MP LDP mechanism MUST support setting up P2MP LSPs. Data plane		The P2MP LDP mechanism MUST support setting up P2MP LSPs. Data plane
	aspects related to P2MP LSPs are those already defined in [RFC4461].		aspects related to P2MP LSPs are those already defined in [RFC4461].
	That is, a P2MP LSP has one Ingress LSR and one or more Egress LSRs.		That is, a P2MP LSP has one Ingress LSR and one or more Egress LSRs.
	Traffic sent by the Ingress LSR is received by all Egress LSRs. The		Traffic sent by the Ingress LSR is received by all Egress LSRs. The
	specific aspects related to P2MP LSPs is the action required at a		specific aspect related to P2MP LSPs is the action required at a
	Branch LSR, where data replication occurs. Incoming labelled data is		Branch LSR, where data replication occurs. Incoming labeled data is
	appropriately replicated to several outgoing interfaces which may use		appropriately replicated to several outgoing interfaces, which may
	different labels.		use different labels.
	An LSR SHOULD NOT send more than one copy of a packet on any given		An LSR SHOULD NOT send more than one copy of a packet on any given
	link of a P2MP LSP. Exceptions to this are mentioned in Section 4.9		link of a P2MP LSP. Exceptions to this are mentioned in Sections 4.9
	and Section 4.18.		and 4.18.
	A P2MP LSP MUST be identified by a constant and unique identifier		A P2MP LSP MUST be identified by a constant and unique identifier
	within the whole LDP domain, whatever the number of leaves, which may		within the whole LDP domain, whatever the number of leaves, which may
	vary dynamically. This identifier will be used so as to add/remove		vary dynamically. This identifier will be used so as to add/remove
	leaves to/from the P2MP tree.		leaves to/from the P2MP tree.
	4.2. P2MP LSP FEC		4.2. P2MP LSP FEC
	As with P2P MPLS technology [RFC5036], traffic MUST be classified		As with P2P MPLS technology [RFC5036], traffic MUST be classified
	into a FEC in this P2MP extension. All packets which belong to a		into a Forwarding Equivalence Class (FEC) in this P2MP extension.
	particular P2MP FEC and which travel from a particular node MUST use		All packets that belong to a particular P2MP FEC and that travel from
	the same P2MP LSP.		a particular node MUST use the same P2MP LSP.
	If existing FECs cannot be used for this purpose, a new LDP FEC that		If existing FECs cannot be used for this purpose, a new LDP FEC that
	is suitable for P2MP forwarding MUST be specified.		is suitable for P2MP forwarding MUST be specified.
	4.3. P2MP LDP Routing		4.3. P2MP LDP Routing
	As with P2P and MP2P LDP LSPs, the P2MP LDP mechanism MUST support		As with P2P and MP2P LDP LSPs, the P2MP LDP mechanism MUST support
	hop-by-hop LSP routing. P2MP LDP-based routing SHOULD rely upon the		hop-by-hop LSP routing. P2MP LDP-based routing SHOULD rely upon the
	information maintained in LSR Routing Information Bases (RIB).		information maintained in LSR Routing Information Bases (RIBs).
	It is RECOMMENDED that the P2MP LSP routing rely upon the unicast		It is RECOMMENDED that the P2MP LSP routing rely upon the unicast
	route to the Ingress LSR to build a reverse path tree.		route to the Ingress LSR to build a reverse path tree.
	4.4. Setting Up, Tearing Down and Modifying P2MP LSPs		4.4. Setting Up, Tearing Down, and Modifying P2MP LSPs
	The P2MP LDP mechanism MUST support the establishment, maintenance		The P2MP LDP mechanism MUST support the establishment, maintenance,
	and teardown of P2MP LSPs in a scalable manner. This MUST include		and teardown of P2MP LSPs in a scalable manner. This MUST include
	both the existence of a large amount of P2MP LSPs within a single		both the existence of a large number of P2MP LSPs within a single
	network and a large amount of leaf LSRs for a single P2MP LSP (see		network and a large number of Leaf LSRs for a single P2MP LSP (see
	also Section 4.17 for scalability considerations and figures).		also Section 4.17 for scalability considerations and figures).
	In order to scale well with a large number of leaves it is		In order to scale well with a large number of leaves, it is
	RECOMMENDED to follow a leaf-initiated P2MP LSP setup approach. For		RECOMMENDED to follow a leaf-initiated P2MP LSP setup approach. For
	that purpose, leaves will have to be aware of the P2MP LSP		that purpose, leaves will have to be aware of the P2MP LSP
	identifier. The ways a Leaf LSR discovers P2MP LSPs identifiers rely		identifier. The ways a Leaf LSR discovers P2MP LSP identifiers rely
	on the applications that will use P2MP LSPs, and are out of the scope		on the applications that will use P2MP LSPs and are out of the scope
	of this document.		of this document.
	The P2MP LDP mechanism MUST allow the dynamic addition and removal of		The P2MP LDP mechanism MUST allow the dynamic addition and removal of
	leaves to and from a P2MP LSP, without any restriction (provided		leaves to and from a P2MP LSP, without any restriction (provided
	there is network connectivity). It is RECOMMENDED that these		there is network connectivity). It is RECOMMENDED that these
	operations be leaf-initiated. These operations MUST NOT impact the		operations be leaf-initiated. These operations MUST NOT impact the
	data transfer (packet loss, duplication, delay) towards other leaves.		data transfer (packet loss, duplication, delay) towards other leaves.
	It is RECOMMENDED that these operations do not cause any additional		It is RECOMMENDED that these operations do not cause any additional
	processing except on the path from the added/removed Leaf LSR to the		processing except on the path from the added/removed Leaf LSR to the
	Branch LSR.		Branch LSR.
	skipping to change at page 11, line 5		skipping to change at page 11, line 12
	advertisement mode. This is well suited to a leaf-initiated approach		advertisement mode. This is well suited to a leaf-initiated approach
	and is consistent with P2P/MP2P LDP operations.		and is consistent with P2P/MP2P LDP operations.
	Other advertisement modes MAY also be supported.		Other advertisement modes MAY also be supported.
	4.6. Data Duplication		4.6. Data Duplication
	Data duplication refers to the receipt of multiple copies of a packet		Data duplication refers to the receipt of multiple copies of a packet
	by any leaf. Although this may be a marginal situation, it may also		by any leaf. Although this may be a marginal situation, it may also
	be detrimental for certain applications. Hence, data duplication		be detrimental for certain applications. Hence, data duplication
	SHOULD as much as possible be avoided, and limited to (hopefully		SHOULD be avoided as much as possible and limited to (hopefully rare)
	rare) transitory conditions.		transitory conditions.
	Note, in particular, that data duplication might occur if P2MP LSP		Note, in particular, that data duplication might occur if P2MP LSP
	rerouting is being performed (See also Section 4.8).		rerouting is being performed (see also Section 4.8).
	4.7. Detecting and Avoiding Loops		4.7. Detecting and Avoiding Loops
	The P2MP LDP extension MUST have a mechanism to detect routing loops.		The P2MP LDP extension MUST have a mechanism to detect routing loops.
	This MAY rely on extensions to the LDP Loop detection mechanism		This MAY rely on extensions to the LDP loop detection mechanism
	defined in [RFC5036]. A loop detection mechanism MAY require		defined in [RFC5036]. A loop detection mechanism MAY require
	recording the set of LSRs traversed on the P2MP Tree. The P2MP loop		recording the set of LSRs traversed on the P2MP tree. The P2MP loop
	avoidance mechanism MUST NOT impact the scalability of the P2MP LDP		avoidance mechanism MUST NOT impact the scalability of the P2MP LDP
	solution.		solution.
	The P2MP LDP mechanism SHOULD have a mechanism to avoid routing loops		The P2MP LDP mechanism SHOULD have a mechanism to avoid routing loops
	in the data plane even during transient events.		in the data plane even during transient events.
	Furthermore, the P2MP LDP mechanism MUST avoid routing loops in the		Furthermore, the P2MP LDP mechanism MUST avoid routing loops in the
	data plane, that may trigger unexpected non-localized exponential		data plane, which may trigger unexpected non-localized exponential
	growth of traffic.		growth of traffic.
	4.8. P2MP LSP Re-routing		4.8. P2MP LSP Rerouting
	The P2MP LDP mechanism MUST support the rerouting of a P2MP LSP in		The P2MP LDP mechanism MUST support the rerouting of a P2MP LSP in
	the following cases:		the following cases:
	o Network failure (link or node);		o Network failure (link or node);
	o A better path exists (e.g. new link, metric change);		o A better path exists (e.g., new link or metric change); and
	o Planned maintenance.		o Planned maintenance.
	Given that P2MP LDP routing should rely on the RIB, the achievement		Given that P2MP LDP routing should rely on the RIB, the achievement
	of the following requirements relies on the underlying routing		of the following requirements relies on the underlying routing
	protocols (IGP, etc.).		protocols (IGP, etc.).
	4.8.1. Rerouting upon Network Failure		4.8.1. Rerouting upon Network Failure
	The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case		The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case
	of link or node failure(s), by relying upon update of the routes in		of link or node failure(s) by relying upon update of the routes in
	the RIB. The rerouting time SHOULD be minimized as much as possible		the RIB. The rerouting time SHOULD be minimized as much as possible
	so as to reduce traffic disruption.		so as to reduce traffic disruption.
	A mechanism MUST be defined to prevent constant P2MP LSP teardown and		A mechanism MUST be defined to prevent constant P2MP LSP teardown and
	rebuild which may be caused by the instability of a specific link/		rebuild, which may be caused by the instability of a specific link/
	node in the network. This can rely on IGP dampening but may be		node in the network. This can rely on IGP dampening but may be
	completed by specific dampening at the LDP level.		completed by specific dampening at the LDP level.
	4.8.2. Rerouting on a Better Path		4.8.2. Rerouting on a Better Path
	The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case		The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case
	a better path is created in the network, for instance as a result of		a better path is created in the network, for instance, as a result of
	a metric change, a link repair, or the addition of links or nodes.		a metric change, a link repair, or the addition of links or nodes.
	This will rely on update of the routes in the RIB.		This will rely on update of the routes in the RIB.
	4.8.3. Rerouting upon Planned Maintenance		4.8.3. Rerouting upon Planned Maintenance
	The P2MP LDP mechanism MUST support planned maintenance operations.		The P2MP LDP mechanism MUST support planned maintenance operations.
	It MUST be possible to reroute a P2MP LSP before a link/node is		It MUST be possible to reroute a P2MP LSP before a link/node is
	deactivated for maintenance purposes. Traffic disruption and data		deactivated for maintenance purposes. Traffic disruption and data
	duplication SHOULD be minimized as much as possible during such		duplication SHOULD be minimized as much as possible during such
	planned maintenance. P2MP LSP rerouting upon planned maintenance MAY		planned maintenance. P2MP LSP rerouting upon planned maintenance MAY
	rely on a make before break procedure.		rely on a make-before-break procedure.
	4.9. Support for Multi-Access Networks		4.9. Support for Multi-Access Networks
	The P2MP LDP mechanism SHOULD provide a way for a Branch LSR to send		The P2MP LDP mechanism SHOULD provide a way for a Branch LSR to send
	a single copy of the data onto an interface to a multi-access network		a single copy of the data onto an interface to a multi-access network
	(e.g. an Ethernet LAN) and reach multiple adjacent downstream nodes.		(e.g., an Ethernet LAN) and reach multiple adjacent downstream nodes.
	This requires that the same label be negotiated with all downstream		This requires that the same label be negotiated with all downstream
	LSRs for the LSP.		LSRs for the LSP.
	When there are several candidate upstream LSRs on an interface to a		When there are several candidate upstream LSRs on an interface to a
	multi-access LAN, the P2MP LDP mechanism SHOULD provide a way for all		multi-access LAN, the P2MP LDP mechanism SHOULD provide a way for all
	downstream LSRs of a given P2MP LSP to select the same upstream LSR,		downstream LSRs of a given P2MP LSP to select the same upstream LSR,
	so as to avoid traffic replication. In addition, the P2MP LDP		so as to avoid traffic replication. In addition, the P2MP LDP
	mechanism SHOULD allow for an efficient balancing of a set of P2MP		mechanism SHOULD allow for an efficient balancing of a set of P2MP
	LSPs among a set of candidate upstream LSRs on a LAN interface.		LSPs among a set of candidate upstream LSRs on a LAN interface.
	skipping to change at page 13, line 21		skipping to change at page 13, line 28
	separate P2P and P2MP LDP sessions.		separate P2P and P2MP LDP sessions.
	4.12. IPv4/IPv6 Support		4.12. IPv4/IPv6 Support
	The P2MP LDP mechanism MUST support the establishment of LDP sessions		The P2MP LDP mechanism MUST support the establishment of LDP sessions
	over both IPv4 and IPv6 control planes.		over both IPv4 and IPv6 control planes.
	4.13. Multi-Area/AS LSPs		4.13. Multi-Area/AS LSPs
	The P2MP LDP mechanism MUST support the establishment of multi-area		The P2MP LDP mechanism MUST support the establishment of multi-area
	P2MP LSPs, i.e. LSPs whose leaves do not all reside in the same IGP		P2MP LSPs, i.e., LSPs whose leaves do not all reside in the same IGP
	area as the Ingress LSR. This SHOULD be possible without requiring		area as the Ingress LSR. This SHOULD be possible without requiring
	the advertisement of Ingress LSRs' addresses across IGP areas.		the advertisement of Ingress LSRs' addresses across IGP areas.
	The P2MP LDP mechanism MUST also support the establishment of		The P2MP LDP mechanism MUST also support the establishment of
	inter-AS P2MP LSPs, i.e. LSPs whose leaves do not all reside in the		inter-AS P2MP LSPs, i.e., LSPs whose leaves do not all reside in the
	same AS as the Ingress LSR. This SHOULD be possible without		same AS as the Ingress LSR. This SHOULD be possible without
	requiring the advertisement of Ingress LSRs' addresses across ASes.		requiring the advertisement of Ingress LSRs' addresses across ASes.
	4.14. OAM		4.14. OAM
	LDP management tools ([RFC3815], etc.) will have to be enhanced to		LDP management tools ([RFC3815], etc.) will have to be enhanced to
	support P2MP LDP extensions. This may yield a new MIB module, which		support P2MP LDP extensions. This may yield a new MIB module, which
	may possibly be inherited from the LDP MIB.		may possibly be inherited from the LDP MIB.
	Built-in diagnostic tools MUST be defined to check the connectivity,		Built-in diagnostic tools MUST be defined to check the connectivity,
	trace the path and ensure fast detection of data plane failures on		trace the path, and ensure fast detection of data plane failures on
	P2MP LDP LSPs.		P2MP LDP LSPs.
	Further and precise requirements and mechanisms for P2MP MPLS OAM		Further and precise requirements and mechanisms for P2MP MPLS
	purpose are out of the scope of this document and are addressed in		Operations, Administration, and Maintenance (OAM) purposes are out of
	[RFC4687].		the scope of this document and are addressed in [RFC4687].
	4.15. Graceful Restart and Fault Recovery		4.15. Graceful Restart and Fault Recovery
	LDP Graceful Restart mechanisms [RFC3478] and Fault Recovery		LDP Graceful Restart mechanisms [RFC3478] and Fault Recovery
	mechanisms [RFC3479] SHOULD be enhanced to support P2MP LDP LSPs.		mechanisms [RFC3479] SHOULD be enhanced to support P2MP LDP LSPs.
	4.16. Robustness		4.16. Robustness
	A solution MUST be designed to re-establish connectivity for P2MP and		A solution MUST be designed to re-establish connectivity for P2MP and
	MP2MP LSPs in the event of failures, provided there exists network		MP2MP LSPs in the event of failures, provided there exists network
	connectivity between ingress and egress nodes (i.e. designed without		connectivity between ingress and egress nodes (i.e., designed without
	introducing single points of failure).		introducing single points of failure).
	4.17. Scalability		4.17. Scalability
	Scalability is a key requirement for the P2MP LDP mechanism. It MUST		Scalability is a key requirement for the P2MP LDP mechanism. It MUST
	be designed to scale well with an increase in the number of any of		be designed to scale well with an increase in the number of any of
	the following:		the following:
	o number of Leaf LSRs per P2MP LSP;		o Number of Leaf LSRs per P2MP LSP;
	o number of Downstream LSRs per Branch LSR;		o Number of downstream LSRs per Branch LSR; and
	o number of P2MP LSPs per LSR.		o Number of P2MP LSPs per LSR.
	In order to scale well with an increase in the number of leaves, it		In order to scale well with an increase in the number of leaves, it
	is RECOMMENDED that the size of a P2MP LSP state on a LSR, for one		is RECOMMENDED that the size of a P2MP LSP state on an LSR, for one
	particular LSP, depend only on the number of adjacent LSRs on the		particular LSP, depend only on the number of adjacent LSRs on the
	LSP.		LSP.
	4.17.1. Orders of Magnitude Expected in Operational Networks		4.17.1. Orders of Magnitude Expected in Operational Networks
	Typical orders of magnitude that we expect should be supported are:		Typical orders of magnitude that we expect should be supported are:
	o tens of thousands of P2MP trees spread out across core network		o Tens of thousands of P2MP trees spread out across core network
	routers;		routers; and
	o hundreds, or a few thousands, of leaves per tree;		o Hundreds, or a few thousands, of leaves per tree.
	See also section 4.2 of [RFC4834].		See also Section 4.2 of [RFC4834].
	4.18. Backward Compatibility		4.18. Backward Compatibility
	In order to allow for a smooth migration, the P2MP LDP mechanism		In order to allow for a smooth migration, the P2MP LDP mechanism
	SHOULD offer as much backward compatibility as possible. In		SHOULD offer as much backward compatibility as possible. In
	particular, the solution SHOULD allow the setup of a P2MP LSP along		particular, the solution SHOULD allow the setup of a P2MP LSP along
	non-Branch Transit LSRs that do not support P2MP LDP extensions.		non-Branch Transit LSRs that do not support P2MP LDP extensions.
	Also, the P2MP LDP solution MUST co-exist with current LDP mechanisms		Also, the P2MP LDP solution MUST coexist with current LDP mechanisms
	and inherit its capability sets from [RFC5036]. The P2MP LDP		and inherit its capability sets from [RFC5036]. The P2MP LDP
	solution MUST NOT impede the operation of P2P/MP2P LSPs. A P2MP LDP		solution MUST NOT impede the operation of P2P/MP2P LSPs. A P2MP LDP
	solution MUST be designed in such a way that it allows P2P/MP2P and		solution MUST be designed in such a way that it allows P2P/MP2P and
	P2MP LSPs to be signalled on the same interface.		P2MP LSPs to be signaled on the same interface.
	5. Shared Trees		5. Shared Trees
	For traffic delivery between a group of N LSRs that act as egress		For traffic delivery between a group of N LSRs that act as egress
	and/or egress nodes on different P2MP flows, it may be useful to		and/or egress nodes on different P2MP flows, it may be useful to set
	setup a shared tree connecting all these LSRs, instead of having N		up a shared tree connecting all these LSRs instead of having N P2MP
	P2MP LSPs. This would reduce the amount of control and forwarding		LSPs. This would reduce the amount of control and forwarding state
	state that has to be maintained on a given LSR.		that has to be maintained on a given LSR.
	There are actually two main options for supporting such shared trees:		There are two main options for supporting such shared trees:
	o This could rely on the applications protocols that use LDP LSPs.		o Relying on the applications' protocols that use LDP LSPs. A
	A shared tree could consist of the combination of a MP2P LDP LSP		shared tree could consist of the combination of an MP2P LDP LSP
	from Leafs LSRs to a given root node, with a P2MP LSP from this		from Leaf LSRs to a given root node with a P2MP LSP from this root
	root to Leaf LSRs. For instance with Multicast L3 VPN		to Leaf LSRs. For instance, with Multicast L3 VPN applications,
	applications, it would be possible to build a shared tree by		it would be possible to build a shared tree by combining (see
	combining (see [I-D.ietf-l3vpn-2547bis-mcast]):		[MVPN]):
	* a MP2P unicast LDP LSP, from each PE of the group to a		* An MP2P unicast LDP LSP, from each PE router of the group to a
	particular root PE acting as tree root,		particular root PE router acting as tree root and
	* with a P2MP LDP LSP from this root PE to each PE of the group.		* A P2MP LDP LSP from this root PE router to each PE router of
			the group.
	o Or this could rely on a specific LDP mechanism allowing to setup		o Relying on a specific LDP mechanism allowing the setup of
	multipoint-to-multipoint MPLS LSPs (MP2MP LSPs).		multipoint-to-multipoint MPLS LSPs (MP2MP LSPs).
	The former approach (Combination of MP2P and P2MP LSPs at the		The former approach (combination of MP2P and P2MP LSPs at the
	application level) is out of the scope of this document while the		application level) is out of the scope of this document while the
	latter (MP2MP LSPs) belong to the scope of this document.		latter (MP2MP LSPs) is within the scope of this document.
	Requirements for the set up of MP2MP LSPs are listed below.		Requirements for the setup of MP2MP LSPs are listed below.
	5.1. Requirements for MP2MP LSPs		5.1. Requirements for MP2MP LSPs
	A Multipoint-to-multipoint (MP2MP) LSP is an LSP connecting a group		A multipoint-to-multipoint (MP2MP) LSP is an LSP connecting a group
	of Leaf LSRs acting as Egress and/or Ingress LSRs. Traffic sent by		of Leaf LSRs acting as Egress and/or Ingress LSRs. Traffic sent by
	any Leaf LSR is received by all other Leaf LSRs of the group.		any Leaf LSR is received by all other Leaf LSRs of the group.
	Procedures for setting up MP2MP LSPs with LDP SHOULD be specified.		Procedures for setting up MP2MP LSPs with LDP SHOULD be specified.
	An implementation that support P2MP LDP LSPs MAY also support MP2MP		An implementation that supports P2MP LDP LSPs MAY also support MP2MP
	LDP LSP.		LDP LSPs.
	The MP2MP LDP procedures MUST NOT impede the operations of P2MP LSP.		The MP2MP LDP procedures MUST NOT impede the operations of P2MP LSP.
	Requirements for P2MP LSPs, set forth in Section 4, apply equally to		Requirements for P2MP LSPs, set forth in Section 4, apply equally to
	MP2MP LSPs. Particular attention should be given on the below		MP2MP LSPs. Particular attention should be given to the requirements
	requirements:		below:
	o The solution MUST support recovery upon link and transit node		o The solution MUST support recovery upon link and transit node
	failure and be designed to re-establish connectivity for MP2MP		failure and be designed to re-establish connectivity for MP2MP
	LSPs in the event of failures, provided there exists network		LSPs in the event of failures, provided network connectivity
	connectivity between ingress and egress nodes (i.e. designed		exists between ingress and egress nodes (i.e., designed without
	without introducing single points of failure);		introducing single points of failure).
	o The size of MP2MP state on a LSR, for one particular MP2MP LSP,		o The size of MP2MP state on an LSR, for one particular MP2MP LSP,
	SHOULD only depend on the number of adjacent LSRs on the LSP;		SHOULD only depend on the number of adjacent LSRs on the LSP.
	o Furthermore, the MP2MP LDP mechanism MUST avoid routing loops that		o Furthermore, the MP2MP LDP mechanism MUST avoid routing loops that
	may trigger exponential growth of traffic. Note that this		may trigger exponential growth of traffic. Note that this
	requirement is more challenging with MP2MP LSPs as a LSR may need		requirement is more challenging with MP2MP LSPs as an LSR may need
	to receive traffic for a given LSP on multiple interfaces.		to receive traffic for a given LSP on multiple interfaces.
	There are additional requirements specific to MP2MP LSPs:		There are additional requirements specific to MP2MP LSPs:
	o It is RECOMMENDED that a MP2MP MPLS LSP is built based on the		o It is RECOMMENDED that an MP2MP MPLS LSP is built based on the
	unicast route to a specific LSR called root LSR;		unicast route to a specific LSR called root LSR.
	o It is RECOMMENDED to define several root LSRs (e.g. a primary and		o It is RECOMMENDED to define several root LSRs (e.g., a primary and
	a backup) to ensure redundancy upon root LSR failure;		a backup) to ensure redundancy upon root LSR failure.
	o The receiver SHOULD NOT receive back a packet it has sent on the		o The receiver SHOULD NOT receive back a packet it has sent on the
	MP2MP LSP;		MP2MP LSP.
	o The solution SHOULD avoid that all traffic between any pair of		o The solution SHOULD avoid that all traffic between any pair of
	leaves is traversing a root LSR (similarly to PIM-Bidir trees) and		leaves is traversing a root LSR (similarly to PIM-Bidir trees) and
	SHOULD provide the operator with means to minimize the delay		SHOULD provide the operator with means to minimize the delay
	between two leaves;		between two leaves.
	o It MUST be possible to check connectivity of a MP2MP LSP in both		o It MUST be possible to check connectivity of an MP2MP LSP in both
	directions.		directions.
	6. Evaluation Criteria		6. Evaluation Criteria
	6.1. Performance		6.1. Performance
	The solution will be evaluated with respect to the following		The solution will be evaluated with respect to the following
	criteria:		criteria:
	(1) Efficiency of network resource usage;		(1) Efficiency of network resource usage;
	(2) Time to add or remove a Leaf LSR;		(2) Time to add or remove a Leaf LSR;
			(3) Time to repair a P2MP LSP in case of link or node failure; and
	(3) Time to repair a P2MP LSP in case of link or node failure;
	(4) Scalability (state size, number of messages, message size).		(4) Scalability (state size, number of messages, message size).
	Particularly the P2MP LDP mechanism SHOULD be designed with as key		Particularly, the P2MP LDP mechanism SHOULD be designed with the key
	objective to minimize the additional amount of state and additional		objective of minimizing the additional amount of state and additional
	processing required in the network.		processing required in the network.
	Also, the P2MP LDP mechanism SHOULD be designed so that convergence		Also, the P2MP LDP mechanism SHOULD be designed so that convergence
	times in case of link or node failure are minimized, in order to		times in case of link or node failure are minimized, in order to
	limit traffic disruption.		limit traffic disruption.
	6.2. Complexity and Risks		6.2. Complexity and Risks
	The proposed solution SHOULD NOT introduce complexity to the current		The proposed solution SHOULD NOT introduce complexity to the current
	LDP operations to such a degree that it would affect the stability		LDP operations to such a degree that it would affect the stability
	and diminish the benefits of deploying such solution.		and diminish the benefits of deploying such solution.
	7. Security Considerations		7. Security Considerations
	It is expected that addressing the requirements defined in this		It is expected that addressing the requirements defined in this
	document should not introduce any new security issue beyond those		document should not introduce any new security issues beyond those
	inherent to LDP, and that a P2MP LDP solution will rely on the		inherent to LDP and that a P2MP LDP solution will rely on the
	security mechanisms defined in [RFC5036] (e.g. TCP MD5 Signature).		security mechanisms defined in [RFC5036] (e.g., TCP MD5 Signature).
	An evaluation of the security features for MPLS networks may be found		An evaluation of the security features for MPLS networks may be found
	in [RFC5920], and where issues or further work is identified by that		in [RFC5920], and where issues or further work is identified by that
	document, new security features or procedures for the MPLS protocols		document, new security features or procedures for the MPLS protocols
	will need to be developed.		will need to be developed.
	8. IANA Considerations		8. Acknowledgments
	This informational document makes no requests to IANA for action.
	9. Acknowledgments
	We would like to thank Christian Jacquenet, Hitoshi Fukuda, Ina		We would like to thank Christian Jacquenet, Hitoshi Fukuda, Ina
	Minei, Dean Cheng, and Benjamin Niven-Jenkins, for their highly		Minei, Dean Cheng, and Benjamin Niven-Jenkins for their highly useful
	useful comments and suggestions. We would also like to thank Adrian		comments and suggestions. We would like to thank Adrian Farrel for
	Farrel for reviewing this document before publication.		reviewing this document before publication.
	We would also like to thank authors of [RFC4461] from which some of
	the text in this document has been inspired.
	10. References
	10.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol		We would also like to thank the authors of [RFC4461], which inspired
	Label Switching Architecture", RFC 3031, January 2001.		some of the text in this document.
	[RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful		9. References
	Restart Mechanism for Label Distribution Protocol",
	RFC 3478, February 2003.
	[RFC3479] Farrel, A., "Fault Tolerance for the Label Distribution		9.1. Normative References
	Protocol (LDP)", RFC 3479, February 2003.
	[RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	of Managed Objects for the Multiprotocol Label Switching		Requirement Levels", BCP 14, RFC 2119, March 1997.
	(MPLS), Label Distribution Protocol (LDP)", RFC 3815,
	June 2004.
	[RFC4461] Yasukawa, S., "Signaling Requirements for Point-to-		[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
	Multipoint Traffic-Engineered MPLS Label Switched Paths		"Multiprotocol Label Switching Architecture", RFC 3031,
	(LSPs)", RFC 4461, April 2006.		January 2001.
	[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP		[RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful
	Specification", RFC 5036, October 2007.		Restart Mechanism for Label Distribution Protocol",
			RFC 3478, February 2003.
	10.2. Informative References		[RFC3479] Farrel, A., "Fault Tolerance for the Label Distribution
			Protocol (LDP)", RFC 3479, February 2003.
	[I-D.ietf-l2vpn-vpls-mcast]		[RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani,
	Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter,		"Definitions of Managed Objects for the Multiprotocol
	"Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-08 (work		Label Switching (MPLS), Label Distribution Protocol
	in progress), October 2010.		(LDP)", RFC 3815, June 2004.
	[I-D.ietf-l3vpn-2547bis-mcast]		[RFC4461] Yasukawa, S., "Signaling Requirements for Point-to-
	Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y.,		Multipoint Traffic-Engineered MPLS Label Switched Paths
	Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in		(LSPs)", RFC 4461, April 2006.
	MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work
	in progress), January 2010.
	[I-D.ietf-mpls-ldp-p2mp]		[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
	Minei, I., Wijnands, I., Kompella, K., and B. Thomas,		Specification", RFC 5036, October 2007.
	"Label Distribution Protocol Extensions for Point-to-
	Multipoint and Multipoint-to-Multipoint Label Switched
	Paths", draft-ietf-mpls-ldp-p2mp-13 (work in progress),
	April 2011.
	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,		9.2. Informative References
	and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
	Tunnels", RFC 3209, December 2001.
	[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual		[MLDP] Minei, I., Wijnands, I., Kompella, K., and B. Thomas,
	Private Network (VPN) Terminology", RFC 4026, March 2005.		"Label Distribution Protocol Extensions for Point-to-
			Multipoint and Multipoint-to-Multipoint Label Switched
			Paths", Work in Progress, August 2011.
	[RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau,		[MVPN] Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter,
	"Operations and Management (OAM) Requirements for Point-		Y., Rosen, E., Wijnands, I., and S. Yasukawa,
	to-Multipoint MPLS Networks", RFC 4687, September 2006.		"Multicast in MPLS/BGP IP VPNs", Work in Progress,
			January 2010.
	[RFC4834] Morin, T., Ed., "Requirements for Multicast in Layer 3		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
	Provider-Provisioned Virtual Private Networks (PPVPNs)",		V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
	RFC 4834, April 2007.		LSP Tunnels", RFC 3209, December 2001.
	[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,		[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned
	"Extensions to Resource Reservation Protocol - Traffic		Virtual Private Network (VPN) Terminology", RFC 4026,
	Engineering (RSVP-TE) for Point-to-Multipoint TE Label		March 2005.
	Switched Paths (LSPs)", RFC 4875, May 2007.
	[RFC5501] Kamite, Y., Wada, Y., Serbest, Y., Morin, T., and L. Fang,		[RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau,
	"Requirements for Multicast Support in Virtual Private LAN		"Operations and Management (OAM) Requirements for
	Services", RFC 5501, March 2009.		Point-to-Multipoint MPLS Networks", RFC 4687,
			September 2006.
	[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS		[RFC4834] Morin, T., Ed., "Requirements for Multicast in Layer 3
	Networks", RFC 5920, July 2010.		Provider-Provisioned Virtual Private Networks
			(PPVPNs)", RFC 4834, April 2007.
	Authors' Addresses		[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
			"Extensions to Resource Reservation Protocol - Traffic
			Engineering (RSVP-TE) for Point-to-Multipoint TE Label
			Switched Paths (LSPs)", RFC 4875, May 2007.
	Jean-Louis Le Roux (editor)		[RFC5501] Kamite, Y., Wada, Y., Serbest, Y., Morin, T., and L.
	France Telecom - Orange		Fang, "Requirements for Multicast Support in Virtual
			Private LAN Services", RFC 5501, March 2009.
	Email: jeanlouis.leroux@orange-ftgroup.com		[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
			Networks", RFC 5920, July 2010.
	Thomas Morin (editor)		[VPLS-MCAST] Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter,
	France Telecom - Orange		"Multicast in VPLS", Work in Progress, July 2011.
	Email: thomas.morin@orange-ftgroup.com		Contributing Authors
	Vincent Parfait		Vincent Parfait
	France Telecom - Orange, Orange Business Services		France Telecom - Orange, Orange Business Services
	Email: vincent.parfait@orange-ftgroup.com		EMail: vincent.parfait@orange-ftgroup.com
	Luyuan Fang		Luyuan Fang
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Email: lufang@cisco.com		EMail: lufang@cisco.com
	Lei Wang		Lei Wang
	Telenor		Telenor
	Email: lei.wang@telenor.com		EMail: lei.wang@telenor.com
	Yuji Kamite		Yuji Kamite
	NTT Communications Corporation		NTT Communications Corporation
	Email: y.kamite@ntt.com		EMail: y.kamite@ntt.com
	Shane Amante		Shane Amante
	Level 3 Communications, LLC		Level 3 Communications, LLC
	Email: shane@level3.net		EMail: shane@level3.net
			Authors' Addresses
			Jean-Louis Le Roux (editor)
			France Telecom - Orange
			EMail: jeanlouis.leroux@orange-ftgroup.com
			Thomas Morin (editor)
			France Telecom - Orange
			EMail: thomas.morin@orange-ftgroup.com
End of changes. 148 change blocks.
	312 lines changed or deleted		295 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/