[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: question about LDP restart...
This was discussed at the last IETF and we are revising drafts accordingly.
There three drafts on the table...
Had already passed WG last call
Fully scoped extensions to LDP for complete survivability
of the protocol over software and hardware failure/swapping.
Assumes that it is acceptable to 're-learn' control state
from neighboring nodes. In this it is considerably simpler
to implement, but may not be acceptable if rapid re-learning
of large numbers of LSPs is required, or if seamless survival
of traumatic events (such as software upload) is needed.
A light-weight approach to check-pointing state applicable
only to targeted LDP sessions where state transitions are
rare and can acceptably be lost. Particularly applicable to
At the last IETF it was decided that 1) and 3) had some common ground because
they both preserve state, but that 2) is distinct because it re-learns state.
Thus 1) and 3) will be merged and 2) will continue as distinct.
There will be one piece of overlap: the merged 1) and 3) will include a method
of identifying whether or not the procedures used in 2) are supported.
The merging work has been done and is currently being reviewed prior to
----- Original Message -----
From: "Zhi-Wei Lin" <firstname.lastname@example.org>
To: "ccamp" <email@example.com>
Sent: Friday, February 22, 2002 9:33 AM
Subject: question about LDP restart...
> Hi all,
> I was just browsing some files, and came across two similar WG documents
> covering what I think are very similar areas:
> draft-ietf-mpls-ldp-restart-00.txt (published Jan '02)
> draft-ietf-mpls-ldp-ft-02.txt (published Oct '01)
> My question is: since the ldp-ft already provides a solution, is
> referenced in GMPLS CR-LDP as the way to go, what was the reason for
> making the ldp-restart also a WG document?
> Thanks for any clarification...