draft-ietf-mpls-ldp-applicability-label-adv-01.txt		draft-ietf-mpls-ldp-applicability-label-adv-02.txt
	MPLS Working Group Kamran Raza		MPLS Working Group Kamran Raza
	Internet Draft Sami Boutros		Internet Draft Sami Boutros
	Updates: 5036, 4447 (if approved) Luca Martini		Updates: 5036, 4447, 5918, 6388, 3212 Luca Martini
	Intended status: Standards Track Cisco Systems, Inc.		Intended status: Standards Track Cisco Systems, Inc.
	Expires: August 14, 2013		Expires: July 19, 2014
	Nicolai Leymann		Nicolai Leymann
	Deutsche Telekom		Deutsche Telekom
	February 15, 2013		January 20, 2014
	Applicability of LDP Label Advertisement Mode		Label Advertisement Discipline for LDP FECs
	draft-ietf-mpls-ldp-applicability-label-adv-01.txt		draft-ietf-mpls-ldp-applicability-label-adv-02.txt
	Abstract		Abstract
	An LDP speaker negotiates the label advertisement mode with its LDP		The label advertising behavior of an LDP speaker for a given FEC is
	peer at the time of session establishment. Although different		governed by the FEC type and not necessarily by the LDP session's
	applications sharing the same LDP session may need different modes		negotiated label advertisement mode. This document updates RFC 5036
	of label distribution and advertisement, there is only one type of		to make that fact clear, as well as updates RFC 3212, RFC 4447,
	label advertisement mode that is negotiated and used per LDP		RFC 5918, and RFC 6388 by specifying the label advertisement mode
	session. This document clarifies the use and the applicability of		for all currently defined FECs.
	session's negotiated label advertisement mode, and categorizes LDP
	applications into two broad categories of negotiated mode-bound and
	mode-independent applications. The document updates RFC5036 and
	RFC4447 to remove any ambiguity and conflict in the area of using
	correct label advertisement mode for a given application.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted 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), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 2, line 4		skipping to change at page 1, line 42
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as		at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress."		reference material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	This Internet-Draft will expire on August 14, 2013.		This Internet-Draft will expire on July 19, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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		carefully, as they describe your rights and restrictions with
	respect to this document. Code Components extracted from this		respect to this document. Code Components extracted from this
	document must include Simplified BSD License text as described in		document must include Simplified BSD License text as described in
	Section 4.e of the Trust Legal Provisions and are provided without		Section 4.e of the Trust Legal Provisions and are provided without
	warranty as described in the Simplified BSD License.		warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction 3		1. Introduction 2
	2. Conventions used in this document 3		2. Label Advertisement Discipline 3
	3. Label Advertisement Mode Applicability 4		2.1. Update to RFC-5036 3
	3.1. Label Advertisement Mode Negotiation 4		2.2. Specification for LDP FECs 4
	3.2. Mode-based Categorization of LDP Applications 4		3. Security Considerations 4
	3.2.1. Session mode-bound Applications 5		4. IANA Considerations 4
	3.2.2. Session mode-independent Applications 5		5. References 5
	3.3. Unacceptable label advertisement mode 6		5.1. Normative References 5
	4. Clarification on Mode Applicability 6		5.2. Informative References 5
	4.1. Update to RFC-5036 7		6. Acknowledgments 5
	4.2. Update to RFC-4447 7
	5. Security Considerations 7
	6. IANA Considerations 7
	7. References 7
	7.1. Normative References 7
	7.2. Informative References 8
	8. Acknowledgments 8
	1. Introduction		1. Introduction
	The MPLS architecture [RFC3031] defines two modes of label		Label Distribution Protocol (LDP) [RFC5036] allows label
	advertisement for an LSR:		advertisement mode negotiation at the time of session establishment.
			LDP specification also dictates that only single label advertisement
	1. Downstream-on-Demand		mode is negotiated, agreed and used for a given LDP session between
			two LSRs.
	2. Unsolicited Downstream
	The "Downstream-on-Demand" mode requires an LSR to explicitly
	request the label binding for FECs from its peer, whereas
	"Unsolicited Downstream" mode allows an LSR to distribute the label
	binding for FECs to LSR peers that have not explicitly requested
	them. The MPLS architecture also specifies that on any given label
	distribution adjacency, the upstream LSR and the downstream LSR must
	agree to use a single label advertisement mode.
	Label Distribution Protocol (LDP) [RFC5036] allows label
	advertisement mode negotiation at time of session establishment
	(section 3.5.3 [RFC5036]). To comply with MPLS architecture, LDP
	specification also dictates that only single label advertisement
	mode is agreed and used for a given LDP session between two LSRs.
	With the advent of new LDP applications, such as L2VPN [RFC4447],
	mLDP [RFC6388], ICCP [ICCP], there are situations when an LDP
	session is shared across more than one application to exchange label
	bindings for different types of FEC. Although different applications
	sharing the same LDP session may need a different type of label
	advertisement mode negotiated, there is only one type of label
	advertisement mode that is negotiated and agreed at the time of
	establishment of LDP session.
	This document clarifies the use and the applicability of label
	advertisement mode of a session for each application using the
	session. It also categorizes LDP applications into two broad
	categories of mode-bound and mode-independent applications.
	The document also suggests an update to RFC-5036 and RFC-4447 to
	remove any ambiguity and conflict in the area of using correct label
	advertisement mode for a given LDP application.
	2. Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC-2119 [RFC2119].
	The unqualified term "mode" used in document refers to "label
	advertisement mode".
	Please also note that LDP specification [RFC5036] uses the term
	"Downstream Unsolicited" to refer to "Unsolicited Downstream". The
	LDP specification also uses the terms "label distribution mode" and
	"label advertisement mode" interchangeably. Like LDP specification
	document, this document also uses these terms interchangeably.
	3. Label Advertisement Mode Applicability
	3.1. Label Advertisement Mode Negotiation
	Label advertisement mode is negotiated between LSR peers at the time
	of session establishment. The label advertisement mode is specified
	in LDP Initialization message's "Common Session Parameter" TLV by
	setting A-bit (Label Advertisement Discipline bit) to 1 or 0 for
	Downstream-on-Demand or Downstream-Unsolicited modes respectively.
	The negotiation of the A-bit is specified in section 3.5.3 of
	[RFC5036] as follows:
	"If one LSR proposes Downstream Unsolicited and the other proposes
	Downstream on Demand, the rules for resolving this difference is:
	- If the session is for a label-controlled ATM link or a
	label- controlled Frame Relay link, then Downstream on Demand
	MUST be used.
	- Otherwise, Downstream Unsolicited MUST be used."
	Once label advertisement mode has been negotiated and agreed, both
	LSR peers must use the same mode for label binding exchange.
	3.2. Mode-based Categorization of LDP Applications
	The earlier applications, defined and identified at the time of
	standardization of LDP base specification RFC-3036, using LDP to
	exchange their FEC bindings were:
	. Dynamic Label Switching for IP Prefixes
	. Label-controlled ATM/FR
	Since then, several new applications have emerged that use LDP to
	signal their FEC bindings and/or application data. These include:
	. L2VPN P2P PW ([RFC4447])
	. L2VPN P2MP PW ([P2MP-PW])
	. mLDP ([RFC6388])
	. ICCP ([ICCP])
	We divide the LDP applications into two broad categories from label
	advertisement mode usage point of view:
	1. Session mode-bound Applications
	2. Session mode-independent Applications
	3.2.1. Session mode-bound Applications
	We define a "session mode-bound application" to be an application
	which uses the negotiated label advertisement mode. This means that
	the FEC-label binding exchange for such an LDP application MUST use
	the label advertisement mode negotiated for the LDP session.
	The early LDP applications "Dynamic Label Switching for IP Prefixes"
	and "Label-controlled ATM/FR" are included into this category.
	3.2.2. Session mode-independent Applications
	We define a "session mode-independent application" to be an
	application which does not care about the negotiated label
	advertisement mode. This means that the FEC-label binding, or any
	other application data, exchange for such an LDP application does
	not care about, nor tied to the "negotiated" label advertisement
	mode of the session; rather, the information exchange is driven by
	the application need and procedures as described by its
	specification document. For example, [RFC6388] specifies procedures
	to advertise P2MP FEC label binding in an unsolicited manner,
	irrespective of the negotiated label advertisement mode of the
	session.
	The applications, PW (P2P and P2MP), MLDP, and ICCP, are included
	into this category of LDP applications.
	3.2.2.1. Upstream Label Assignment
	As opposed to downstream assigned label advertisement defined by
	[RFC3031], [RFC6389] specification defines new mode of label
	advertisement where label advertisement and distribution occurs for
	upstream assigned labels.
	As stated earlier in this document, LDP base specification RFC-5036
	only allows specifying Downstream-Unsolicited or Downstream-on-Demand
	mode. This means that any LDP application that requires upstream
	assigned label advertisement also falls under the category of Session
	mode-independent application.
	3.3. Unacceptable label advertisement mode		The negotiated label advertisement mode defined in RFC 5036 and
			carried in the LDP Initialization message is only indicative. It
			indicates how the LDP speakers on a session will advertise labels for
			some FECs, but it is not a rule that restricts the speakers to behave
			in a specific way. Furthermore, for some FEC types the advertising
			behavior of the LDP speaker is governed by the FEC type and not by
			the negotiated behavior.
	The procedures related to unacceptable label advertisement mode, as		This document updates [RFC5036] to make that fact clear, and updates
	defined in RFC-5036 section 3.5.3, continue to apply for any "mode-		[RFC3212], [RFC4447], [RFC5036], [RFC5918], and [RFC6388] to indicate
	bound" FEC/application. For a "mode-independent" FEC/application,		for each FEC type that has already been defined whether the label
	mode negotiation does not apply and hence both LSRs MUST operate in		binding advertisements for the FEC are constrained by the negotiated
	the mode specified for the given application by the respective		label advertisement mode or not. Furthermore, this document specifies
	specification.		the label advertisement mode to be used for all currently defined
			LDP FECs.
	If a session is jointly shared amongst mode-bound and mode-		2. Label Advertisement Discipline
	independent FEC/applications, session will not be established if the
	label advertisement mode is unacceptable (between the LSRs) for a
	given mode-bound FEC/application type. This is inline with RFC-5036
	section 3.5.3 specification for unacceptable mode.
	4. Clarification on Mode Applicability		To remove any ambiguity and conflict regarding label advertisement
			discipline amongst different FEC types sharing a common LDP session,
			this document specifies a label advertisement disciplines for FEC
			types.
	To remove any ambiguity and conflict amongst different		This document introduces following types for specifying a label
	specifications with regards to the use of LDP session's label		advertisement discipline for a FEC type:
	advertisement mode, we propose an update to LDP base specification
	RFC-5036 to clarify the applicability of session's negotiated mode.
	Furthermore, RFC-4447 specifies LDP extensions and procedures to		- DU (Downstream Unsolicited)
	exchange label bindings for P2P PW FECs [RFC4447], and dictates the		- DoD (Downstream On Demand)
	use of Downstream-Unsolicited mode for an LDP session related to		- As negotiated (DU or DoD)
	L2VPN PW. This mode dictation creates a direct conflict in		- Upstream ([RFC6389])
	situations when a PW LDP session is shared with an LDP application		- Not Applicable
	with Downstream-on-Demand mode (such as Label switching Application
	for IP prefixes). To remove such a conflict, we also propose an
	update to a section of RFC-4447.
	4.1. Update to RFC-5036		2.1. Update to RFC-5036
	The section 3.5.3 of [RFC5036] is updated to add following two		The section 3.5.3 of [RFC5036] is updated to add following two
	statements under the description of "A, Label Advertisement		statements under the description of "A, Label Advertisement
	Discipline":		Discipline":
	- The negotiated label advertisement discipline only applies to FEC		- Each document defining an LDP FEC must state the applicability
	label binding advertisement of "Address Prefix" FECs;		of the negotiated label advertisement discipline for label
			binding advertisements for that FEC. If the negotiated label
			advertisement discipline does not apply to the FEC, the
			document must also explicitly state the discipline to be used
			for the FEC.
	- Any new document specifying a new FEC MUST state the		- This document defines the label advertisement discipline for
	applicability of the negotiated label advertisement discipline for		the following FEC types:
	that FEC.
	4.2. Update to RFC-4447		+----------+----------+--------------------------------+
			| FEC Type | FEC Name | Label advertisement discipline |
			+----------+----------+--------------------------------+
			| 0x01 | Wildcard | Not applicable |
			| 0x02 | Prefix | As negotiated (DU or DoD) |
			+----------+----------+--------------------------------+
	The section 3 of [RFC4447] states:		2.2. Specification for LDP FECs
	"LDP MUST be used in its downstream unsolicited mode."		Following is the specification of label advertisement disciplines to
			be used for currently defined LDP FEC types.
	Since PW application falls under session mode-independent		+------+----------------+--------------------------------+------+
	application category, the above statement in [RFC4447] should be		| FEC | FEC Name | Label advertisement discipline |RFC |
	read to mean as follows:		| Type | | | |
			+------+----------------+--------------------------------+------+
			| 0x01 | Wildcard | Not applicable | 5036 |
			| 0x02 | Prefix | As negotiated (DU or DoD) | 5036 |
			| 0x04 | CR-LSP | DoD | 3212 |
			| 0x05 | Typed Wildcard | Not applicable | 5918 |
			| 0x06 | P2MP | DU | 6388 |
			| 0x07 | MP2MP-up | DU | 6388 |
			| 0x08 | MP2MP-down | DU | 6388 |
			| 0x80 | PWid | DU | 4447 |
			| 0x81 | Gen. PWid | DU | 4447 |
			+------+----------------+--------------------------------+------+
	"LDP MUST exchange PW FEC label bindings in downstream unsolicited		The above table also lists the RFC (in which given FEC type is
	manner, independent of the negotiated label advertisement mode of		defined), and hence this document updates all the above listed RFCs.
	the LDP session".
	5. Security Considerations		3. Security Considerations
	This document specification only clarifies the applicability of LDP		This document specification only clarifies the applicability of LDP
	session's label advertisement mode, and hence does not add any LDP		session's label advertisement mode, and hence does not add any LDP
	security mechanics and considerations to those already defined in		security mechanics and considerations to those already defined in
	the LDP specification [RFC5036].		the LDP specification [RFC5036].
	6. IANA Considerations		4. IANA Considerations
	None.		This document mandates the specification of a label advertisement
			discipline for each defined FEC type, and hence extends IANA's
			"Forwarding Equivalence Class (FEC) Type Name Space" registry under
			IANA's "Label Distribution Protocol (LDP) Parameters" as follows:
	7. References		- Add a new column titled "Label advertisement discipline" with
			following possible values:
			o DU
			o DoD
			o As negotiated (DU or DoD)
			o Upstream
			o Not applicable
	7.1. Normative References		- For the existing FEC types, populate this column with the
			values listed under section 2.2.
			5. References
			5.1. Normative References
	[RFC5036] L. Andersson, I. Minei, and B. Thomas, "LDP		[RFC5036] L. Andersson, I. Minei, and B. Thomas, "LDP
	Specification", RFC 5036, September 2007.		Specification", RFC 5036, September 2007.
			[RFC3212] B. Jamoussi, et al., "Constraint-Based LSP Setup using
			LDP", RFC 3212, January 2002
	[RFC4447] L. Martini, Editor, E. Rosen, El-Aawar, T. Smith, G.		[RFC4447] L. Martini, Editor, E. Rosen, El-Aawar, T. Smith, G.
	Heron, "Pseudowire Setup and Maintenance using the Label		Heron, "Pseudowire Setup and Maintenance using the Label
	Distribution Protocol", RFC 4447, April 2006.		Distribution Protocol", RFC 4447, April 2006.
	[RFC3031] E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol		[RFC5918] R. Asati, I. Minei, and B. Thomas, "Label Distribution
	Label Switching Architecture", RFC 3031, January 2001.		Protocol Typed Wildcard FEC", RFC 5918, August 2010.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	7.2. Informative References
	[P2MP-PW] S. Boutros, L. Martini, S. Sivabalan, G. Del Vecchio,		[RFC6388] I. Minei, I. Wijnands, K. Kompella, and B. Thomas, "LDP
	Kamite, L. Jin, "Signaling Root-Initiated P2MP PWs using		Extensions for P2MP and MP2MP LSPs", RFC 6388, November
	LDP", draft-ietf-pwe3-p2mp-pw-04.txt, Work in Progress,		2011.
	March 2012.
	[RFC6388] I. Minei, I. Wijnand, K. Kompella, B., "LDP Extensions for		[RFC6389] R. Aggarwal, and JL. Le Roux, "MPLS Upstream Label
	P2MP and MP2MP LSPs", RFC 6388, November 2011.		Assignment for LDP", RFC 6389, November 2011.
	[ICCP] L. Martini, S. Salam, A. Sajassi, and S. Matsushima,		5.2. Informative References
	"Inter-Chassis Communication Protocol for L2VPN PE
	Redundancy", draft-ietf-pwe3-iccp-09.txt, Work in
	Progress, July 2012.
	[RFC6389] R. Aggarwal, and J.L. Le Roux, "MPLS Upstream Label		None.
	Assignment for LDP", RFC 6389, November 2011.
	8. Acknowledgments		6. Acknowledgments
	We acknowledge the authors of [RFC5036] and [RFC4447] since some of		We acknowledge Eric Rosen and Rajiv Asati for their initial review
	the text in this document is borrowed from their specification. We		and input on the document.
	also acknowledge Eric Rosen and Rajiv Asati for their review and
	input.
	This document was prepared using 2-Word-v2.0.template.dot.		This document was prepared using 2-Word-v2.0.template.dot.
	Authors' Addresses		Authors' Addresses
	Kamran Raza		Kamran Raza
	Cisco Systems, Inc.		Cisco Systems, Inc.
	2000 Innovation Drive,		2000 Innovation Drive,
	Ottawa, ON K2K-3E8, Canada.		Ottawa, ON K2K-3E8, Canada.
	E-mail: skraza@cisco.com		E-mail: skraza@cisco.com
End of changes. 38 change blocks.
	248 lines changed or deleted		123 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/