draft-ietf-mpls-ldp-end-of-lib-01.txt		draft-ietf-mpls-ldp-end-of-lib-02.txt
	MPLS Working Group Rajiv Asati		MPLS Working Group Rajiv Asati
	Internet Draft Cisco Systems		Internet Draft Cisco Systems
	Intended status: Standards Track		Intended status: Standards Track
	Expires: March 2009 Pradosh Mohapatra		Expires: June 2009 Pradosh Mohapatra
	Cisco Systems		Cisco Systems
	Bob Thomas		Bob Thomas
	Emily Chen		Emily Chen
	Huawei Technologies		Huawei Technologies
	September 15, 2008		December 29, 2008
	LDP End-of-LIB		LDP End-of-LIB
	draft-ietf-mpls-ldp-end-of-lib-01.txt		draft-ietf-mpls-ldp-end-of-lib-02.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that		By submitting this Internet-Draft, each author represents that
	any applicable patent or other IPR claims of which he or she is		any 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		aware have been or will be disclosed, and any of which he or she
	becomes aware will be disclosed, in accordance with Section 6 of		becomes aware will be disclosed, in accordance with Section 6 of
	BCP 79.		BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	skipping to change at page 1, line 42		skipping to change at page 1, line 42
	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		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 March 15, 2007.		This Internet-Draft will expire on June 29, 2009.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	There are situations following Label Distribution Protocol (LDP)		There are situations following Label Distribution Protocol (LDP)
	session establishment where it would be useful for an LDP speaker to		session establishment where it would be useful for an LDP speaker to
	know when its peer has advertised all of its labels. The LDP		know when its peer has advertised all of its labels. The LDP
	skipping to change at page 2, line 23		skipping to change at page 2, line 23
	completion of its initial label advertisements following session		completion of its initial label advertisements following session
	establishment.		establishment.
	Table of Contents		Table of Contents
	1. Introduction...................................................2		1. Introduction...................................................2
	2. Specification Language.........................................3		2. Specification Language.........................................3
	3. Unrecognized Notification Capability...........................3		3. Unrecognized Notification Capability...........................3
	4. Signaling Completion of Label Advertisement....................4		4. Signaling Completion of Label Advertisement....................4
	5. Usage Guidelines...............................................5		5. Usage Guidelines...............................................5
	5.1. IGP-Sync..................................................5		5.1. LDP-IGP Sync..............................................5
	5.2. LDP Graceful Restart......................................6		5.2. LDP Graceful Restart......................................6
	5.3. Wildcard Label Request....................................7		5.3. Wildcard Label Request....................................7
	5.4. Missing Expected End-of-LIB Notifications.................7		5.4. Missing Expected End-of-LIB Notifications.................7
	6. Security Considerations........................................7		6. Security Considerations........................................7
	7. IANA Considerations............................................7		7. IANA Considerations............................................7
	8. Acknowledgments................................................8		8. Acknowledgments................................................8
	9. References.....................................................9		9. References.....................................................9
	9.1. Normative References......................................9		9.1. Normative References......................................9
	9.2. Informative References....................................9		9.2. Informative References....................................9
	Author's Addresses...............................................10		Author's Addresses...............................................10
	skipping to change at page 4, line 39		skipping to change at page 4, line 39
	An LDP speaker MAY signal completion of its label advertisements to a		An LDP speaker MAY signal completion of its label advertisements to a
	peer by means of a Notification message, if its peer had advertised		peer by means of a Notification message, if its peer had advertised
	the Unrecognized Notification capability during session		the Unrecognized Notification capability during session
	establishment. The LDP speaker MAY send the Notification message (per		establishment. The LDP speaker MAY send the Notification message (per
	FEC Type) to a peer even if the LDP speaker had zero Label bindings		FEC Type) to a peer even if the LDP speaker had zero Label bindings
	to advertise to that peer.		to advertise to that peer.
	Such a Notification message MUST carry:		Such a Notification message MUST carry:
	- A status TLV with TLV E- and F-bits set to zero that carries an		- A status TLV (with TLV E- and F-bits set to zero) that carries
	"End-of-LIB" Status Code.		an "End-of-LIB" Status Code (value to be assigned by IANA).
	- A FEC TLV with the Typed Wildcard FEC Element [TypedWC] that		- A FEC TLV with the Typed Wildcard FEC Element [TypedWC] that
	identifies the FEC type for which initial label advertisements		identifies the FEC type for which initial label advertisements
	have been completed. In terms of Section 3.5.1 of RFC5036,		have been completed. In terms of Section 3.5.1 of RFC5036,
	this TLV is an "Optional Parameter" of the Notification		this TLV is an "Optional Parameter" of the Notification
	message.		message.
	An LDP speaker MUST NOT send a Notification which carries a Status		An LDP speaker MUST NOT send a Notification which carries a Status
	TLV with the End-of-LIB Status Code to a peer unless the peer had		TLV with the End-of-LIB Status Code to a peer unless the peer had
	advertised the Unrecognized Notification capability during session		advertised the Unrecognized Notification capability during session
	skipping to change at page 7, line 37		skipping to change at page 7, line 37
	To deal with the possibility of missing notifications, an LDP speaker		To deal with the possibility of missing notifications, an LDP speaker
	may time out receipt of an expected End-of-LIB Notification, and if		may time out receipt of an expected End-of-LIB Notification, and if
	the timeout occurs, it may behave as if it had received the		the timeout occurs, it may behave as if it had received the
	notification. If the End-of-LIB Notification message is received		notification. If the End-of-LIB Notification message is received
	after the time-out occurs, then the message should be ignored.		after the time-out occurs, then the message should be ignored.
	6. Security Considerations		6. Security Considerations
	No security considerations beyond those that apply to the base LDP		No security considerations beyond those that apply to the base LDP
	specification and described in [RFC5036] apply to signaling the End-		specification [RFC5036] and further described in [MPLSsec] apply to
	of-LIB condition as described in this document.		signaling the End-of-LIB condition as described in this document.
	7. IANA Considerations		7. IANA Considerations
	This draft introduces a new LDP Status Code and a new LDP Capability		This draft introduces a new LDP Status Code and a new LDP Capability
	both of which require IANA assignment.		both of which require IANA assignment -
			The 'End-of-LIB' status code requires a code point from the Status
			Code Name Space. [RFC5036] partitions the Status Code Name Space
			into 3 regions: IETF Consensus region, First Come First Served
			region, and Private Use region. The authors recommend that a code
			point from the IETF Consensus range be assigned to the 'End-of-
			LIB' status code.
			The 'Unrecognized Notification' Capability requires a code point
			from the TLV Type name space. [RFC5036] partitions the TLV TYPE
			name space into 3 regions: IETF Consensus region, First Come
			First Served region, and Private Use region. The authors
			recommend that a code point from the IETF Consensus range be
			assigned to the 'Unrecognized Notification' Capability.
	8. Acknowledgments		8. Acknowledgments
	The authors would like to thank Ina Minei, Alia Atlas, Yakov Rekhter,		The authors would like to thank Ina Minei, Alia Atlas, Yakov Rekhter,
	Loa Andersson and Luyuan Fang for their valuable feedback and		Loa Andersson and Luyuan Fang for their valuable feedback and
	contribution.		contribution.
			The authors would like to recognize Kamran Raza, who helped to
			formulate this draft.
	This document was prepared using 2-Word-v2.0.template.dot.		This document was prepared using 2-Word-v2.0.template.dot.
	9. References		9. References
	9.1. Normative References		9.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.
	[RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and		[RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and
	skipping to change at page 10, line 5		skipping to change at page 9, line 33
	9.2. Informative References		9.2. Informative References
	[LDPSync] Jork, M., Atlas, A., Fang, L., "LDP IGP Synchronization",		[LDPSync] Jork, M., Atlas, A., Fang, L., "LDP IGP Synchronization",
	draft-ietf-mpls-ldp-igp-sync-02, Work in Progress, June		draft-ietf-mpls-ldp-igp-sync-02, Work in Progress, June
	2008.		2008.
	[RFC3478] Leelanivas, M., Rekhter, Y., Aggarwal, R., "Graceful		[RFC3478] Leelanivas, M., Rekhter, Y., Aggarwal, R., "Graceful
	Restart Mechanism for Label Distribution Protocol",		Restart Mechanism for Label Distribution Protocol",
	February 2003.		February 2003.
			[MPLSsec] Fang, L., "Security Framework for MPLS and GMPLS Networks",
			draft-ietf-mpls-mpls-and-gmpls-security-framework-04, Work
			in Progress, Nov 2008.
	Author's Addresses		Author's Addresses
	Rajiv Asati		Rajiv Asati
	Cisco Systems,		Cisco Systems,
	7025-6 Kit Creek Rd, RTP, NC, 27709-4987		7025-6 Kit Creek Rd, RTP, NC, 27709-4987
	Email: rajiva@cisco.com		Email: rajiva@cisco.com
	Pradosh Mohapatra		Pradosh Mohapatra
	Cisco Systems,		Cisco Systems,
	3750 Cisco Way, San Jose, CA, 95134		3750 Cisco Way, San Jose, CA, 95134
End of changes. 10 change blocks.
	10 lines changed or deleted		30 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/