Subject: RE: Last Call on LDP Fault Tolerance

From: Jack Shaio <[email-masked]>
Date: Tue, 10 Apr 2001 13:09:39 -0700

hi Adrian,

I had one comment regarding the LDP fault tolerance draft.

This draft makes fault tolerance (ft) a property of an individual label
rather than a property of the LDP session and requires special care for
all LDP messages that affect ft labels.

However, these procedures simplify if instead all the labels in an
ft LDP session were fault tolerant. One can have 2 parallel LDP sessions
if needed to allow for a mix of fault tolerant and non-fault tolerant
labels to an LDP peer.

If all labels of an ft session are fault tolerant, then you can keep the
FT Protection, FT Ack and FT sequence numbers as in the draft, but each
LDP peer sends both TLV's in LDP KeepAlives. An FT Ack means that the
FT Protection TLV with that FT sequence has been saved by the LDP peer,
and because of the underlying TCP transport, also all earlier LDP
messages.

In case the TCP session is lost, as in a card failure, the ft LDP session
only needs to preserve all the LDP messages sent since the last acked
FT Protection TLV, and replay them when reconnected (when the FT session
reconnect flag is set).

This simply makes the TCP failure transparent and exchanges all LDP
messages that would have been sent had that session not been lost, without
modifying the message processing for LDP or CR-LDP.

Changes in topology or label withdraws are handled after the replay
is complete, much as if, for example, they had occured while waiting
for TCP to retransmit after a lost frame.

--jack

---

From: Eric W Gray <[email-masked]>
Date: Tue, 10 Apr 2001 16:35:12 -0400

Jack,

    This was the way that one of the original drafts was
written to work, so this was looked at, believe it or not.

    Unfortunately, it is not as simple as having either a FT
session or a non-FT session (as opposed to FT labels).
Fault Tolerance is a property of (at least a segment of)
LSPs, rather than (typically) the LSR peers involved in
establishing a single link of these LSPs (or LSP segments).
As you point out, having parallel sessions could address
this, but there are complexities attendant on using this
approach as well.

    Very early on in the process, we opted for one set of
complexities over the other.  I believe this is a reasonable
design choice.

--
Eric Gray

---

From: "Philip Matthews" <[email-masked]>
Date: Wed, 11 Apr 2001 22:12:53 -0400

Jack:

My original FT proposal
   draft-matthews-mpls-ldp-ibb-00.txt
required all labels to be fault-tolerant.
As you state, the procedures were indeed a bit simpler.

But when we produced a combined draft, my co-authors wanted the ability
to make some labels FT and other not FT. They argued that some LSPs would
be more important than other LSPs, and people might want to protect only
the important LSPs. Hence the procedures in the draft today.

I do _not_ think we should go back and revisit this decision now.
It would reset the entire effort back to square one, and I think
it is way too late for this now.

- Philip