Hi Pekka, What is the message Id that can be used to send the informational exchange while sending RESET_WINDOW notify? I find that your approach is similar to this draft as
1. Initiator(failover) and responder(peer) agree upon the new range of message Id's and ignore the lost message Id's. Both the approaches define new notifies and need to send a informational exchange to carry the notifies. 1. If window size is say some five and range expected is 4-8, and if peer has got all four requests with values 5,6,7,8 and 4 is lost, then there would be no message id that can be used to send the notify reset_window. The initiator will not know which message Id should be used to send the new notify. And here the problem is not only to send the request, but also to receive the request. The failover device should also know the permissible range in which it can receive the requests from the peer. The idea to send a new informational exchange with message Id zero was thought only because when the failover takes control it would not know what message Id it can use to know the peer window values .This is the basic problem of message Id synchronization, so having new notify itself will not help. Regards, Kalyani -----Original Message----- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Pekka Riikonen Sent: Saturday, September 04, 2010 4:14 PM To: ipsec@ietf.org Cc: y...@checkpoint.com; kivi...@iki.fi Subject: Re: [IPsec] Comments draft-kagarigi-ipsecme-ikev2-windowsync-04 On Fri, 3 Sep 2010, Pekka Riikonen wrote: : something like next_message_id += window_size / 2, and be happy. Though, : implementation must ensure it never sends more than the increment (that's why : window size of 1 doesn't work to begin with). Why was the window size defined : by default to 1 anyway? Is there a reason why this wouldn't work? : This doesn't actually work. I think I'm seeing some ambiquity in the spec when window size > 1. But, there's still ways to make this work easier than with new exchange. We could add new RESET_WINDOW notify that, when received inside a valid window will reset the left side of the window to the value requested. In failover (assuming window size > 1), the online node can send the notification to reset the window to the new value. Responder clears the old states in the window as initiator has now deemed them lost. Responder must reply with its N(RESET_WINDOW). At the same time we should add GET_WINDOW_SIZE notify which initiator can use to request/require responder to set the window size. Responder SHOULD respond with SET_WINDOW_SIZE of at least the same size. So when initiator sends its N(SET_WINDOW_SIZE) it could at the same time require the responder to send it too. All these notifications in the ikev2bis should be "MUST be supported". And then of course there's the poor man's way, where implementation after the failover could keep sending empty INFORMATIONAL's with new message ids, and wait until it receives response. It now knows the message ids to both directions. This requires that the message ids are synced in the cluster after every packet, so that node has recent values in the failover. Pekka _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
