RE: Operations crossing replication contexts

Steven,

I really feel that LDUP should address the issues involved in a single 
server handling multiple replication contexts.  If we don't I think we 
would be miss the mark by providing a replication model that would not 
meet the needs of LDAP directory deployments.

I agree that providing this implies changes to all the replication drafts 
- with exception, perhaps, of the requirements.  And since this probably 
has implications on the LDUP update protocol as well as the information 
model, it seems to me we should take the time to build it right now rather 
than have to build a whole new "version" to support mulitple replication 
contexts in a single server.

Regards,
Tim Hahn

Internet: [email protected]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681





"Steven Legg" <[email protected]>
Sent by: [email protected]
10/03/2001 04:03 AM
Please respond to steven.legg

 
        To:     <[email protected]>
        cc:     John McMeeking/Rochester/IBM@IBMUS, <[email protected]>
        Subject:        RE: Operations crossing replication contexts

 



John,

John Strassner wrote:
> Hmmm, just when I was about to call to see if all of the comments were
> finished on URP, up pops this message. So I have a quick 
> question to John,
> Steven, and others that are interested in this thread: is it 
> your aim to
> resolve this question as part of the URP Last Call, or is 
> this something
> that you think affects other documents than URP?

The question of immediate relevance to the last call on URP is whether
there is a single Lost & Found per server, or per replication context.
However there is a more general problem that the current LDUP documents
don't adequately address partial replication. I regard two or more
replication contexts held in the same server as an example of partial
replication since moving an entry between replication contexts is
essentially the same problem as a modification altering whether an entry
appears in a sparse replica. We don't have a documented solution in
either case.

If the current LDUP specification can only be effectively implemented
for servers holding one replication context and participating in no
partial replication agreements then the question of whether there is
one L&F per server or one L&F per replication context is rather academic
since the total is one in both cases.

The choice before us is to either:

(1) Issue a first round of LDUP RFCs that address the particular case
of only one replication context per server and no partial replication
agreements. We can issue a second round of RFCs that updates the first
set once we have a general solution for partial replication. Apart
from the amendments discussed during the last call period, URP is ready
for such a first round.

OR

(2) Not issue any RFCs until we have a solution for partial replication.

It is likely that a general solution for partial replication will have
some impact on URP. I don't envision any changes to the existing
procedures for processing replication primitives, but there might need
to be some extra primitives, and the procedures for applying user updates
will have to address changes that span multiple areas of replication.


Recently I've been thinking seriously again about LDUP partial 
replication.
In order to give an indication of the sort of impact partial replication
will make, here is a summary of some changes that would need to be made
to the LDUP architecture to apply the most promising ideas I've been
kicking around.

(i) Hierarchically identified replication areas (RAs). RAs form
subset/superset relationships. Servers enter into agreements to
replicate specific identified RAs. The RA has to exist before the
replication agreement is created.

(ii) An update vector per RA instead of per server. This gets around
severe restrictions on topology imposed by the Update Vector and
facilitates expedited changes.

(iii) Tagging replication primitives with the identifier of the RA
where the original client update was performed and restricting the
flow of replication primitives from servers holding subset RAs to
servers holding superset RAs.

(iv) Tagging each entry with the RAs it currently appears in
(it could be an operational attribute). Entries moving in and
out of scope of an RA are explicitly indicated by modifying the
tags. This is where extra replication primitives might come in.

At the moment I not sure if a have a foolproof way for a server
holding a subset RA to get all the relevant content for an entry
that has just moved into the scope of the subset RA. Glue entries
in sparse replicas also complicate the picture. I'm looking at
both a "push" model where the server holding the superset RA sends
the entry contents it *thinks* the server holding the subset RA
*might* need, and a "pull" model where the server holding the
subset RA asks the server holding the superset RA for the information
it believes is missing. Either method implies extensions to the
replication protocol.

When I think I have a workable solution I'll write up the details
and post to the list.

Regards,
Steven