Comments on -02 PS..

[Markus Stenberg <mstenber@xxxxxxxxx>]

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