Subject: Fail Over extensions for L2TP: comments welcome

From: "Vipin Jain" <[email-masked]>
Date: Sun, 25 Nov 2001 21:40:44 -0800

New draft available for your valuable comments:

Authors: Vipin Jain, Reinaldo Penno, Keyur Parikh, Ly Loi, 
Leo Huber and Mark Townsley

Title: Fail over extensions for L2TP

Abstract

L2TP is a connection-oriented protocol that has shared state between 
active endpoints. Some of this shared state is vital for 
operation but 
may be rather volatile in nature, such as packet sequence 
numbers used 
on the L2TP Control Connection. When failure of one side of a control
connection occurs, a new control connection is created and associated 
with the old connection by exchanging information about the old 
connection. Such a mechanism is not intended as a replacement for an 
active fail over with some mirrored connection states, but as an aid 
just for those parameters that are particularly difficult to have 
immediately available. Protocol extensions to L2TP defined in this 
document are intended to facilitate state recovery, providing 
additional resiliency in an L2TP network and improving a remote 
system's layer 2 connectivity.

---

From: "Jitender Arora" <[email-masked]>
Date: Mon, 26 Nov 2001 08:30:47 -0800

Hello ,
 
           I have one doubt in this draft :
 
1.        Why do we need a new value tunnel ID in the Assigned Tunnel ID AVP
in the SCCRQ upon Failover .In the draft it is mentioned that use of the 
           new tunnel id will avoid  "acknowledging some control messages by
peer that were meant for
           previous tunnel". Do we use the SCCRQ for acknowledging any of
the control messagges , which i could not find .
           Because if we  use the new tunnel id's in the CDN message for all
the unacknowledged CDN's , we will have to 
           keep the mapping between the old tunnel id's and the new tunnel
id's , which we could have avoided by using the 
           same tunnel id's , which were used earlier for the tunnels . Also
once we do all this things , we will have to free these tunnel id's  so that

           these can be used for the new tunnels .
 
           So my suggestion is can we use the same tunnel id's instead of
having the new tunnel id's .
 
Rgds,
Jitender .

 From: Jain, Vipin [SC9:0000:EXCH] 
Sent: Monday, November 26, 2001 12:41 AM
To: [email-masked]'
Subject: Fail Over extensions for L2TP: comments welcome

Abstract

---

From: "Vipin Jain" <[email-masked]>
Date: Mon, 26 Nov 2001 09:05:44 -0800

Jitender,

Thanks for the comments.
The use of new tunnel ID eliminates any interference, which can accidentally
ack a packet in new tunnel, with traffic that arrives at an endpoint after
failover. Consider:

Non failed node            Failed Node
SCCRQ (uses old tid) --->  Ns=0
ICRP <---- (Ns = x, Nr = 1) Now arrives an old packet that was in the
network.

New SCCRQ doesn't ack any packet, it only establishes a new tunnel upon
failover.
The assumption is that an endpoint keeps track of sessions and their states,
not the control messages themselves, which would mean a new CDN would have
to be constructed for a CDN over a new tunnel which would be interpreted
correctly by the peer.

thanks,
-- vipin

-----Original Message-----
From: Arora, Jitender [LIZD:5A03:EXCH] 
Sent: Monday, November 26, 2001 8:31 AM
To: Jain, Vipin [SC9:0000:EXCH]; [email-masked]'
Subject: RE: Fail Over extensions for L2TP: comments welcome

Hello ,

Rgds,
Jitender .

---

From: "Vipin Jain" <[email-masked]>
Date: Mon, 26 Nov 2001 09:16:40 -0800

Forgot to attach the new version.. which should be available at ietf website
soon.
 
thanks,
-- vipin

-----Original Message-----
From: Jain, Vipin [SC9:0000:EXCH] 
Sent: Sunday, November 25, 2001 9:41 PM
To: [email-masked]'
Subject: Fail Over extensions for L2TP: comments welcome

Abstract

---

From: "Jitender Arora" <[email-masked]>
Date: Mon, 26 Nov 2001 10:52:03 -0800

Hello ,

          But i don't think the example u have given will create any problem
as after sending the SCCRQ , we know that we have to wait for the SCCRP .
Till that time we should not handle any other control message .Once the
tunnel is up again , only then we should start catering to the other control
messages .Even if the other side had sent some message , it will wait for
the ack to come ,and on the failed node we won't be able to ack the messages
and we will be sending the SCCRQ so as to establish the tunnel again . once
the tunnle is up , both the nodes have to see what they were doing before
the failover and start all over again ( the examples u have given at the end
of the document , provides a good overview of that ) .

           So i am still not sure whether we need the new tunnel id's or not
....

Rgds,
Jitender .

-----Original Message-----
From: Jain, Vipin [SC9:0000:EXCH] 
Sent: Monday, November 26, 2001 12:06 PM
To: Arora, Jitender [LIZD:5A03:EXCH]; [email-masked]'
Subject: RE: Fail Over extensions for L2TP: comments welcome

Jitender,

Thanks for the comments.

thanks,
-- vipin

-----Original Message-----
From: Arora, Jitender [LIZD:5A03:EXCH] 
Sent: Monday, November 26, 2001 8:31 AM
To: Jain, Vipin [SC9:0000:EXCH]; [email-masked]'
Subject: RE: Fail Over extensions for L2TP: comments welcome

Hello ,

Rgds,
Jitender .

---

From: "Vipin Jain" <[email-masked]>
Date: Mon, 26 Nov 2001 12:06:38 -0800

Regarding examples: I think you are referring to the old version of the
draft, I am attaching the new version, which I sent to the list a while ago.
The new version also uses the new tunnel id for the new tunnel. More
comments inline..

>           But i don't think the example u have given will 
> create any problem as after sending the SCCRQ , we know that 
> we have to wait for the SCCRP . Till that time we should not 
> handle any other control message .
If I take the same situation:
Non failed node            Failed Node
SCCRQ (uses old tid) --->  Ns=0
ICRP <---- (Ns = x, Nr = 1) Now arrives an old packet that 
was in the network.
SCCRP <-------- (Ns = x, Nr = 1) Sent by Failed node will always be
discarded

This SCCRP would be discarded as duplicate if it has Ns=x, this would mean a
new tunnel would never be established if old tunnel id is used?

Using new-tunnel-id doesn't entirely eliminate the interference, but then it
would not be any worse than what would be there otherwise.

thanks,
-- vipin

---

From: "Jitender Arora" <[email-masked]>
Date: Mon, 26 Nov 2001 13:40:02 -0800

Hello ,

        I still have some doubts :

1.   I think the SCCRQ message will be sent by the failed node always ( in
case of failover this is my understanding ) , and it has to wait for the
SCCRP ( from the Peer Node ) . So once the Failed Node has sent the SCCRQ
message and is waiting for the SCCRP message , it can always ignore all
other Control Messages coming for the old tunnel id . And once the Peer node
sends the SCCRP message it has to be with ( Ns=0 , Nr=1), if this is not
correct then we can always ignore this .So i don't see any problem with
using the same old tunnel id's  , as we can always ignore the rest of the
messages except SCCRP that too with the proper Ns,and Nr. 

     This might need a new state in the link ( sessions) state machine
.Because we will have to take care that the other messages(other then SCCRP,
Ns=0,Nr=1) having the old tunnel id, have to be dropped at the Reliable
transport Layer itself .  

     The advantage of using the old tunnel id's is that we don't have to
keep the mapping between the old and the new tunnel id's , if we have to
establish the sessions with in this tunnel again . Also we don't have to
keep track of the tunnel id's which are in use ( till the corrospnding new
tunnels are not established , with all the sessions ) .

Rgds,
Jitender .

-----Original Message-----
From: Jain, Vipin [SC9:0000:EXCH] 
Sent: Monday, November 26, 2001 3:07 PM
To: Arora, Jitender [LIZD:5A03:EXCH]; [email-masked]'
Subject: RE: Fail Over extensions for L2TP: comments welcome

thanks,
-- vipin

---

From: "Vipin Jain" <[email-masked]>
Date: Mon, 26 Nov 2001 14:43:09 -0800

thanks for the comments, my comments inline..

> 1.   I think the SCCRQ message will be sent by the failed 
> node always ( in case of failover this is my understanding ) 
> , and it has to wait for the SCCRP ( from the Peer Node ) . 
you are right, failed node always initiate SCCRQ. I wanted
to emphasize the sequence number mess-up.. another example below:

> So once the Failed Node has sent the SCCRQ message and is 
> waiting for the SCCRP message , it can always ignore all 
> other Control Messages coming for the old tunnel id .
Usually the reliable layer in l2tp acts independently of
the messaging and control plane. If we were to do that we
would have to interpret messages before we take sequence
numbers into account.

> And > once the Peer node sends the SCCRP message it has to be with 
> ( Ns=0 , Nr=1), if this is not correct then we can always 
> ignore this .So i don't see any problem with using the same 
> old tunnel id's  , as we can always ignore the rest of the 
What if it is a ZLB? For example:
Failed node               Non Failed Node
SCCRQ (uses old tid) --->  Ns=0, Nr=0
ZLB <---- (Ns = x, Nr = 1) Now arrives an old packet ZLB
should this be ignored as well? Because it could be a genuine
one, on other hand it might ack something that has not been
received.. more special processing for ZLB then..
SCCRP <-------- (Ns = x, Nr = 1) Sent by Failed node 

>      This might need a new state in the link ( sessions) 
> state machine .Because we will have to take care that the 
> other messages(other then SCCRP, Ns=0,Nr=1) having the old 
> tunnel id, have to be dropped at the Reliable transport Layer 
> itself .  
True.

>      The advantage of using the old tunnel id's is that we 
> don't have to keep the mapping between the old and the new 
> tunnel id's , if we have to establish the sessions with in 
> this tunnel again . Also we don't have to keep track of the 
> tunnel id's which are in use ( till the corrospnding new 
When a new tunnel id is used, the old one can be trashed, why one has to
keep mapping between old and new one? All old buffered packets are
discarded, all sessions that were in transient states are considered dead.
Only the tunnel id is changed.

thanks,
-- vipin

---

From: "Jitender Arora" <[email-masked]>
Date: Mon, 26 Nov 2001 15:12:15 -0800

Hello ,

     My comments are following :

1. As far as i understand we can ignore the ZLB message as well for the old
tunnel .Because for us the Tunnel is being started again , so we should not
bother for the ZLB message also at this point  .
2. Yes we will have to interpret the messages at the REliable transport
layer itself ( that is the only disadvantage ) .
3. We need to keep the mapping between the old and the new Id's as if we
have to send the SCCN for the old tunnels , we won't be able to send unless
we make the new tunnels ( with the new tunnel id's as proposed by u ) , and
if we send the 
SCCN for the new tunnels we need to know the mapping between the old tunnel
id's and the new tunnel id's .Also i was thinking that we can save the
transient sessions as well , because we can store the states for the
sessions also . Only then 
my suggestion becomes more valid .

Rgds,
Jitender .

-----Original Message-----
From: Jain, Vipin [SC9:0000:EXCH] 
Sent: Monday, November 26, 2001 5:43 PM
To: Arora, Jitender [LIZD:5A03:EXCH]; [email-masked]'
Subject: RE: Fail Over extensions for L2TP: comments welcome

True.

thanks,
-- vipin

---

From: "Jitender Arora" <[email-masked]>
Date: Mon, 26 Nov 2001 15:39:54 -0800

ALso we need to keep the mapping and the track of the old tunnel id's till
all the old tunnels are established again with the new tunnel id's . As if
we start using the old tunnel id's again for new tunnels it can lead to the
scenario where any message meant for the old tunnel comes , and since we are
using this tunnel id for a new tunnel we won't be able to distinguish .

Rgds,
Jitender . 
-----Original Message-----
From: Arora, Jitender [LIZD:5A03:EXCH] 
Sent: Monday, November 26, 2001 6:12 PM
To: Jain, Vipin [SC9:0000:EXCH]; [email-masked]'
Subject: RE: Fail Over extensions for L2TP: comments welcome

Hello ,

   
Rgds,
Jitender .

-----Original Message-----
From: Jain, Vipin [SC9:0000:EXCH] 
Sent: Monday, November 26, 2001 5:43 PM
To: Arora, Jitender [LIZD:5A03:EXCH]; [email-masked]'
Subject: RE: Fail Over extensions for L2TP: comments welcome

True.

thanks,
-- vipin

---

From: "Vipin Jain" <[email-masked]>
Date: Mon, 26 Nov 2001 16:07:51 -0800

comments inline..

> 1. As far as i understand we can ignore the ZLB message as 
> well for the old tunnel .Because for us the Tunnel is being 
> started again , so we should not bother for the ZLB message 
> also at this point  .
agree, ZLB could be safely ignored.. but that is a special case
that one has to identify to ignore ZLB, which otherwise would
not be.

> 2. Yes we will have to interpret the messages at the REliable 
> transport layer itself ( that is the only disadvantage ) .

> 3. We need to keep the mapping between the old and the new 
> Id's as if we have to send the SCCN for the old tunnels , we 
> won't be able to send unless we make the new tunnels ( with 
> the new tunnel id's as proposed by u ) , and if we send the 
> SCCN for the new tunnels we need to know the mapping between 
> the old tunnel id's and the new tunnel id's .Also i was 
> thinking that we can save the transient sessions as well , 
> because we can store the states for the sessions also . Only then 
Old tunnels that were in transient state are not restored, they
would have to be dropped. So, why bother about SCCCN?
I think you meant ICCN? ICCNs for old sessions would use
the new tunnel ids, why do you have to know the old tunnel?
On receive side, a session that belonged to an old tunnel would
automatically have a corresponding new session in the new tunnel.
Why does it have to remember one to one correspondence?

thanks,
-- vipin

---

From: "Vipin Jain" <[email-masked]>
Date: Mon, 26 Nov 2001 18:14:18 -0800

thanks for your comments, my comments inline..

> ALso we need to keep the mapping and the track of the old 
> tunnel id's till all the old tunnels are established again 
> with the new tunnel id's . As if we start using the old 
> tunnel id's again for new tunnels it can lead to the scenario 
> where any message meant for the old tunnel comes , and since 
> we are using this tunnel id for a new tunnel we won't be able 
> to distinguish .

If an endpoint uses tunnel ids circularly, it doesn't increase
any further chances, though I agree rfc 2661 recommends
using a random value for tunnel id generation.
If an endpoint uses a random value for next available
tunnel-id, it depends: The tunnel ids are unique per host
(IP Address perhaps), the likelihood of assigning same tunnel
id to the same peer might be lesser. Should an implementation
choose to use system-wide unique Tunnel Ids (i.e. no overlap
among different peers) an implementation could then use its
recently used list to eliminate collisions, as you suggested.

We must also keep in mind that this could happen even when fail over
process is not kicking in. For example, without fail over protocol
when an endpoint fails it would establish new tunnels to the
peer, it might observe interference with old
messages in the network and the similar issues we are discussing now.

thanks,
-- vipin

---

From: Ignacio Goyret <[email-masked]>
Date: Mon, 26 Nov 2001 19:23:38 -0800

At 06:14 PM 11/26/01 -0800, Vipin Jain wrote: 
>when an endpoint fails it would establish new tunnels to the peer,
>it might observe interference with old messages in the network and
>the similar issues we are discussing now. 

...which is the reason for the 'random id allocation' suggestion in
the RFC. If you allocate tunnel ids from a small set of numbers, your
chances of reusing the same number increase and with that, the chances
increase that you may accept an stale packet incorrectly.

This is basically the same situation as in TCP with its ISS.