RE: Comments on -02 PS..

["Narayanan, Vidya" <vidyan@xxxxxxxxxxxx>]

Hi Markus,
Thanks for the review.  I agree that the case for the MIP6 use is more
compelling than that for the regular VPN use, due to having to support
failovers for regular clients that don't support this in the latter
case.  However, the use of VPNs in a 3G environment (such as for use
over untrusted networks) can benefit from a solution such as this one.
Basically, as you note, if the clients support the solution developed
here, the gateways/servers would be able to use it, without having to do
any state replication.  Even if they do state replication, they can
support distributed failovers using this approach.  But, it will depend
on client support.  If the cellular standards require it on the client,
the gateways deployed in those enviroments can use this to provide a
distributed failover solution. In order to get there though, we need to
have a solution at the IETF for the cellular SDOs to consider and
evaluate it. 

Cheers,
Vidya

> -----Original Message-----
> From: owner-ietf-ipsec-failover@xxxxxxxxxxxxx 
> [mailto:owner-ietf-ipsec-failover@xxxxxxxxxxxxx] On Behalf Of 
> Markus Stenberg
> Sent: Tuesday, June 05, 2007 9:44 PM
> To: ietf-ipsec-failover@xxxxxxxx
> Subject: Comments on -02 PS..
> 
> 
> Disclaimer: I have been interested on and off about this 
> topic since the start, but missed the BoF due to $DAYJOB 
> forcing me to go to another WG. I also use term 'server' here 
> for the SGW/end host that the client connects to. I will 
> probably miss the Chicago BOF if it happens too, again due to $DAYJOB.
> 
> I think the PS has gone long ways in becoming concise and to 
> the point; the initial versions were less specific about the 
> applications, and how the solution was actually meant to work.
> 
> Currently, the problem stmt basically provides a way of 
> getting rid of most of the client/server computing load on 
> switchover, and the cost of HA server state synchronization 
> cost at the expense of some more complexity to the IPsec 
> suite / some storage on the client.
> 
> Looking at the pros/cons:
> 
> Client
> + faster switchover (mobility, HA) due to less roundtrips (this is
> most likely big concern in mobility case)
> + less computing on switchover (also nice for mobility)
> - storage of the authorization blob; should be fairly small, 
> although if vendor-specific extensions were allowed to 
> payload in general, it might grow..  just IKEv2 _protocol_ 
> state isn't that big
> - code complexity grows
> 
> Server
> + less load on non-check-pointed switchovers less state 
> storage needed 
> + overall (due to no need to replicate state) less complex code in 
> + general if HA can be skipped
> - however, if support for normal clients is also desired to 
> work 'well', you lose the above benefit and the one above 
> that is also bit questionable (certainly, across-site less 
> state, but who'd design such a solution in the first place?)
> - extra code
> 
> Looking at the arguments, if you control client/server, and 
> do anything with MIP, you'd definitely want this solution - 
> you could skip most of the normal IPsec-related HA code on 
> the server side, get more scalable failovers, and get nice, 
> fast switchovers for the mobile nodes given some assumptions 
> on how the HA is handled)
> 
> For normal VPN user case (is it still the traditional 
> assumption?), I see only marginal benefits due to lack of 
> guarantee of both ends supporting it - server needs to be 
> designed for non-supporting case, and client gets some 
> benefits with the rare server crashes, at cost of significant 
> chunk of extra code.
> 
> Overall? Seems worth doing to me, although I'm curious to 
> hearing some sort of 'show of hands' about people really 
> planning on implementing this, but guess that's what BoFs are for :-)
> 
> Cheers,
> 
> -Markus
> 
> 
>