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

From: John McMeeking <[email-masked]>
Date: Sat, 7 Jun 2003 20:30:53 -0500

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

---

From: [email-masked] (Mark C Smith)
Date: Mon, 09 Jun 2003 10:18:09 -0400

> but I'm almost convinced it isn't needed.  Read on.]

In the past, there were very strong feelings expressed by several LDUP 
WG members that a defined cookie format IS needed. Assume Server A was 
written by Vendor A and Server B by Vendor B. Without a well defined 
cookie format, an LCUP client will not be able synchronize with Server A 
today and with Server B tomorrow without doing a full reload. While I 
think we are some distance away from being ready to define a standard 
cookie format, I do agree we will want to do so eventually. Hence the 
cookie scheme identifier (OID) contained in the LCUP working group 
deliverable.

Because I interpreted the recent charge from the WG chairs and ADs as 
"focus on whether draft-ietf-ldup-lcup-05 has any show stopper problems" 
I have avoided diving into a detailed discussion of 
draft-zeilenga-ldup-sync.  But one comment related to this cookie issue: 
the text in draft-zeilenga-ldup-sync leads me to believe that its 
"Synchronization Sessions" not only can't occur across different vendor 
implementations, but are restricted to one particular server instance as 
well. That limitation might be OK if your primary goal is to provide 
server to server replication, but it is unacceptable in many other 
scenarios. For example, I want to provide a distributed set of LDAP 
replicas that email clients may use to maintain offline copies of the 
corporate addressbook.

-Mark