draft-ietf-mpls-ldp-applicability-label-adv-00.txt		draft-ietf-mpls-ldp-applicability-label-adv-01.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 (if approved) Luca Martini
	Intended status: Standards Track Cisco Systems, Inc.		Intended status: Standards Track Cisco Systems, Inc.
	Expires: February 7, 2013		Expires: August 14, 2013
	Nicolai Leymann		Nicolai Leymann
	Deutsche Telekom		Deutsche Telekom
	August 8, 2012		February 15, 2013
	Applicability of LDP Label Advertisement Mode		Applicability of LDP Label Advertisement Mode
	draft-ietf-mpls-ldp-applicability-label-adv-00.txt		draft-ietf-mpls-ldp-applicability-label-adv-01.txt
	Abstract		Abstract
	An LDP speaker negotiates the label advertisement mode with its LDP		An LDP speaker negotiates the label advertisement mode with its LDP
	peer at the time of session establishment. Although different		peer at the time of session establishment. Although different
	applications sharing the same LDP session may need different modes		applications sharing the same LDP session may need different modes
	of label distribution and advertisement, there is only one type of		of label distribution and advertisement, there is only one type of
	label advertisement mode that is negotiated and used per LDP		label advertisement mode that is negotiated and used per LDP
	session. This document clarifies the use and the applicability of		session. This document clarifies the use and the applicability of
	session's negotiated label advertisement mode, and categorizes LDP		session's negotiated label advertisement mode, and categorizes LDP
	applications into two broad categories of negotiated mode-bound and		applications into two broad categories of negotiated mode-bound and
	mode-independent applications. The document also suggests an update		mode-independent applications. The document updates RFC5036 and
	to RFC 5036 and RFC 4447 to remove any ambiquity and conflict in the		RFC4447 to remove any ambiguity and conflict in the area of using
	area of using correct label advertisement mode for a given		correct label advertisement mode for a given application.
	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 7		skipping to change at page 2, line 7
	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 February 7, 2013.		This Internet-Draft will expire on August 14, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2013 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 3
	2. Conventions used in this document 3		2. Conventions used in this document 3
	3. Label Advertisement Mode Applicability 4		3. Label Advertisement Mode Applicability 4
	3.1. Label Advertisement Mode Negotiation 4		3.1. Label Advertisement Mode Negotiation 4
	3.2. Mode-based Categorization of LDP Applications 4		3.2. Mode-based Categorization of LDP Applications 4
	3.2.1. Session mode-bound Applications 5		3.2.1. Session mode-bound Applications 5
	3.2.2. Session mode-independent Applications 5		3.2.2. Session mode-independent Applications 5
	3.3. Unacceptable label advertisement mode 6		3.3. Unacceptable label advertisement mode 6
	4. Clarification on Mode Applicability 6		4. Clarification on Mode Applicability 6
	4.1. Update to RFC-5036 7		4.1. Update to RFC-5036 7
	4.2. Update to RFC-4447 7		4.2. Update to RFC-4447 7
	5. Security Considerations 7		5. Security Considerations 7
	6. IANA Considerations 7		6. IANA Considerations 7
	7. References 7		7. References 7
	7.1. Normative References 7		7.1. Normative References 7
	7.2. Informative References 8		7.2. Informative References 8
	8. Acknowledgments 8		8. Acknowledgments 8
	1. Introduction		1. Introduction
	The MPLS architecture [RFC3031] defines two modes of label		The MPLS architecture [RFC3031] defines two modes of label
	advertisement for an LSR:		advertisement for an LSR:
	1. Downstream-on-Demand		1. Downstream-on-Demand
	2. Unsolicited Downstream		2. Unsolicited Downstream
	skipping to change at page 5, line 21		skipping to change at page 5, line 21
	advertisement mode usage point of view:		advertisement mode usage point of view:
	1. Session mode-bound Applications		1. Session mode-bound Applications
	2. Session mode-independent Applications		2. Session mode-independent Applications
	3.2.1. Session mode-bound Applications		3.2.1. Session mode-bound Applications
	We define a "session mode-bound application" to be an application		We define a "session mode-bound application" to be an application
	which uses the negotiated label advertisement mode. This means that		which uses the negotiated label advertisement mode. This means that
	the FEC-label binding exchange for such an LDP applications MUST use		the FEC-label binding exchange for such an LDP application MUST use
	the label advertisement mode negotiated for the LDP session.		the label advertisement mode negotiated for the LDP session.
	The early LDP applications "Dynamic Label Switching for IP Prefixes"		The early LDP applications "Dynamic Label Switching for IP Prefixes"
	and "Label-controlled ATM/FR" are included into this category.		and "Label-controlled ATM/FR" are included into this category.
	3.2.2. Session mode-independent Applications		3.2.2. Session mode-independent Applications
	We define a "session mode-independent application" to be an		We define a "session mode-independent application" to be an
	application which does not care about the negotiated label		application which does not care about the negotiated label
	advertisement mode. This means that the FEC-label binding, or any		advertisement mode. This means that the FEC-label binding, or any
	skipping to change at page 7, line 22		skipping to change at page 7, line 22
	label binding advertisement of "Address Prefix" FECs;		label binding advertisement of "Address Prefix" FECs;
	- Any new document specifying a new FEC MUST state the		- Any new document specifying a new FEC MUST state the
	applicability of the negotiated label advertisement discipline for		applicability of the negotiated label advertisement discipline for
	that FEC.		that FEC.
	4.2. Update to RFC-4447		4.2. Update to RFC-4447
	The section 3 of [RFC4447] states:		The section 3 of [RFC4447] states:
	"LDP MUST be used in its downstream unsolicited mode."		"LDP MUST be used in its downstream unsolicited mode."
	Since PW application falls under session mode-independent		Since PW application falls under session mode-independent
	application category, the above statement in [RFC4447] should be		application category, the above statement in [RFC4447] should be
	read to mean as follows:		read to mean as follows:
	"LDP MUST exchange PW FEC label bindings in downstream unsolicited		"LDP MUST exchange PW FEC label bindings in downstream unsolicited
	manner, independent of the negotiated label advertisement mode of		manner, independent of the negotiated label advertisement mode of
	the LDP session".		the LDP session".
	5. Security Considerations		5. 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
	LDP specification [RFC5036].		the LDP specification [RFC5036].
	6. IANA Considerations		6. IANA Considerations
	None.		None.
	7. References		7. References
	7.1. Normative References		7.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.
	[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		[RFC3031] E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol
	Label Switching Architecture", RFC 3031, January 2001.		Label Switching Architecture", RFC 3031, January 2001.
	[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, RFC2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	7.2. Informative References		7.2. Informative References
	[P2MP-PW] S. Boutros, L. Martini, S. Sivabalan, G. Del Vecchio,		[P2MP-PW] S. Boutros, L. Martini, S. Sivabalan, G. Del Vecchio,
	Kamite, L. Jin, "Signaling Root-Initiated P2MP PWs using		Kamite, L. Jin, "Signaling Root-Initiated P2MP PWs using
	LDP", draft-ietf-pwe3-p2mp-pw-04.txt, Work in Progress,		LDP", draft-ietf-pwe3-p2mp-pw-04.txt, Work in Progress,
	March 2012.		March 2012.
	[RFC6388] I. Minei, I. Wijnand, K. Kompella, B., "LDP Extensions for		[RFC6388] I. Minei, I. Wijnand, K. Kompella, B., "LDP Extensions for
	P2MP and MP2MP LSPs", RFC 6388, November 2011.		P2MP and MP2MP LSPs", RFC 6388, November 2011.
	[ICCP] L. Martini, S. Salam, A. Sajassi, and S. Matsushima,		[ICCP] L. Martini, S. Salam, A. Sajassi, and S. Matsushima,
	"Inter-Chassis Communication Protocol for L2VPN PE		"Inter-Chassis Communication Protocol for L2VPN PE
	Redundancy", draft-ietf-pwe3-iccp-08.txt, Work in		Redundancy", draft-ietf-pwe3-iccp-09.txt, Work in
	Progress, June 2012.		Progress, July 2012.
	[RFC6389] R. Aggarwal, and J.L. Le Roux, "MPLS Upstream Label		[RFC6389] R. Aggarwal, and J.L. Le Roux, "MPLS Upstream Label
	Assignment for LDP", RFC 6389, November 2011.		Assignment for LDP", RFC 6389, November 2011.
	8. Acknowledgments		8. Acknowledgments
	We acknowledge the authors of [RFC5036] and [RFC4447] since some of		We acknowledge the authors of [RFC5036] and [RFC4447] since some of
	the text in this document is borrowed from their specification. We		the text in this document is borrowed from their specification. We
	also acknowledge Eric Rosen and Rajiv Asati for their review and		also acknowledge Eric Rosen and Rajiv Asati for their review and
	input.		input.
	skipping to change at page 9, line 17		skipping to change at page 9, line 17
	San Jose, CA 95134, USA.		San Jose, CA 95134, USA.
	E-mail: sboutros@cisco.com		E-mail: sboutros@cisco.com
	Luca Martini		Luca Martini
	Cisco Systems, Inc.		Cisco Systems, Inc.
	9155 East Nichols Avenue, Suite 400,		9155 East Nichols Avenue, Suite 400,
	Englewood, CO 80112, USA.		Englewood, CO 80112, USA.
	E-mail: lmartini@cisco.com		E-mail: lmartini@cisco.com
	Nicolai Leymann		Nicolai Leymann
	Deutsche Telekom,		Deutsche Telekom AG,
	Winterfeldtstrasse 21-27,		Winterfeldtstrasse 21,
	10781 Berlin, Germany.		Berlin 10781, Germany.
	E-mail: N.Leymann@telekom.de		E-mail: N.Leymann@telekom.de
End of changes. 13 change blocks.
	35 lines changed or deleted		34 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/