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

"Jeff Parham" <[email protected]> Fri, 6 Jun 2003 12:52:08 -0700
Newsgroups gmane.ietf.ldup
Message-ID <6BA5A5D4255F564BBF4BF9E413BF53B801789812@WIN-MSG-05.wingroup.windeploy.ntdev.microsoft.com>


> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email protected]]
> Sent: Friday, June 06, 2003 10:29 AM
> To: Jeff Parham
> Cc: [email protected]
> Subject: RE: Applicability of LDAP Content Sync to loosely coupled
replica
> sets
> 
> At 06:36 PM 6/5/2003, Jeff Parham wrote:
> >> >Is LDAP Content Sync intended to be applicable in this case?
> >>
> >> Likely (but I'd have to think about it more).  I note that since
> >> LDAP Sync supports both updates+present and update+delete
> >> incremental synchronization mechanisms, if LCUP is applicable
> >> then likely so is LDAP Sync.
> >
> >I'm not sure I agree there.  The key difference between LCUP and LDAP
> >Content Sync is the ability to assert the "member objects" without
> >forcing a reload.  The implication is that an incremental sync can
force
> >the client to drop previous knowledge, which seems to be the heart of
> >the problematic example I illustrated.  LCUP doesn't have such a
> >mechanism; knowledge is lost only on a full reload.
> 
> LCUP not only support an incremental sync mechanism (updates+deletes)
> to drop previous knowledge, servers are to use those mechanism to
ensure
> eventual convergence.  If they cannot ensure eventual convergence,
they
> are to force a reload.
> 
> LDAP Sync provides two incremental sync mechanisms (updates+deletes
> and update+present), but has the same eventual convergence
requirements.

By "lost knowledge", I'm referring to knowledge the client did have and
should have in the future, but now does not.  In the example in
http://www.imc.org/ietf-ldup/mail-archive/msg01792.html, a client that
should in the fullness of time have a copy of the new object created on
DSA1 first gets that object from DSA1, then is forced to drop it after
performing an LDAP Content Sync against DSA2.  This is what I refer to
as "lost knowledge", as opposed to the case where synchronization
indicates to the client that an object that the client synced in the
past e.g. has moved out of the subtree being synchronized by the client.

How does LDAP Content Sync detect and recover from this lost knowledge
phenomenon?  If it does so by discouraging or eliminating the mechanism
that diffs the full set of objects by entryUUID, then LDAP Content Sync
essentially becomes the same proposal as LCUP.

In short, I would love to see a solution that requires little or no
history information on the DSA and simultaneously guarantees
convergence, but I'm having trouble seeing how the differences in LDAP
Content Sync over LCUP actually enable this in loosely coupled
deployments.

Thanks,
-J