draft-ietf-mpls-mp-ldp-reqs-05.txt		draft-ietf-mpls-mp-ldp-reqs-06.txt
	MPLS J. Le Roux, Ed.		MPLS J. Le Roux, Ed.
	Internet-Draft T. Morin		Internet-Draft T. Morin
	Intended status: Informational V. Parfait		Intended status: Informational V. Parfait
	Expires: May 30, 2011 France Telecom - Orange		Expires: June 4, 2011 France Telecom - Orange
	L. Fang		L. Fang
	Cisco		Cisco
	L. Wang		L. Wang
	Telenor		Telenor
	Y. Kamite		Y. Kamite
	NTT		NTT
	S. Amante		S. Amante
	Level3		Level3
	November 26, 2010		December 01, 2010
	Requirements for Point-To-Multipoint Extensions to the Label		Requirements for Point-To-Multipoint Extensions to the Label
	Distribution Protocol		Distribution Protocol
	draft-ietf-mpls-mp-ldp-reqs-05		draft-ietf-mpls-mp-ldp-reqs-06
	Abstract		Abstract
	This document lists a set of functional requirements for Label		This document lists a set of functional requirements for Label
	Distribution Protocol (LDP) extensions for setting up point-to-		Distribution Protocol (LDP) extensions for setting up point-to-
	multipoint (P2MP) Label Switched Paths (LSP), in order to deliver		multipoint (P2MP) Label Switched Paths (LSP), in order to deliver
	point-to-multipoint applications over a Multi Protocol Label		point-to-multipoint applications over a Multi Protocol Label
	Switching (MPLS) infrastructure. It is intended that solutions that		Switching (MPLS) infrastructure. It is intended that solutions that
	specify LDP procedures for setting up P2MP LSP satisfy these		specify LDP procedures for setting up P2MP LSP satisfy these
	requirements.		requirements.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on June 4, 2011.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on May 30, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the BSD License.		described in the Simplified BSD License.
			This document may contain material from IETF Documents or IETF
			Contributions published or made publicly available before November
			10, 2008. The person(s) controlling the copyright in some of this
			material may not have granted the IETF Trust the right to allow
			modifications of such material outside the IETF Standards Process.
			Without obtaining an adequate license from the person(s) controlling
			the copyright in such materials, this document may not be modified
			outside the IETF Standards Process, and derivative works of it may
			not be created outside the IETF Standards Process, except to format
			it for publication as an RFC or to translate it into languages other
			than English.
	Table of Contents		Table of Contents
	1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Problem Statement and Requirements Overview . . . . . . . . . 6		3. Problem Statement and Requirements Overview . . . . . . . . . 6
	3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 6		3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 6
	3.2. Requirements overview . . . . . . . . . . . . . . . . . . 7		3.2. Requirements overview . . . . . . . . . . . . . . . . . . 7
	skipping to change at page 10, line 17		skipping to change at page 10, line 17
	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, 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.
	5.5. Label Advertisement		5.5. Label Advertisement
	The P2MP LDP mechanism MUST support downstream unsolicited label		The P2MP LDP mechanism MUST 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.
	skipping to change at page 10, line 48		skipping to change at page 10, line 48
	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 6.8).		rerouting is being performed (See also section 6.8).
	5.7. Detecting and Avoiding Loops		5.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, that may trigger unexpected non-localized exponential
	growth of traffic.		growth of traffic.
	5.8. P2MP LSP Re-routing		5.8. P2MP LSP Re-routing
	skipping to change at page 14, line 21		skipping to change at page 14, line 21
	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 co-exist with current LDP mechanisms		Also, the P2MP LDP solution MUST co-exist 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 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 setup a		indifferently as Ingress or Egress LSRs, it may be useful to setup a
	shared tree connecting all these LSRs, instead of having N P2MP LSPs.		shared tree connecting all these LSRs, instead of having N P2MP LSPs.
	This would reduce the amount of control and forwarding state that has		This would reduce the amount of control and forwarding state that has
	to be maintained on a given LSR.		to be maintained on a given LSR.
	skipping to change at page 15, line 17		skipping to change at page 15, line 17
	6.1. Requirements for MP2MP LSPs		6.1. Requirements for MP2MP LSPs
	A MP2MP LSP is a LSP connecting a group of Leaf LSRs acting		A MP2MP LSP is a LSP connecting a group of Leaf LSRs acting
	indifferently as Ingress or Egress LSRs. Traffic sent by any Leaf		indifferently as Ingress or Egress LSRs. Traffic sent by any Leaf
	LSR is received by all other Leaf LSRs of the group.		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 support P2MP LDP LSPs MAY also support MP2MP
	LDP LSP.		LDP LSP.
	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 6, apply equally to		Requirements for P2MP LSPs, set forth in section 6, apply equally to
	MP2MP LSPs. Particular attention should be given on the below		MP2MP LSPs. Particular attention should be given on the below
	requirements:		requirements:
	o The solution MUST support recovery upon link and transit node		o The solution MUST support recovery upon link and transit node
	failure and there MUST NOT be any single point of failure		failure and there MUST NOT be any single point of failure
	(provided network connectivity is redundant);		(provided network connectivity is redundant);
	o The size of MP2MP state on a LSR, for one particular MP2MP LSP,		o The size of MP2MP state on a LSR, for one particular MP2MP LSP,
	skipping to change at page 15, line 43		skipping to change at page 15, line 43
	receive traffic for a given LSP on multiple interfaces.		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 follow shortest paths to a		o It is RECOMMENDED that a MP2MP MPLS LSP follow shortest paths to a
	specific LSR called root LSR;		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, and SHOULD as much as possible		leaves is traversing a root LSR, and SHOULD as much as possible
	minimize the distance between two leaves (similarly to PIM-Bidir		minimize the distance between two leaves (similarly to PIM-Bidir
	trees);		trees);
	o It MUST be possible to check connectivity of a MP2MP LSP in both		o It MUST be possible to check connectivity of a MP2MP LSP in both
	directions.		directions.
	skipping to change at page 16, line 31		skipping to change at page 16, line 31
	Particularly the P2MP LDP mechanism SHOULD be designed with as key		Particularly the P2MP LDP mechanism SHOULD be designed with as key
	objective to minimize the additional amount of state and additional		objective to minimize 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.
	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 solution.		and diminish the benefits of deploying such solution.
	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 will rely on the security		inherent to LDP, and a P2MP LDP solution will rely on the security
	mechanisms defined in [RFC5036] (e.g. TCP MD5 Signature).		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
End of changes. 13 change blocks.
	21 lines changed or deleted		27 lines changed or added
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/