Subject: RE: Few questions on L2TP..

From: Keyur Parikh <[email-masked]>
Date: Wed, 7 Mar 2001 08:34:35 -0500

-----Original Message-----
From: W. Mark Townsley [mailto:[email-masked]]
Sent: Tuesday, March 06, 2001 8:22 PM
To: Keyur Parikh
Cc: Andy Koscinski; [email-masked]
Subject: Re: Few questions on L2TP..

> Just a thought: How about ensuring that your hot standby router has full
> state before even acknowledging the control message from your primary?
> This doesn't require any changes to the protocol.
> 
> KRP - This is not a very scalable solution.  Specially for the session
data

Repeat after me: "Data messages do not need synchronizing", "Data
messages do not need synchronizing", "Data messages do not need
synchronizing"...

KRP - Yes they do not need synchronization, but if the LNS has turned on
sequencing for data sessions and is doing re-ordering, then how will it
behave if it receives data session message without sequencing.  My point is
I want to recover the call, I don't want the LNS to drop the call. Again,
this behavior should be indicated in the RFC2661. I think you are missing
the point here and that's ok because I have all the information for this
topic I need - thanks to you and andyk. 
> messages. IMO, the RFC2661 should state what the LNS MUST do when it
> receives session data messages without Ns when it was enabled by the LNS.
I

Sequencing on data packets within any tunneling protocol is a tricky
subject.

IMHO, the LNS SHOULD accept them. One could argue that the LNS should
have this wiggle room if it "knows" that sequencing is vital for the
particular state of the protocol being carried or not. I suppose it
would not hurt to make this more clear in the spec, though there are no
easy answers here.

> agree with andy that some mechanism should be recommended for resetting
the
> stateful information between LAC and LNS.  How about assigning a bit in
the
> common header for this purpose. Anytime either end want to reset the
> applicable sequence numbers they can set this bit in the control message.

And then you have to check this bit for every single data packet just to
enable the failover feature? Probably not a good choice. Error recovery
should not slow down your data packet performance.
KRP - read again, the bit is set in control message.  I have not described
the entire protocol here, just a concept. 
> This should trigger the other end reset its internal variables for the
> control and all the data session of the tunnel.  Again this is just an
> initial thought.

If we have the freedom to modify the protocol, this can probably all be
done with explicit signalling. Also, you could decouple the tunnel
control connection and sessions within if you wish. Bottom line, we
didn't consider this when designing the protocol at the beginning. If we
are going to modify the protocol to handle semi-full state failover,
then we should step back and approach it from a fresh perspective. 

- Mark

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 07 Mar 2001 11:01:07 -0500

> topic I need - thanks to you and andyk.

An implementation that is performing any sort of reordering MUST be able
to handle packet loss. This should be clear from RFC2661. 

This includes loss of a single packet, 1000 packets, 65535 packets, or
more. If you stop at a given sequence number, switchover, and pickup at
0, at worst you look like you dropped a bunch of packets, or sent a few
duplicates. Your tunnel peer may discard some packets on receipt, queue
some packets waiting for the "lost" one, etc. but the numbers should
sync up fairly quickly. 

> the entire protocol here, just a concept.

"common header" - I thought that included the data header. I'm glad you
agree that such a bit should only be inspected and set on the control
channel. Anyway, I think you could get away with this through explicit
signalling as I suggested below rather than chewing up a bit in the
header.

---

From: "Srikrish" <[email-masked]>
Date: Wed, 7 Mar 2001 12:52:44 -0800

Hello Guys,

   Just a suggestion (need validation,ofcourse),

   Since maintaining the state (of Ns/Nr) values for every packet
   in the standby card is painful process ( and performance issue too)

   And Sending Ns/Nr = 0 (in hello packet) during switch over can cause
   problems as described by Mark.

   Will following approach solve the problem.

   As a trade-off between two approaches,
   Maintaining the sequence number (Ns/Nr per tunnel) update in standby
   at regular interval and at the time of switch-over sending an
   Hello packet with Last stored Ns/Nr value may solve the problem.

Regards
Sriks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of W. Mark Townsley
Sent: March 7, 2001 8:01 AM
To: Keyur Parikh
Cc: Andy Koscinski; [email-masked]
Subject: Re: Few questions on L2TP..