RE: Applicability of LDAP Content Sync to loosely coupled replica sets

I think either of the sync proposals could be made to work with loosely
coupled replicas if:
1) the replication mechanism supports something like LDUP's "update vector"
-- something that indicates the latest information a replica has seen from
other replicas, AND
2) the cookie contains the equivalent of an update vector, AND
3) there is a defined cookie format that is understood by the DSAs the
client syncs with (possibly requested by the client)

This is already described in the back of LCUP, but it applies to both sync
proposals.

Or did I misinterpret this discussion?

[BTW - (3) is something else that is missing from draft-zeilenga-ldup-sync,
but I'm almost convinced it isn't needed.  Read on.]

The question, then, becomes whether a given replication implementation has
the information necessary to support this.

I haven't thought through how either approach would handle a reload (or
LDAP Sync's "entry present" messages) if the current DSA was known to be
out of date with respect to the state of the original DSA at the time the
client last synched with it.  That might require the client know more about
the replication mechanism -- server sends its update vector, client keeps
any information it has that is newer than the current DSA's update vector.
That starts to sound a whole lot like multi-master replication, and I don't
think we want to take LCUP there.  Maybe we just need the DSA to recognize
that the client has more current knowledge than the DSA, and not send any
updates until the DSA has caught up with the client.  We may want some
mechanism to tell the client the current DSA is out of date, but I don't
know what the client would do about it.  It doesn't hurt to provide the
information, even if the client choses not to do anything with it.

With multiple masters it could get more complicated - the DSA may have more
current information for information updated through it (or another DSA),
but be out of date with respect to changes originating at the original DSA.
This seems unlikely to me, as it would seem to require that the client be
syncing with differnt DSAs more frequently than replication occurs.  Maybe
we just accept that the client might go backwards briefly until the DSA
catches up.

For the DSA to not send updates until it has caught up with the client
doesn't require any changes to either sync proposal.  It just requires that
servers provide a multi-DSA capable sync implementation.  It may require
that the client be able to request a particular cookie format, but I think
it just requires that the DSA use a cookie format defined for the
particular replication mechanism it is using.  There might be one defined
for LDUP, and there might be others defined by vendors for their
replication implementations.


John  McMeeking