Subject: RE: What exactly constitutes the State info in FT-LDP and what do we mean by "Securing the message" ??

From: Aditya Chugh <[email-masked]>
Date: Mon, 26 Mar 2001 07:22:54 +0500

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 "

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" ??

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 ????

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:[email-masked]]
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 ([email-masked]).

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

---

From: Eric Gray <[email-masked]>
Date: Mon, 26 Mar 2001 11:34:42 -0500

Aditya,

    I will attempt to answer your questions.

You wrote:

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

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

> What do you exactly mean by the term "SECURED".....obviously it does
> not mean "PROCESS" the message ?

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.

> exactly mean by "state and information related to the previous
> incarnation of the session "
>
> 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
>
>
> 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.
> > 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).
> >

---

From: "Philip Matthews" <[email-masked]>
Date: Tue, 27 Mar 2001 17:39:30 -0500

Aditya:

Adrian beat me to the reply, but I agree with everything he said.
Does this answer your question?

- Philip

Aditya Chugh wrote:
> 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 !!!!
> 
> exactly mean by "state and information related to the previous incarnation of the session "
> 
> Could you please tell me as to what specifically constitutes the "state information and resources" ??
> 
> What do you exactly mean by the term "SECURED".....obviously it does not mean "PROCESS" the message ?
> exactly mean by "state and information related to the previous incarnation of the session "
> 
> 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
> 
> > 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.
> > ....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).
> >
> > release the Session Block ...or I can use the same session block to establish a "Brand New" FT session.??
> >
> > Thanks in advance,
> > Aditya