Re: question about LDP restart...

["Adrian Farrel" <afarrel@movaz.com>]

This was discussed at the last IETF and we are revising drafts accordingly.
There three drafts on the table...

1) draft-ietf-mpls-ldp-ft-02.txt
   Had already passed WG last call
   Fully scoped extensions to LDP for complete survivability
   of the protocol over software and hardware failure/swapping.

2) draft-ietf-mpls-ldp-restart-00.txt
   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.

3) draft-smith-ldp-restart-00.txt
    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
    VPNs.

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
publication.

Regards,
Adrian

----- Original Message -----
From: "Zhi-Wei Lin" <zwlin@lucent.com>
To: "ccamp" <ccamp@ops.ietf.org>
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...
>
> Zhi
>
>