Subject: RE: Few questions on L2TP hot standby..

From: Andy Koscinski <[email-masked]>
Date: Wed, 7 Mar 2001 01:14:01 -0800

my comments inline marked "andyk"

m> Just a thought: How about ensuring that your hot standby router has full
m> state before even acknowledging the control message from your primary?
m> This doesn't require any changes to the protocol.

KRP> - This is not a very scalable solution.  Specially for the session data

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

andyk> you might think the full state in the hot standby is best.
andyk> Practically, IMO it is not a very scalable solution today, because of

andyk> the storm of updates (e.g. Ns and Nr coming from the tunnel control
messages,
andyk> control, control, control,...) to the hot standby. Such storm will
reduce 
andyk> the active router performance as seen by it's peers, 
andyk> especially in the context of all other
andyk> concurrent protocols feeding the hot standby with the full state
andyk> (e.g. BGP, OSPF, MPLS, RSVP, LDP). On top you have to wait for an ack
from
andyk> the hot standby, because otherwise you don't know for sure if the
full 
andyk> state got into the hot standby. And then what if the ack got lost...
andyk> Full state in the hot standby is an alternative, I agree.  

andyk> another alternative is, to send a subset L2TP state to the hot
standby,
andyk> e.g. only active tunnels and sessions, no Ns or Nr, and have a simple

andyk> resync mechanism for tunnel hello's to execute after "switchover",
andyk> with the goal to keep all tunnels and data flowing after the
"switchover" in all 
andyk> active sessions, but accept a loss of a tunnel or session in a
transient state.

KRP> messages. IMO, the RFC2661 should state what the LNS MUST do when it
KRP> receives session data messages without Ns when it was enabled by the
LNS.  I

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

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

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

m> And then you have to check this bit for every single data packet 

andyk> I think KRP said "bit in the control message", 
andyk> not "bit for every single data packet"?

m> just to
m> enable the failover feature? Probably not a good choice. Error recovery
m> should not slow down your data packet performance.

KRP> This should trigger the other end reset its internal variables for the
KRP> control and all the data session of the tunnel.  Again this is just an
KRP> initial thought.

m>If we have the freedom to modify the protocol, this can probably all be
m>done with explicit signalling. 

andyk> I agree about the explicit signalling. 
andyk> the old L2TP implementations would ignore the new signalling
andyk> and - in consequence - reset all tunnels after failure, as it is done
today. 
andyk> The new L2TP implementations would understand the new signalling, 
andyk> resync the sequence counters and keep all tunnels up after a failure.

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

-andy