Subject: LDP Fault Tolerance

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 2 Mar 2002 09:20:11 -0500

At the December IETF there were three proposals on the table to address the issues in LDP and CR-LDP when there is a temporary interruption to the control plane from which we want to recover without tearing all of the LSPs the were set up using that part of the control plane.

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
   to targeted LDP sessions where state transitions are rare 
   and can acceptably be lost.  Particularly applicable to
   VPNs.
   This proposal could also be applied to facilitate graceful
   shutdown before maintenance events.

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 authors of 1) and 3) have been working hard to agree a merged draft, 
but have unfortunately missed the deadline for draft submission for the 
March IETF.  Some issues still remain concerning how tightly to 
integrate the two drafts.

We hope to reach agreement in the next few weeks and believe discussions
will proceed more smoothly without the immediate pressure of a deadline.

I'd particularly like to thank Jack Shaio and Paul Brittain for the time
they have given to trying to find a resolution.

Anyone wishing to know more about the likely direction of the draft and
the issues that we are struggling with should contact Jack, Paul or me.

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 6 Mar 2002 11:19:48 -0500

All,

The co-chairs have asked me to summarize the state of the work for merging the LDP fault tolerance drafts so that the WG can contribute and give direction to the merging process.

For more background see my mail to the list of 3/2/02, and the drafts draft-ietf-mpls-ldp-ft-02.txt, draft-ietf-mpls-ldp-restart-00.txt and draft-smith-ldp-restart-00.txt

This is my take on the state as editor. The other authors will, no doubt, jump in if they feel I have misrepresented how things stand.

Integration with draft-ietf-mpls-ldp-restart-00.txt

  The intention is that a single TLV will allow configuration
  and selection of LDP FT options.  This TLV will be defined
  in draft-ietf-mpls-ldp-ft-03 with bits to select which 
  options are supported/required.  Other configuration fields
  will be added to the TLV but the semantics for 
  draft-ietf-mpls-ldp-restart will remain internal to that 
  draft only.

  A first stab has been made at this integration and, after
  discussions, we believe we know what changes need to be
  made to make this workable.

Integration with draft-smith-ldp-restart-00.txt

  The initial plan was to put the function of this draft into
  draft-ietf-mpls-ldp-ft-03 more or less as an appendix and
  use a negotiation bit during session establishment to 
  determine whether the function was in use.  There was 
  concern, however, that since the functions were so 
  similar they should be more closely integrated.

  A good proposal was made and agreed on that used the
  sequence number/ack method of draft-ietf-mpls-ldp-ft-02
  applied to the Keepalive message to achieve the
  checkpointing required by draft-smith-ldp-restart-00.txt

  There was some debate about the *purpose* of the 
  function in draft-smith-ldp-restart-00.txt.  I believe we
  now have a form of words that indicates that the primary
  purpose is as a periodic state checkpointing process
  that serves to reduce the processing of acknowledgements
  and which can force a remote node to acknowledge up-to-
  date.  The function also makes possible graceful shutdown
  (useful before maintenance outages such as software 
  upgrade).

  One issue remains and is blocking progress on integration.

  - One camp believes that it is possible to apply the 
    merged draft-smith-ldp-restart-00.txt function to LDP
    exchanges without requiring any changes to those 
    messages.  In particular, that it should not be a 
    requirement to place sequence numbers on LDP messages
    to make the checkpoint function work.  To include
    sequence numbers is unnecessary and burdensome to the
    implementation.

  - The other camp agrees that it is not necessary to 
    include sequence numbers on all LDP messages to make 
    the checkpoint function work, but believes that not
    using them 
    - impacts interoperability with FT implementations that
      support the full draft
    - provides yet another protocol option for negotiation
    - reduces flexibility in having some labels protected 
      and others not
    - forces implicit sequence numbering on an 
      implementation.

  There would, on the face of it, appear to be little or no
  difference in the processing of individual messages that
  would be required for the two approaches.

This is where we are stuck.  Should we include sequence numbers on all messages or not?

Happy to answer all questions (except those of a personal nature :-)

Adrian

---

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 6 Mar 2002 08:51:20 -0800

[clipped]

Adrian,
>   made to make this workable.

To clarify, the purpose of the above is to enable the use of procedures in 
draft-ietf-mpls-ldp-restart for someone implementing 
draft-ietf-mpls-ldp-ft-02.txt, right ? Hence maybe we can use a term other
than 'integration' to describe it. 

thanks,
rahul

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 6 Mar 2002 12:05:11 -0500

> than 'integration' to describe it.

Rahul,
No, that wasn't the purpose.  There would be no need to implement
draft-ietf-mpls-ldp-restart if draft-ietf-mpls-ldp-ft was implemented because
all of the state would already be in place.

There _might_ be some value in supporting both processes if a subset of labels
were to be maintained over restart and another set re-learned.  However, this
seems to be stretching things a bit.

The main benefit of draft-ietf-mpls-ldp-restart is that it allows recovery by
nodes that do not have FT capabilities (dual processors, flash RAM, hard disks,
card-punches and readers).  The main assumption of draft-ietf-mpls-ldp-ft is
that the systems involved _do_ have these capabilities.

Note that a node may support both procedures, but that a session would not.

The intention of the "integration" work is to provide a common
configuration/selection method for FT processes.

Adrian

---

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 6 Mar 2002 09:16:39 -0800

> card-punches and readers).  The main assumption of draft-ietf-mpls-ldp-ft is

Just as a note we have most of these FT capabilities in our system, but 
still went with draft-ietf-mpls-ldp-restart. But that is a different
discussion :)

> configuration/selection method for FT processes.

Ok. It wasn't entirely clear from reading the note.