< draft-pelletier-mpls-ldp-bindings-refresh-01.txt		draft-pelletier-mpls-ldp-bindings-refresh-02.txt >
	MPLS Working Group Andre Pelletier		MPLS Working Group Andre Pelletier
	Internet Draft Kamran Raza		Internet Draft Kamran Raza
	Intended status: Standards Track		Intended status: Standards Track
	Expires: October 30, 2012 Cisco Systems, Inc.		Expires: August 24, 2013 Cisco Systems, Inc.
	May 1, 2012		February 25, 2013
	LDP Bindings Refresh		LDP Bindings Refresh
	draft-pelletier-mpls-ldp-bindings-refresh-01.txt		draft-pelletier-mpls-ldp-bindings-refresh-02.txt
	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. This document may not be modified,		provisions of BCP 78 and BCP 79. This document may not be modified,
	and derivative works of it may not be created, except to publish it		and derivative works of it may not be created, except to publish it
	as an RFC and to translate it into languages other than English.		as an RFC and to translate it into languages other than English.
	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
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 October 30, 2012.		This Internet-Draft will expire on August 24, 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.		respect to this document.
	Abstract		Abstract
	skipping to change at page 7, line 45 ¶		skipping to change at page 7, line 45 ¶
	successfully, an LDP speaker:		successfully, an LDP speaker:
	o MAY send a START marker prior to responding with the requested		o MAY send a START marker prior to responding with the requested
	bindings. Returning a START marker is OPTIONAL, as the requesting		bindings. Returning a START marker is OPTIONAL, as the requesting
	LSR is able to infer that the request itself is equivalent to a		LSR is able to infer that the request itself is equivalent to a
	START marker; all requested bindings will implicitly follow the		START marker; all requested bindings will implicitly follow the
	request event.		request event.
	o MUST signal completion of the response by sending an END marker.		o MUST signal completion of the response by sending an END marker.
	When sending an END marker in response to a Wildcard Request, the		When sending an END marker in response to a Wildcard Request, the
	END marker notification message MUST contain the "Message ID" TLV of		END marker notification message MUST contain the "Message ID" TLV
	the associated Wildcard request. This ensures that the receiver is		of the associated Wildcard request. This ensures that the receiver
	able to correlate the END marker back to the associated wildcard		is able to correlate the END marker back to the associated wildcard
	request, as opposed to some unrelated END sent as part of an		request, as opposed to some unrelated END sent as part of an
	unsolicited re-advertisement. This additional "Message ID" TLV is		unsolicited re-advertisement. This additional "Message ID" TLV is
	placed under the "Optional Parameters" section of an LDP		placed under the "Optional Parameters" section of an LDP
	Notification message. This specification, thus, also updates the		Notification message. This specification, thus, also updates the
	End-of-LIB notification format as originally defined in RFC5919.		End-of-LIB notification format as originally defined in RFC5919.
	The requesting LDP speaker MAY assume that any bindings that were		The requesting LDP speaker MAY assume that any bindings that were
	not returned between the request and the END marker containing the		not returned between the request and the END marker containing the
	associated message ID TLV response are stale, and may be purged.		associated message ID TLV response are stale, and may be purged.
	skipping to change at page 15, line 18 ¶		skipping to change at page 15, line 18 ¶
	0x00000032 0 Start-of-Addresses		0x00000032 0 Start-of-Addresses
	0x00000033 0 End-of-Addresses		0x00000033 0 End-of-Addresses
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and		[RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and
	Thomas, B., "LDP Specification", RFC 5036, January 2001.		Thomas, B., "LDP Specification", RFC 5036, January 2001.
	[RFC5919] R. Asati, P. Mohapatra, E. Chen, B. Thomas, "Signaling LDP		[RFC5919] R. Asati, P. Mohapatra, E. Chen, B. Thomas, "Signaling
	Label Advertisement Completion", RFC 5919, August 2010.		LDP Label Advertisement Completion", RFC 5919,
			August 2010.
	[RFC5918] Asati, R., Minei, I., and Thomas, B. "Label Distribution		[RFC5918] Asati, R., Minei, I., and Thomas, B. "Label Distribution
	Protocol Typed Wildcard FEC", RFC 5918, August 2010.		Protocol Typed Wildcard FEC", RFC 5918, August 2010.
	[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.
	[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.		[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and
	Le Roux, "LDP Capabilities", RFC 5561, July 2009.		JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009.
	8.2. Informative References		8.2. Informative References
	[RFC5920] Fang, L. et al., "Security Framework for MPLS and GMPLS		[RFC5920] Fang, L. et al., "Security Framework for MPLS and GMPLS
	Networks", RFC 5920, July 2010.		Networks", RFC 5920, July 2010.
	9. Acknowledgments		9. Acknowledgments
	The authors would like to acknowledge Eric Rosen for his review and		The authors would like to acknowledge Eric Rosen for his review and
	input on this specification.		input on this specification.
End of changes. 8 change blocks.
	12 lines changed or deleted		13 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/