IPsec re-key is the process of negotiating a new pair of SAs with a certain amount of time after the current pair of SAs is being used. The in-place re-key process minimizes traffic loss during SA switchover.  Interoperational issues may appear during this process.  It is important to understand under what conditions the IPsec traffic should switch over from the old SA to the new SA.

This article clarifies the specification of IPsec SA switch over for IKEv2.

The IPsec rekey process detailed in rfc7296 section 2.8 indicates the IPsec SA switch over conditions:

"The responder can be assured that the initiator is prepared to receive messages on an SA if either (1) it has received a cryptographically valid message on the other half of the SA pair, or (2) the new SA rekeys an existing SA and it receives an IKE request to close the replaced SA."

According to the statement above, the responder should switch over to a new SA if it has either received a SA DELETE message to delete the old SA (condition #2), or if it has received a packet on the new SA (condition #1). Any of these two events should trigger traffic switch over at the responder. In practice, an implementation may rely on the UDP-based DELETE message (informational exchange with "delete" payload) which is with a unreliable nature. A better implementation is to check if data is received on the new SA. Junos devices switch traffic to a new SA as soon as the new SA is established.