Subject: [L2tpext] Questions about draft-ietf-l2tpext-failover-02.txt

From: Paul Howard <[email-masked]>
Date: Tue, 30 Sep 2003 15:20:08 -0400

Vipin,

I've got some questions about the failover draft.

sec 2.3 - "Endpoints MUST avoid sending any control packets over the old 
tunnel that is being recovered".   What is the behavior for in-transit 
control packets?   I presume the receiver should silently discard any 
control packets on the old tunnel (no acknowledgement, no action based 
on received control packet).   I presume such behavior should start once 
recovery is detected (either by failed endpoint sending new SCCRQ or by 
failed endpoint's peer receiving new SCCRQ)?

sec 2.3.1, last bullet - "...it SHOULD clear the tunnel and sessions 
within that tunnel on its end".   I presume this is a silent clearing 
(no transmit of StopCCN or CDN)?

sec 2.3.3, last bullet - Would it not be potentially premature to start 
establishing new sessions prior to re-synchornization of the session 
state?  

sec 2.3.4 - "The Session State Inconsistency mechanism SHOULD be carried 
out only for sessions that are not getting any traffic".   It would seem 
that this would be based on observation of data flow after determining 
that a failover has started.   How would the failed endpoint do this 
reliably?   Consider that data is in-transit from the failed endpoint's 
peer when the failed endpoint starts tunnel recovery.   If this 
in-transit data is the last data to be sent and the failed endpoint's 
peer has initiated a disconnect then it would seem possible to have the 
failed endpoint consider the session established with data flow (and 
therefore not query it's peer) and for the peer to consider it not 
established (and thus not query the peer).   The result would seem to be 
a mis-match in the session state even after exchange of the FSQ and FSR.

sec 2.3.4 - "Data Plane Behavior" - When should the data flow be 
transitioned from the old TID to the new TID?   Should data flow be 
interrupted upon start of tunnel recovery until completion of tunnel 
recovery?   What about in-transit data that arrives after the switch to 
the new TID?   Should data on the old TID be accepted until data is 
received on the new TID?

sec 2.3.4 - "Data Plane Behavior" - "...the non-failed endpoint MUST set 
the next expected Ns based on the incoming Ns value..." - I presume the 
next expected Ns is set based on the incoming Ns value of the first data 
received on the new TID?   Why is this only required at the non-failed 
endpoint?

sec 3.1 - I presume multiple FSQs are allowed to handle situations with 
large numbers of sessions on a single tunnel?   Similarly with multiple 
FSRs?

sec a.2 - "target time of 3-5 seconds for 30K tunnels" - Does this 
really set a realistic expection?   It would seem that we're looking at 
on the order of 210K control packets to recovery 30K tunnels (SCCRQ, 
SCCRP, SCCCN, FSQ(2), FSR(2)).   This works out to 40K to 70K pps of 
control traffic at a time when one peer is doing failover recovery and 
is likely to be rather busy with activity over and above L2TP 
requirements.  

General - What was the reasoning behind creating a new tunnel instead of 
just doing a resync exchange on the extant tunnel?   Depending upon the 
structure of the implementation this could potentially be a rather 
expensive operation to "move" sessions to the new tunnel resulting in 
increased forwarding interruption, increased cpu intensiveness, and 
slower recovery.  I guess I don't understand the value in changing the 
TIDs.  

Thanx,

Paul Howard

_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext