The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

Aditya,

    I will attempt to answer your questions.

You wrote:

 

Hello Philip,
 Thanks for your mail.
I recieved a reply from Adrian(enclosed below)......but I asked him a
further question based on his answer(also enclosed below)...regarding which I am yet to hear
from him. It would really help if you could shed some light on the matter !!!!

The question I had asked Adrian was:-- "Could you explain what you
exactly mean by "state and information related to the previous incarnation of the session "

Previous incarnation relates to fact that the proposal
is intended to provide a means to preserve state over
loss of TCP connectivity.  Incarnation may not be the
best word to capture the notion that the previous (now
dead) TCP connection is now represented by a new
TCP connection that is intended to continue the same
session.

 

In section 3.4 of your draft you say that
"If either LDP peer sets the FT Reconnect Flag to 0, or omits the FT
   Session TLV, both LDP peers MUST release any state information and
   resources associated with the previous instantiation of the LDP
   session between the same LDP peers, including FT label state and
   Addresses"

Could you please tell me as to what specifically constitutes the "state information and resources" ??

Assigned labels and LSP related resources - i.e. queuing
related resources associated with an LSP associated
with an LDP peer session.

 

Secondly in Section 4.2 of your draft you write
   "When an LDP Peer receives a message containing the FT Protection TLV,
   it MUST take steps to secure this message (or the state information
   derived from processing the message).  Once the message is secured,
   it MUST be ACKed.  However, there is no requirement on the LSR to
   send this ACK immediately."

What do you exactly mean by the term "SECURED".....obviously it does not mean "PROCESS" the message ?
So what does "secure this message" mean ????

The precise meaning of secured is implementation specific.
An example would be to have stored pertinent information
relating to a transaction in progress in non-volatile memory.

 

Looking forward to your reply.
Thanks in Advance,
Aditya
 

Dear Adrian,
 Thanks for your reply.Could you kindly explain what you
exactly mean by "state and information related to the previous incarnation of the session "

In section 3.4 of your draft you say that
"If either LDP peer sets the FT Reconnect Flag to 0, or omits the FT
   Session TLV, both LDP peers MUST release any state information and
   resources associated with the previous instantiation of the LDP
   session between the same LDP peers, including FT label state and
   Addresses"

I broadly understand what you mean by  "state information and resources "..but could you
give me the specifics as to what constitutes the "state information and resources" .
Sorry for bothering you with the gory details...but I guess it is better to be safe rather than sorry
Thanks for your help
warm regards,
Aditya
 
 

>>Hi again Aditya,
>>Fair question.
>>It's your choice whether you re-use the same session control block, but you should throw out state and information related >>to the previous incarnation of the session and only populate the new/re-used control block with information about the re-

>>established session.
>>OK?
>>Regards,
>>Adrian
 

-----Original Message-----
From: Philip Matthews [mailto:philipma@nortelnetworks.com]
Sent: Tuesday, March 20, 2001 9:23 AM
To: Aditya Chugh (Leela)
Subject: Re: If we recieve FT reconnect Flag = 0...can we use same
session ??

I saw this posted to the MPLS-OPS list run by the MPLS Resource Center....

If you have questions on our Fault Tolerance draft, it would be best to
send them directly to the authors. Some of us are a little behind in our
reading of various mailing lists ...

And don't send them to MPLS-OPS list, which is for operational questions,
but to the MPLS WG list instead (mpls@uu.net).

Anyway, nice to see someone else implementing the draft.

- Philip

PS. Did Adrian every reply to your question??

"Aditya Chugh (Leela)" wrote:
>
> Dear Adrian,
> I need to bother you again...!!!!!!
>
> If our FT-LDP implementation is to conform to your draft " draft-ietf-mpls-ldp-ft-00.txt "...then how should the following be handled ????

>
> Consider the case when the TCP connection (of an FT session)  needs to be reestablished.
> Before the Reconnection Timer Expires
> if I recieve an Initialization message( with valid Session TLV)..
> ....but FT reconnect flag set to 0( which means that peer has not preserved state info for previous instantiations of this LDP session )

>
> I am supposed to release all the label state and resources associated with the previous instantiation of the LDP session.

>
> this would mean that I release the Labels and the Control Blocks ( since Labels are stored in the Control Blocks).
>
> But do I need to tear down the session also ??...that is do I also need to
> release the Session Block ...or I can use the same session block to establish a "Brand New" FT session.??
>
> Thanks in advance,
> Aditya