We already have "arbitration" for a similar problem:
http://tools.ietf.org/html/rfc5996#section-2.8.1
Thanks,
Yaron
On 09/16/2010 11:43 AM, Pekka Riikonen wrote:
On Thu, 16 Sep 2010, Kalyani Garigipati (kagarigi) wrote:
: Regarding the race condition, I think instead of starting the message
: Id's altogether with 1, we can have the devices sync up to the higher
: value among the responses.
:
: Cluster A Cluster B
: request SYNC -->
:<-- request SYNC
: response (4,4) -->
:<-- response (5,5)
:
: Cluster A should update its values to 5,5 whereas Cluster B should not
: update its values since its values are higher than the values at Cluster
: A.
: Which means Cluster B has correctly synced its message values to some
: extent when compared with Cluster A.
:
I don't think this can work, because the responses can cross each other in
the network also, and most likely do if the requests did as well. That
is, Cluster A responds same time as Cluster B before it has received the
response. The implementation would have to wait for the response before
sending its own response. But, what if the other end is waiting it also?
It's a dead lock.
I think it needs to be a pre-defined value that both end set in this case
or there needs to be some arbitration between the peers to deicde who
waits. I'd go for the simplest solution.
Pekka
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
