draft-ietf-mpls-ldp-restart-04.txt		draft-ietf-mpls-ldp-restart-05.txt
	Network Working Group Manoj Leelanivas (Juniper Networks)		Network Working Group Manoj Leelanivas (Juniper Networks)
	Internet Draft Yakov Rekhter(Juniper Networks)		Internet Draft Yakov Rekhter(Juniper Networks)
	Expiration Date: March 2003 Rahul Aggarwal (Redback Networks)		Expiration Date: March 2003 Rahul Aggarwal (Redback Networks)
	Graceful Restart Mechanism for LDP		Graceful Restart Mechanism for LDP
	draft-ietf-mpls-ldp-restart-04.txt		draft-ietf-mpls-ldp-restart-05.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026, except that the right to		all provisions of Section 10 of RFC2026, except that the right to
	produce derivative works is not granted.		produce derivative works is not granted.
	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 other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 4, line 12		skipping to change at page 4, line 12
	are capable of preserving the forwarding state across the restart of		are capable of preserving the forwarding state across the restart of
	their control plane and implement the mechanism described here.		their control plane and implement the mechanism described here.
	The mechanism makes minimalistic assumptions on what has to be		The mechanism makes minimalistic assumptions on what has to be
	preserved across restart - the mechanism assumes that only the actual		preserved across restart - the mechanism assumes that only the actual
	MPLS forwarding state has to be preserved. Clearly this is the		MPLS forwarding state has to be preserved. Clearly this is the
	minimum amount of state that has to be preserved across the restart		minimum amount of state that has to be preserved across the restart
	in order not to perturb the LSPs traversing a restarting LSR. The		in order not to perturb the LSPs traversing a restarting LSR. The
	mechanism does not require any of the LDP-related state to be		mechanism does not require any of the LDP-related state to be
	preserved across the restart.		preserved across the restart.
			In the scenario where label binding on an LSR is created/maintained
			not just by the LDP component of the control plane, but by other
			protocol components as well (e.g., BGP, RSVP-TE), and the LSR
			supports restart of the individual components of the control plane
			that create/maintain label binding (e.g., restart of LDP, but no
			restart of BGP), the LSR needs to preserve across the restart the
			information about which protocol has assigned which labels.
	The procedures described in this document apply to downstream		The procedures described in this document apply to downstream
	unsolicited label distribution. Extending these procedures to		unsolicited label distribution. Extending these procedures to
	downstream on demand label distribution is for further study.		downstream on demand label distribution is for further study.
	2. LDP Extension		2. LDP Extension
	An LSR indicates that it is capable of supporting LDP Graceful		An LSR indicates that it is capable of supporting LDP Graceful
	Restart, as defined in this document, by including the Fault Tolerant		Restart, as defined in this document, by including the Fault Tolerant
	(FT) Session TLV as an Optional Parameter in the LDP Initialization		(FT) Session TLV as an Optional Parameter in the LDP Initialization
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/