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/