The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Mar> msg00262



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

LDP-FT Question

  • From: afarrel@movaz.com
  • Date: Thu, 22 Mar 2001 04:51:29 -0500
  • Cc: mpls@UU.NET, eric.gray@sandburst.com, pjb@dataconnection.com, philipma@nortelnetworks.com

Bora,
Thanks for your interest in the draft.

Your thinking is, I believe, that on recovery of a TCP connection and
re-establishment of the LSP session, the peers are able to establish the
instance of the session from which they have preserved state.

However, since the session runs between the two peers and no-one else is
involved, it will always be the case that both peers have the same
understanding of the last successful session instance.  Further, maintained
state refers to the long-term conceptual session between the peers, not to
individual instances.

The following race illustrates your concern...
A talks to B
connection fails
connection re-established
A announces preserved state
B announces lost state, but connection fails before A hears this
connection re-established
A announces preserved state (*)
B announces preserved state (i.e. nothing to preserve since last time) (+)
Now A believes that the state is preserved, when it has actually been lost.

However, the Initialization messages at (*) and (+) carry the sequence
numbers of the most recently received and processed messages.  A will
receive 0 and will know that no message it sent has been preserved.  B will
receive some non-zero number and will immediately report a sequence number
error since it believes it has issued no messages.  The session will be
reset.

Does this answer your worries?

Regards,
Adrian
--
Adrian Farrel
Movaz Networks Inc
afarrel@movaz.com


> -----Original Message-----
> From: Bora Akyol [mailto:akyol@pluris.com]
> Sent: Wednesday, March 21, 2001 6:53 PM
> To: af@dataconnection.com
> Cc: mpls@UU.NET
> Subject: LDP-FT Question
> 
> 
> Adrian
> 
> I would like to suggest that the draft use a sequence number in place 
> of the FT_ Reconnect_Flag. A sequence number that is updated every 
> time FT data is changed and agreed upon by both sides (FT-pair) will 
> offer better protection than a single flag especially if both router 
> reboot within a time window.
> 
> What do you think?
> 
> Bora
>