draft-ietf-mpls-ldp-restart-00.txt   draft-ietf-mpls-ldp-restart-01.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: July 2002 Rahul Aggarwal (Redback Networks) Expiration Date: October 2002 Rahul Aggarwal (Redback Networks)
Graceful Restart Mechanism for LDP Graceful Restart Mechanism for LDP
draft-ietf-mpls-ldp-restart-00.txt draft-ietf-mpls-ldp-restart-01.txt
1. Status of this Memo 1. 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 5 skipping to change at page 4, line 5
sender could exchange LDP messages with its neighbors. sender could exchange LDP messages with its neighbors.
For a restarting LSR the Recovery Time carries the time (in For a restarting LSR the Recovery Time carries the time (in
milliseconds) the LSR is willing to retain its MPLS forwarding state milliseconds) the LSR is willing to retain its MPLS forwarding state
that it preserved across the restart. The time is from the moment the that it preserved across the restart. The time is from the moment the
LSR sends the Initialization message that carries the Graceful LSR sends the Initialization message that carries the Graceful
Restart TLV after restart. Setting this time to 0 indicates that the Restart TLV after restart. Setting this time to 0 indicates that the
MPLS forwarding state wasn't preserved across the restart (or even if MPLS forwarding state wasn't preserved across the restart (or even if
it was preserved, is no longer available). it was preserved, is no longer available).
For an (non restarting) LSR that re-established an LDP adjacency with
a neighbor, this is the time (in milliseconds) that the LSR is
willing to retain the label-FEC bindings that have been received from
the neighbor prior to neighbor's restart. The time is from the moment
the LSR sends the Initialization message that carries the Graceful
Restart TLV.
The Recovery Time should be long enough to allow the neighboring The Recovery Time should be long enough to allow the neighboring
LSR's to re-sync all the LSP's in a graceful manner, without creating LSR's to re-sync all the LSP's in a graceful manner, without creating
congestion in the LDP control plane. congestion in the LDP control plane.
6. Operations 6. Operations
For the sake of brevity in the context of this document by "the For the sake of brevity in the context of this document by "the
control plane" we mean "the LDP component of the control plane". control plane" we mean "the LDP component of the control plane".
An LSR that supports functionality described in this document should An LSR that supports functionality described in this document should
skipping to change at page 8, line 34 skipping to change at page 8, line 24
should be configurable. should be configurable.
If the LSR re-establishes an LDP session with the neighbor within the If the LSR re-establishes an LDP session with the neighbor within the
lesser of the Restart Time and the local timer, and the LSR lesser of the Restart Time and the local timer, and the LSR
determines that the neighbor was not able to preserve its MPLS determines that the neighbor was not able to preserve its MPLS
forwarding state, the LSR should immediately delete all the stale forwarding state, the LSR should immediately delete all the stale
label-FEC bindings received from that neighbor. If the LSR determines label-FEC bindings received from that neighbor. If the LSR determines
that the neighbor was able to preserve its MPLS forwarding state (as that the neighbor was able to preserve its MPLS forwarding state (as
was indicated by the non-zero Recovery Time advertised by the was indicated by the non-zero Recovery Time advertised by the
neighbor), the LSR should further keep the stale label-FEC bindings neighbor), the LSR should further keep the stale label-FEC bindings
received from the neighbor for as long as the Recovery Time that the received from the neighbor for as long as the lesser of the Recovery
LSR advertises to the neighbor (after that, the bindings still marked Time, advertised by the neighbor, and a local configurable value.
as stale should be deleted). The Recovery Time that the LSR
advertises to the neighbor should be greater than the Recovery Time
the (restarting) neighbor advertised to the LSR.
The LSR should try to complete the exchange of its label mapping The LSR should try to complete the exchange of its label mapping
information with the neighbor within the Recovery Time, as specified information with the neighbor within the Recovery Time, as specified
in the Graceful Restart TLV received from the neighbor. in the Graceful Restart TLV received from the neighbor.
The LSR should handle the Label Mapping messages received from the The LSR should handle the Label Mapping messages received from the
neighbor by following the normal LDP procedures, except that (a) it neighbor by following the normal LDP procedures, except that (a) it
should treat the stale entries in its Label Information Base (LIB), should treat the stale entries in its Label Information Base (LIB),
as if these entries have been received over the (newly established) as if these entries have been received over the (newly established)
session, (b) if the label-FEC binding carried in the message is the session, (b) if the label-FEC binding carried in the message is the
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/