draft-ietf-mpls-mp-ldp-reqs-00.txt		draft-ietf-mpls-mp-ldp-reqs-01.txt
	Network Working Group J.-L. Le Roux (Editor)		Network Working Group J.-L. Le Roux (Editor)
	Internet Draft France Telecom		Internet Draft France Telecom
	Category: Informational		Category: Informational
	Expires: November 2006 T. Morin		Expires: January 2007 T. Morin
	France Telecom		France Telecom
	Vincent Parfait		Vincent Parfait
	Equant		Equant
	Luyuan Fang		Luyuan Fang
	AT&T		AT&T
	Lei Wang		Lei Wang
	Telenor		Telenor
	Yuji Kamite		Yuji Kamite
	NTT Communications		NTT Communications
	Shane Amante		Shane Amante
	Level 3 Communications		Level 3 Communications
	Requirements for point-to-multipoint extensions to		Requirements for point-to-multipoint extensions to
	the Label Distribution Protocol		the Label Distribution Protocol
	draft-ietf-mpls-mp-ldp-reqs-00.txt		draft-ietf-mpls-mp-ldp-reqs-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of 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 other		Task Force (IETF), its areas, and its working groups. Note that other
	skipping to change at page 2, line 36		skipping to change at page 2, line 36
	3.1. Problem Statement...........................................5		3.1. Problem Statement...........................................5
	3.2. Requirements overview.......................................5		3.2. Requirements overview.......................................5
	4. Application scenario........................................6		4. Application scenario........................................6
	5. Detailed Requirements.......................................7		5. Detailed Requirements.......................................7
	5.1. P2MP LSPs...................................................7		5.1. P2MP LSPs...................................................7
	5.2. P2MP LSP FEC................................................7		5.2. P2MP LSP FEC................................................7
	5.3. P2MP LDP routing............................................8		5.3. P2MP LDP routing............................................8
	5.4. Setting up, tearing down and modifying P2MP LSPs............8		5.4. Setting up, tearing down and modifying P2MP LSPs............8
	5.5. Label Advertisement.........................................8		5.5. Label Advertisement.........................................8
	5.6. Data Duplication............................................8		5.6. Data Duplication............................................8
	5.7. Avoiding loops..............................................8		5.7. Avoiding loops..............................................9
	5.8. P2MP LSP Re-routing.........................................9		5.8. P2MP LSP Re-routing.........................................9
	5.8.1. Rerouting upon Network Failure..............................9		5.8.1. Rerouting upon Network Failure..............................9
	5.8.2. Rerouting on a Better Path..................................9		5.8.2. Rerouting on a Better Path..................................9
	5.8.3. Rerouting upon Planned Maintenance..........................9		5.8.3. Rerouting upon Planned Maintenance.........................10
	5.9. Support for LAN interfaces.................................10		5.9. Support for LAN interfaces.................................10
	5.10. Support for encapsulation in P2P and P2MP TE tunnels........10		5.10. Support for encapsulation in P2P and P2MP TE tunnels.......10
	5.11. Label spaces................................................10		5.11. Label spaces...............................................10
	5.12. IPv4/IPv6 support...........................................10		5.12. IPv4/IPv6 support..........................................11
	5.13. Multi-Area LSPs.............................................10		5.13. Multi-Area LSPs............................................11
	5.14. OAM.........................................................11		5.14. OAM........................................................11
	5.15. Graceful Restart and Fault Recovery.........................11		5.15. Graceful Restart and Fault Recovery........................11
	5.16. Robustness..................................................11		5.16. Robustness.................................................11
	5.17. Scalability.................................................11		5.17. Scalability................................................11
	5.17.1. Orders of magnitude of the expected numbers of P2MP		5.17.1. Orders of magnitude of the expected numbers of P2MP
	LSPs in operational networks.............................11		LSPs in operational networks.............................12
	5.18. Backward Compatibility......................................12		5.18. Backward Compatibility.....................................12
	6. Shared Trees...............................................12		6. Shared Trees...............................................12
	6.1. MP2MP LSPs.................................................12		6.1. Requirements for MP2MP LSPs................................13
	7. Evaluation criteria........................................13		7. Evaluation criteria........................................14
	7.1. Performances...............................................13		7.1. Performances...............................................14
	7.2. Complexity and Risks.......................................13		7.2. Complexity and Risks.......................................14
	8. Security Considerations....................................13		8. Security Considerations....................................14
	9. Acknowledgments............................................13		9. Acknowledgments............................................14
	10. References.................................................14		10. References.................................................14
			10.1. Normative references.......................................14
			10.2. Informative references.....................................15
	11. Editor Address.............................................15		11. Editor Address.............................................15
	12. Contributors Addresses.....................................15		12. Contributors Addresses.....................................16
	13. Intellectual Property Statement............................16		13. Intellectual Property Statement............................17
	1. Terminology		1. Terminology
	LSR: Label Switching Router		LSR: Label Switching Router
	LSP: MPLS Label Switched Path		LSP: MPLS Label Switched Path
	Ingress LSR: Router acting as a sender of an LSP		Ingress LSR: Router acting as a sender of an LSP
	Egress LSR: Router acting as a receiver of an LSP		Egress LSR: Router acting as a receiver of an LSP
	P2P LSP: A LSP that has one unique Ingress LSR and one unique		P2P LSP: A LSP that has one unique Ingress LSR and one unique
	Egress LSR		Egress LSR
	MP2P LSP: A LSP that has one or more Ingress LSRs and one unique		MP2P LSP: A LSP that has one or more Ingress LSRs and one unique
	Egress LSR		Egress LSR
	P2MP LSP: A LSP that has one unique Ingress LSR and one or more		P2MP LSP: A LSP that has one unique Ingress LSR and one or more
	Egress LSRs		Egress LSRs
	Leaf LSR: Egress LSR of a P2MP LSP		MP2MP LSP: A LSP that as one or more Leaf LSRs acting
			indifferently as Ingress or Egress LSR
			Leaf LSR: Egress LSR of a P2MP LSP or Ingress/Egress LSR of a
			MP2MP LSP
	Transit LSR: A LSR of a P2MP LSP that has one or more downstream		Transit LSR: A LSR of a P2MP LSP that has one or more downstream
	LSRs		LSRs
	Branch LSR: A LSR of a P2MP LSP that has more than one downstream		Branch LSR: A LSR of a P2MP LSP that has more than one downstream
	LSR		LSR
	Bud LSR: A LSR of a P2MP LSP that is an egress but also has one or		Bud LSR: A LSR of a P2MP LSP that is an egress but also has one or
	more directly connected downstream LSRs		more directly connected downstream LSRs
	skipping to change at page 4, line 31		skipping to change at page 4, line 31
	They meet requirements expressed in [P2MP-TE-REQ]. This approach is		They meet requirements expressed in [P2MP-TE-REQ]. This approach is
	useful, in network environments where P2MP Traffic Engineering		useful, in network environments where P2MP Traffic Engineering
	capabilities are needed (Optimization, QoS, Fast recovery).		capabilities are needed (Optimization, QoS, Fast recovery).
	However for operators who want to support point-to-multipoint traffic		However for operators who want to support point-to-multipoint traffic
	delivery on an MPLS backbone, without Traffic Engineering needs, and		delivery on an MPLS backbone, without Traffic Engineering needs, and
	have already deployed LDP for P2P traffic, an interesting and useful		have already deployed LDP for P2P traffic, an interesting and useful
	approach would be to rely on LDP extensions in order to setup point-		approach would be to rely on LDP extensions in order to setup point-
	to-multipoint (P2MP) LSPs. This would bring consistency with P2P MPLS		to-multipoint (P2MP) LSPs. This would bring consistency with P2P MPLS
	applications and would ease the delivery of point-to-multipoint		applications and would ease the delivery of point-to-multipoint
	applications in an MPLS backbone.		services in an MPLS backbone.
	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 a LDP-enabled MPLS infrastructure.
	These requirements should be used as guidelines when specifying LDP		These requirements should be used as guidelines when specifying LDP
	extensions. It is intended that solutions that specify LDP procedures		extensions. It is intended that solutions that specify LDP procedures
	for P2MP LSP setup, satisfy these requirements.		for P2MP LSP setup, satisfy these requirements.
	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 solution
	specific requirements related to LDP extensions in order to set up		specific requirements related to LDP extensions in order to set up
	P2MP LSPs.		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, such as for instance PIM extensions, but these are out of the
	scope of this document. The objective is not to compare these		scope of this document. The objective is not to compare these
	mechanisms but rather to focus on the requirements for an LDP		mechanisms but rather to focus on the requirements for an LDP
	extension approach.		extension approach.
	The document is structured as follows:		The document is structured as follows:
	- Section 3 points out the problem statement.		- Section 3 points out the problem statement;
	- Section 4 illustrates an application scenario.		- Section 4 illustrates an application scenario;
	- Section 5 addresses detailed requirements.		- Section 5 addresses detailed requirements for P2MP LSPs;
	- Section 6 finally discusses group communication.		- Section 6 finally discusses group communication, and
			requirements for MP2MP LSPs.
	3. Problem Statement and Requirements Overview		3. Problem Statement and Requirements Overview
	3.1. Problem Statement		3.1. Problem Statement
	Many operators have deployed LDP [LDP] for setting up P2P and MP2P		Many operators have deployed LDP [LDP] for setting up P2P and MP2P
	MPLS LSPs as PE-to-PE tunnels so as to carry point-to-point traffic		MPLS LSPs as PE-to-PE tunnels so as to carry point-to-point traffic
	essentially in Layer 3 and Layer 2 VPN networks. There are emerging		essentially in Layer 3 and Layer 2 VPN networks. There are emerging
	requirements for supporting multicast traffic delivery within these		requirements for supporting multicast traffic delivery within these
	VPN infrastructures ([L3VPN-MCAST-REQ] and [L2VPN-MCAST-REQ]). For		VPN infrastructures ([L3VPN-MCAST-REQ] and [L2VPN-MCAST-REQ]). For
	skipping to change at page 5, line 47		skipping to change at page 5, line 47
	The following gives a set of guidelines that a specification of LDP		The following gives a set of guidelines that a specification of LDP
	extensions for setting up P2MP LSPs should follow.		extensions for setting up P2MP LSPs should follow.
	3.2. Requirements overview		3.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 arbitrary addition or removal		The P2MP LDP mechanism MUST allow the addition or removal of leaves
	of leaves associated with a P2MP LSP.		associated with a P2MP LSP.
	The P2MP LDP mechanism MUST interoperate seamlessly with existing P2P		The P2MP LDP mechanism MUST co-exist with current LDP mechanisms and
	and MP2P LDP mechanisms.		inherit its capability sets from [LDP]. It is of paramount importance
	It is of paramount importance that the P2MP LDP mechanism MUST NOT		that the P2MP LDP mechanism MUST NOT impede the operation of existing
	impede the operation of existing P2P/MP2P LSPs.		P2P/MP2P LSPs.
	Note that the P2MP LDP mechanism MAY also allow setting up		The P2MP LDP mechanism MAY also allow setting up multipoint-to-
	multipoint-to-multipoint (MP2MP) LSPs connecting a group of Leaf LSRs		multipoint (MP2MP) LSPs connecting a group of Leaf LSRs acting
	acting indifferently as Ingress LSR or Egress LSR. This may allow		indifferently as Ingress LSR or Egress LSR. This may allow a
	a reduction in the amount of LDP state that must be		reduction in the amount of LDP state that needs to be maintained by a
	maintained by a LSR. Detailed requirements for MP2MP LSPs are left		LSR.
	for further study.
	4. Application scenario		4. 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 [2547-MCAST] for		following for instance the architecture defined in [2547-MCAST] for
	BGP/MPLS VPNs, or the one defined in [VPLS-MCAST].		BGP/MPLS VPNs, or the one defined in [VPLS-MCAST].
	MP2P LDP LSPs are setup between PE routers to carry unicast VPN		A set of MP2P LDP LSPs are setup between PE routers to carry unicast
	traffic.		VPN traffic within the MPLS backbone.
	A set of P2MP LDP LSPs are setup between PE routers acting as Ingress		A set of P2MP LDP LSPs are setup between PE routers acting as Ingress
	LSRs and PE routers acting as Egress LSRs, so as to support multicast		LSRs and PE routers acting as Egress LSRs, so as to support multicast
	VPN traffic delivery within the MPLS backbone.		VPN traffic delivery within the MPLS backbone.
	For instance, a P2MP LDP LSP is setup between Ingress LSR PE1 and		For instance, a P2MP LDP LSP is setup 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 are
	non-branch transit LSRs, they forward MPLS traffic sent by P1 to PE3		non-branch transit LSRs, they forward MPLS traffic sent by P1 to PE3
	skipping to change at page 8, line 29		skipping to change at page 8, line 29
	network and a large amount of leaf LSRs for a single P2MP LSP.		network and a large amount of leaf LSRs for a single P2MP LSP.
	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 LSPs 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. It is RECOMMENDED that these		leaves to and from a P2MP LSP, without any restriction (provided
			there is network connectivity). It is RECOMMENDED that these
	operations be leaf-initiated.		operations be leaf-initiated.
	It is RECOMMENDED that these operations do not cause any additional		These operations MUST not impact the data transfer (packet loss,
	processing except on the path from the added/removed Leaf LSR to		duplication, delay) towards other leaves. It is RECOMMENDED that
	the Branch LSR.		these operations do not cause any additional processing except on the
			path from the added/removed Leaf LSR to the Branch LSR.
	5.5. Label Advertisement		5.5. Label Advertisement
	The P2MP LDP mechanism SHOULD support downstream unsolicited label		The P2MP LDP mechanism SHOULD support downstream unsolicited label
	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.
	5.6. Data Duplication		5.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
	skipping to change at page 9, line 14		skipping to change at page 9, line 19
	Furthermore, the P2MP LDP mechanism MUST avoid routing loops that may		Furthermore, the P2MP LDP mechanism MUST avoid routing loops that may
	trigger unexpected non-localized exponential growth of traffic. Note		trigger unexpected non-localized exponential growth of traffic. Note
	that any loop-avoidance mechanism MUST respect scalability		that any loop-avoidance mechanism MUST respect scalability
	requirements.		requirements.
	5.8. P2MP LSP Re-routing		5.8. P2MP LSP Re-routing
	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:
	- Network failure (link or node)		- Network failure (link or node);
	- A better path exists (e.g. new link, metric change)		- A better path exists (e.g. new link, metric change);
	- Planned maintenance		- Planned maintenance.
	Given that P2MP LDP routing must rely on the RIB, the achievement of		Given that P2MP LDP routing should rely on the RIB, the achievement
	the following requirements also implies the underlying routing		of the following requirements also implies the underlying routing
	protocols (IGP, etc.).		protocols (IGP, etc.).
	5.8.1. Rerouting upon Network Failure		5.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). The rerouting time SHOULD be minimized as		of link or node failure(s). The rerouting time SHOULD be minimized as
	much as possible so as to reduce traffic disruption.		much as possible 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		rebuild which may be caused by the instability of a specific
	link/node in the network.		link/node in the network.
	5.8.2. Rerouting on a Better Path		5.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, or the addition of links or nodes.		a metric change, a link repair, or the addition of links or nodes.
	Traffic disruption SHOULD be minimized as much as possible during		Traffic disruption and data duplication SHOULD be minimized as much
	such rerouting. It SHOULD be feasible to avoid packet loss during		as possible during such rerouting.
	such rerouting.		There is actually a tension between packet loss minimization and
	Unnecessary data duplication during such rerouting SHOULD also be		packet duplication minimization objectives.
	minimized as much as possible.		It SHOULD be feasible to avoid either data duplication or packet loss
			during such rerouting.
	Note that there is likely to be a tension between packet loss		A solution MAY provide the operator with means to choose between
	minimization and packet duplication minimization objectives.		favoring avoiding packet loss at the expense of potential packet
			duplication, and favoring avoiding duplication against packet loss.
	5.8.3. Rerouting upon Planned Maintenance		5.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 SHOULD be		deactivated for maintenance purposes.
	minimized as much as possible during such rerouting. It SHOULD be		Traffic disruption and data duplication SHOULD be minimized as much
	feasible to avoid packet loss during such rerouting.		as possible during such planned maintenance.
	Unnecessary traffic duplication during such rerouting SHOULD also be		There is actually a tension between packet loss minimization and
	minimized as much as possible.		packet duplication minimization objectives.
			It SHOULD be feasible to avoid either data duplication or packet loss
	Note that there is likely to be a tension between packet loss		during such rerouting.
	minimization and packet duplication minimization objectives.		A solution MAY provide the operator with means to choose between
			favoring avoiding packet loss at the expense of packet duplication,
			and favoring avoiding duplication against packet loss.
	5.9. Support for LAN interfaces		5.9. Support for LAN interfaces
	The P2MP LDP mechanism MUST provide a way for a Branch LSR to send a		The P2MP LDP mechanism MUST provide a way for a Branch LSR to send a
	single copy of the data onto an Ethernet LAN interface and reach		single copy of the data onto an Ethernet LAN interface and reach
	multiple adjacent downstream nodes. This requires that the same label		multiple adjacent downstream nodes. This requires that the same label
	be negotiated with all downstream LSRs for the LSP.		be negotiated with all downstream LSRs for the LSP.
	When there are several candidate upstream LSRs on a LAN interface,		When there are several candidate upstream LSRs on a LAN interface,
	the P2MP LDP mechanism MUST provide a way for all downstream LSRs of		the P2MP LDP mechanism MUST provide a way for all downstream LSRs of
	skipping to change at page 10, line 40		skipping to change at page 10, line 52
	on the P2MP LSP, which are also Egress LSRs of the tunnel. As with		on the P2MP LSP, which are also Egress LSRs of the tunnel. As with
	LAN interfaces, this requires that the same LDP label be negotiated		LAN interfaces, this requires that the same LDP label be negotiated
	with all downstream LSRs for the P2MP LDP LSP.		with all downstream LSRs for the P2MP LDP LSP.
	5.11. Label spaces		5.11. Label spaces
	Labels for P2MP LSPs and P2P/MP2P LSPs MAY be assigned from shared or		Labels for P2MP LSPs and P2P/MP2P LSPs MAY be assigned from shared or
	dedicated label spaces.		dedicated label spaces.
	Note that dedicated label spaces will require the establishment of		Note that dedicated label spaces will require the establishment of
	separate P2MP LDP sessions.		separate P2P and P2MP LDP sessions.
	5.12. IPv4/IPv6 support		5.12. IPv4/IPv6 support
	The P2MP LDP mechanism MUST be equally applicable to IPv4 and IPv6		The P2MP LDP mechanism MUST be equally applicable to IPv4 and IPv6
	traffic. Likewise, it SHOULD be possible to convey both kinds of		traffic. Likewise, it SHOULD be possible to convey both kinds of
	traffic in a given P2MP LSP facility.		traffic in a given P2MP LSP facility.
	Also the P2MP LDP mechanism MUST support the establishment of LDP		Also the P2MP LDP mechanism MUST support the establishment of LDP
	sessions over both IPv4 and IPv6 control planes.		sessions over both IPv4 and IPv6 control planes.
	skipping to change at page 11, line 30		skipping to change at page 11, line 46
	purpose are out of the scope of this document and are addressed in		purpose are out of the scope of this document and are addressed in
	[P2MP-OAM-REQ].		[P2MP-OAM-REQ].
	5.15. Graceful Restart and Fault Recovery		5.15. Graceful Restart and Fault Recovery
	LDP Graceful Restart mechanisms [LDP-GR] and Fault Recovery [LDP-FT]		LDP Graceful Restart mechanisms [LDP-GR] and Fault Recovery [LDP-FT]
	mechanisms SHOULD be enhanced to support P2MP LDP LSPs.		mechanisms SHOULD be enhanced to support P2MP LDP LSPs.
	5.16. Robustness		5.16. Robustness
	A solution SHOULD avoid single points of failures or propose some		A solution MUST avoid single points of failures provided there is
	technical solutions for a failover mechanism.		enough network connectivity.
	5.17. Scalability		5.17. Scalability
	Scalability is a key requirement for the P2MP LDP mechanism.		Scalability is a key requirement for the P2MP LDP mechanism.
	It MUST be designed to scale well with an increase in the number of		It MUST be designed to scale well with an increase in the number of
	any of the following:		any of the following:
	- number of Leaf LSRs per P2MP LSP		- number of Leaf LSRs per P2MP LSP;
	- number of Downstream LSRs per Branch LSR		- number of Downstream LSRs per Branch LSR;
	- number of P2MP LSPs per LSR		- 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 a 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.
	5.17.1. Orders of magnitude of the expected numbers of P2MP LSPs in		5.17.1. Orders of magnitude of the expected numbers of P2MP LSPs in
	operational networks		operational networks
	Typical orders of magnitude that we expect should be supported are:		Typical orders of magnitude that we expect should be supported are:
	- tens of thousands of P2MP trees spread out across core network		- tens of thousands of P2MP trees spread out across core network
	routers		routers;
	- hundreds, or a few thousands, of leaves per tree		- hundreds, or a few thousands, of leaves per tree;
	See also section 4.2 of [L3VPN-MCAST-REQ].		See also section 4.2 of [L3VPN-MCAST-REQ].
	5.18. Backward Compatibility		5.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 interoperate seamlessly with current		Also, the P2MP LDP solution MUST co-exist with current LDP mechanisms
	LDP mechanisms and inherit its capability sets from [LDP]. The P2MP		and inherit its capability sets from [LDP]. The P2MP LDP solution
	LDP solution MUST not impede the operation of P2P/MP2P LSPs. A P2MP		MUST not impede the operation of P2P/MP2P LSPs. A P2MP LDP solution
	LDP solution MUST be designed in such a way that it allows P2P/MP2P		MUST be designed in such a way that it allows P2P/MP2P and P2MP LSPs
	and P2MP LSPs to be signalled on the same interface.		to be signalled on the same interface.
	6. Shared Trees		6. Shared Trees
	For traffic delivery between a group of N Leaf LSRs which are acting		For traffic delivery between a group of N Leaf LSRs which are acting
	indifferently as Ingress or Egress LSRs, it may be useful to		indifferently as Ingress or Egress LSRs, it may be useful to
	setup a shared tree connecting all these LSRs, instead of having N		setup a shared tree connecting all these LSRs, instead of having N
	P2MP LSPs. This would reduce the amount of control and forwarding		P2MP LSPs. This would reduce the amount of control and forwarding
	state that has to be maintained on a given LSR.		state that has to be maintained on a given LSR.
	There are actually two main options for supporting such shared trees:		There are actually two main options for supporting such shared trees:
	- This could rely on the applications protocols that use LDP		- This could rely on the applications protocols that use LDP
	LSPs. A shared tree could consist of the combination of a		LSPs. A shared tree could consist of the combination of a
	MP2P LDP LSP from Leafs LSRs to a given root node, with a P2MP		MP2P LDP LSP from Leafs LSRs to a given root node, with a P2MP
	LSP from this root to all Leaf LSRs.		LSP from this root to all Leaf LSRs. For instance with
	For instance with Multicast L3 VPN applications, it would be		Multicast L3 VPN applications, it would be possible to build a
	possible to build a shared tree by combining:		shared tree by combining:
	- a MP2P unicast LDP LSP, from each PE of the group to a		- a MP2P unicast LDP LSP, from each PE of the group to a
	particular root PE acting as tree root,		particular root PE acting as tree root,
	- with a P2MP LDP LSP from the root PE to all PEs of the		- with a P2MP LDP LSP from this root PE to each PEs of the
	Group (see also [2547-MCAST]).		Group.
	- Or this could rely on a specific LDP mechanism allowing to		- Or this could rely on a specific LDP mechanism allowing to
	setup multipoint-to-multipoint MPLS LSPs (MP2MP LSPs).		setup 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) belong to the scope of this document.
	Requirements for the set up of MP2MP LSPs are listed below.		Requirements for the set up of MP2MP LSPs are listed below.
	6.1. MP2MP LSPs		6.1. Requirements for MP2MP LSPs
	*Editorial note: There is currently no clear analysis of the gain of		A MP2MP LSP is a LSP connecting a group of Leaf LSRs acting
	the MP2MP MPLS approach (with the potential impact on LDP), versus		indifferently as Ingress or Egress LSRs. Traffic sent by any Leaf
	using application-level shared trees. This is why the requirement for		LSRs is received by all other Leaf LSRs of the group.
	MP2MP LSPs is currently optional*
	The P2MP LDP mechanism MAY allow setting up MP2MP LSP. A MP2MP LSP is		Procedures for setting up MP2MP LSPs SHOULD be specified.
	a LSP connecting a group of Leaf LSRs acting indifferently as Ingress		An implementation that support P2MP LDP LSPs MAY also support MP2MP
	or Egress LSRs. Traffic sent by any Leaf LSRs is received by all		LDP LSP.
	other Leaf LSRs of the group. A sender LSR does not receive back the
	traffic sent.
	All detailed requirements for P2MP LSPs listed in section 5, apply		The MP2MP LDP procedures MUST not impede the operations of P2MP LSP.
	equally to MP2MP LSPs. Particularly it is RECOMMENDED that the size
	of MP2MP state on a LSR, for one particular MP2MP LSP, depend only on
	the number of adjacent LSRs on the LSP, and not on the number of Leaf
	LSRs.
	Additional detailed requirements specific to MP2MP LSPs are left for		Requirements for P2MP LSPs set forth in section 5 apply equally to
	further study.		MP2MP LSPs. Particular attention should be given on the below
			requirements:
			- The solution MUST support recovery upon link and transit node
			failure and there MUST be no single point of failure (provided
			network connectivity is redundant). Note that transit node
			failure recovery is likely to be more complex to handle with MP2MP
			LSPs than with P2MP LSPs;
			- The size of MP2MP state on a LSR, for one particular MP2MP LSP,
			SHOULD only depend on the number of adjacent LSRs on the LSP;
			- Furthermore, the MP2MP LDP mechanism MUST avoid routing loops that
			may trigger exponential growth of traffic. Note that this
			requirement is more challenging with MP2MP LSPs as a LSR can
			receive traffic for a given LSP on multiple interfaces.
			There are additional requirements specific to MP2MP LSPs:
			- It is RECOMMENDED that a MP2MP MPLS LSP follow shortest paths to a
			specific LSR called root LSR;
			- It is RECOMMENDED to define several root LSRs (e.g. a primary and
			a backup) to ensure redundancy upon root LSR failure;
			- The receiver SHOULD not receive back a packet it has sent on the
			MP2MP LSP;
			- The solution SHOULD avoid that all traffic between any pair of
			leaves is traversing a root LSR, and SHOULD as much as possible
			minimize the distance between two leaves (similarly to PIM-Bidir
			trees);
			- It MUST be possible to check connectivity of a MP2MP LSP in both
			directions.
	7. Evaluation criteria		7. Evaluation criteria
	7.1. Performances		7.1. Performances
	The solution will be evaluated with respect to the following		The solution will be evaluated with respect to the following
	criteria:		criteria:
	(1) Time to add or remove a Leaf LSR;		(1) Time to add or remove a Leaf LSR;
	(2) Time to repair a P2MP LSP in case of link or node		(2) Time to repair a P2MP LSP in case of link or node
	failure;		failure;
	(3) Scalability (state size, number of messages, message size).		(3) Scalability (state size, number of messages, message size).
	Particularly, the P2MP LDP mechanism SHOULD be designed so that		Particularly the P2MP LDP mechanism SHOULD be designed with as key
	convergence times in case of link or node failure are minimized, in		objective to minimize the additional amount of state and additional
	order to limit traffic disruption.		processing required in the network when deploying P2MP LDP.
			Also, the P2MP LDP mechanism SHOULD be designed so that convergence
			times in case of link or node failure are minimized, in order to
			limit traffic disruption.
	7.2. Complexity and Risks		7.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 P2MP LDP solution.		and diminish the benefits of deploying such P2MP LDP solution.
	The proposed solution SHOULD not require deploying a new routing
	protocol.
	8. Security Considerations		8. Security Considerations
	This document does not introduce any new security issue beyond those		This document does not introduce any new security issue beyond those
	inherent to LDP, and a P2MP LDP solution may rely on the security		inherent to LDP, and a P2MP LDP solution may rely on the security
	mechanisms defined in [LDP] (e.g. TCP MD5 Signature).		mechanisms defined in [LDP] (e.g. TCP MD5 Signature).
	9. Acknowledgments		9. Acknowledgments
	We would like to thank Christian Jacquenet (France Telecom),		We would like to thank Christian Jacquenet (France Telecom),
	Hitoshi Fukuda (NTT Communications), Ina Minei (Juniper), Dean		Hitoshi Fukuda (NTT Communications), Ina Minei (Juniper), Dean
	Cheng (Cisco Systems), and Benjamin Niven-Jenkins (British Telecom),		Cheng (Cisco Systems), and Benjamin Niven-Jenkins (British Telecom),
	for their highly useful comments and suggestions.		for their highly useful comments and suggestions.
	We would also like to thank authors of [P2MP-TE-REQ] from which some		We would also like to thank authors of [P2MP-TE-REQ] from which some
	text of this document has been inspired.		text of this document has been inspired.
	10. References		10. References
			10.1. Normative references
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
	3667, February 2004.
	[BCP79] Bradner, S., "Intellectual Property Rights in IETF
	Technology", RFC 3979, March 2005.
	[LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas,		[LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas,
	"LDP Specification", RFC 3036, January 2001		"LDP Specification", RFC 3036, January 2001
	[L3VPN-MCAST-REQ] T. Morin, Ed., "Requirements for Multicast in L3
	Provider-Provisioned VPNs", draft-ietf-l3vpn-ppvpn-mcast-reqts, work
	in progress.
	[L2VPN-MCAST-REQ] Y. Kamite et al. "Requirements for Multicast
	Support in Virtual Private LAN Services", draft-ietf-l2vpn-vpls-
	mcast-reqts, work in progress
	[P2MP-TE-REQ] S. Yasukawa, et. al., "Requirements for Point-to-
	Multipoint capability extension to MPLS", RFC4461, April 2006.
	[P2MP-TE-RSVP] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et. al..,
	"Extensions to RSVP-TE for Point to Multipoint TE LSPs", draft-ietf-
	mpls-rsvp-te-p2mp, work in progress.
	[LDP-MIB] J. Cuchiarra et al. "Definitions of Managed Objects for the		[LDP-MIB] J. Cuchiarra et al. "Definitions of Managed Objects for the
	Multiprotocol Label Switching (MPLS), Label Distribution Protocol		Multiprotocol Label Switching (MPLS), Label Distribution Protocol
	(LDP)", RFC3815, June 2004.		(LDP)", RFC3815, June 2004.
	[LDP-GR] M. Leelanivas, Y. Rekhter, R. Aggarwal, " Graceful Restart		[LDP-GR] M. Leelanivas, Y. Rekhter, R. Aggarwal, " Graceful Restart
	Mechanism for Label Distribution Protocol" RFC3478, February 2003.		Mechanism for Label Distribution Protocol" RFC3478, February 2003.
	[LDP-FT] A. Farrel, " Fault Tolerance for the Label Distribution		[LDP-FT] A. Farrel, " Fault Tolerance for the Label Distribution
	Protocol (LDP)", RFC3479, February 2003.		Protocol (LDP)", RFC3479, February 2003.
			10.2. Informative references
			[L3VPN-MCAST-REQ] T. Morin, Ed., "Requirements for Multicast in L3
			Provider-Provisioned VPNs", draft-ietf-l3vpn-ppvpn-mcast-reqts, work
			in progress.
			[L2VPN-MCAST-REQ] Y. Kamite et al. "Requirements for Multicast
			Support in Virtual Private LAN Services", draft-ietf-l2vpn-vpls-
			mcast-reqts, work in progress.
	[2547-MCAST] E. Rosen, R. Aggarwal, et. al., "Multicast in MPLS/BGP		[2547-MCAST] E. Rosen, R. Aggarwal, et. al., "Multicast in MPLS/BGP
	IP VPNs", draft-ietf-l3vpn-2547bis-mcast, work in progress.		IP VPNs", draft-ietf-l3vpn-2547bis-mcast, work in progress.
			[VPLS-MCAST] R.Aggarwal, Y Kamite, L Fang, “VPLS Multicast” draft-
			ietf-l2vpn-vpls-mcast, work in progress.
	[P2MP-OAM-REQ] S. Yasukawa, A. Farrel, D. King, T. Nadeau, "OAM		[P2MP-OAM-REQ] S. Yasukawa, A. Farrel, D. King, T. Nadeau, "OAM
	Requirements for Point-To-Multipoint MPLS Networks", draft-ietf-mpls-		Requirements for Point-To-Multipoint MPLS Networks", draft-ietf-mpls-
	p2mp-oam-reqs, work in progress.		p2mp-oam-reqs, work in progress.
	[VPLS-MCAST] R.Aggarwal, Y Kamite, L Fang, “VPLS Multicast” draft-		[P2MP-TE-REQ] S. Yasukawa, et. al., "Requirements for Point-to-
	ietf-l2vpn-vpls-mcast, work in progress.		Multipoint capability extension to MPLS", RFC4461, April 2006.
			[P2MP-TE-RSVP] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et. al..,
			"Extensions to RSVP-TE for Point to Multipoint TE LSPs", draft-ietf-
			mpls-rsvp-te-p2mp, work in progress.
	11. Editor Address		11. Editor Address
	Jean-Louis Le Roux		Jean-Louis Le Roux
	France Telecom		France Telecom
	2, avenue Pierre-Marzin		2, avenue Pierre-Marzin
	22307 Lannion Cedex		22307 Lannion Cedex
	FRANCE		FRANCE
	Email: jeanlouis.leroux@francetelecom.com		Email: jeanlouis.leroux@orange-ft.com
	12. Contributors Addresses		12. Contributors Addresses
	Thomas Morin		Thomas Morin
	France Telecom		France Telecom
	2, avenue Pierre-Marzin		2, avenue Pierre-Marzin
	22307 Lannion Cedex		22307 Lannion Cedex
	FRANCE		FRANCE
	Email: thomas.morin@francetelecom.com		Email: thomas.morin@orange-ft.com
	Vincent Parfait		Vincent Parfait
	EQUANT		EQUANT
	1041 Route des Dolines		1041 Route des Dolines
	Sophia Antipolis		Sophia Antipolis
	06560 Valbonne		06560 Valbonne
	FRANCE		FRANCE
	Email: vincent.parfait@equant.com		Email: vincent.parfait@orange-ft.com
	Luyuan Fang		Luyuan Fang
	AT&T		AT&T
	200 Laurel Avenue		200 Laurel Avenue
	Middletown, NJ 07748		Middletown, NJ 07748
	USA		USA
	Email: luyuanfang@att.com		Email: luyuanfang@att.com
	Lei Wang		Lei Wang
	Telenor		Telenor
End of changes. 46 change blocks.
	137 lines changed or deleted		167 lines changed or added
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/