Subject: Re: Supporting Partial Replication

From: "Steven Legg" <[email-masked]>
Date: Wed, 12 Dec 2001 05:08:13

Ryan,

Please disregard my previous reply to you (which didn't make it to the 
mailing list).
More below.

Ryan Moats wrote:
>On Thu, Dec 06, 2001 at 02:45:14PM +1100, Steven Legg wrote:
>| Folks,
>| A while ago I promised to write up my thoughts on changes to the LDUP
>| architecture to support partial replication. Well this is part one of
>| that write up, which discusses changes to the architecture to make it
>| more amenable to replication topologies involving partial replicas.
>| Consider the following replication topology:
>|   S1 ====== S2
>|     \      /
>|      \    /
>|       \  /
>|        S3
>| Servers S1 & S2 hold full copies of replication area R1. S3 holds
>| replication area R2, a subset of R1. R2 could be a subtree of R1, a
>| sparse replica or a fractional replica. The exact details don't matter
>| at this stage. It is enough to recognize that R2 is a subset of the
>| information in R1.
>| Suppose that there are two successive update operations, U1 & U2, 
>performed
>| at S2, where U1 affects information in R1 but wholly outside of R2 and U2
>| is wholly within R2 (and thus also within R1). The CSN alloted to U1 is
>| less than the CSN alloted to U2.
>| Suppose S3 and S2 establish replication sessions to exchange updates.
>| S3 has no changes to send. S2 will send U2 because it is within the scope
>| of the replication agreement S3 has with S2, but will not send U1.
>| S3 and S1 then establish replication sessions. S1 has no changes tosend.
>| S3 sends U2 since the CSN for U2 is more recent than the CSNcorresponding
>| to S2 in S1's update vector. S1 will set the CSN corresponding to S2 in
>| its update vector to be the CSN for U2.
>| Now, if S2 establishes a replication session with S1 it will send no
>| updates. In particular, it won't send U1 because the CSN corresponding to
>| S2 in S1's update vector is already greater than the CSN for U1. In fact,
>| S1 will never receive U1, so the requirement for all replicas to converge
>| will not be satisfied. In general, the current LDUP architecture only
>| works if the replication topology has no cycles, or where there are
>| cycles, if the replicas in each cycle have replication agreements for
>| exactly the same area of replication.
>|
>
>Hold on...  I'm deleting the rest of this message because you've lost me
>here.

Sorry. I was operating under a false assumption that a server can have only 
one replication
context and therefore only one update vector. I'll correct that shortly to 
remove some
of the confusion.

>I thought that (a) we had a separate CSN vector for each other
>server

You're thinking of the purge vector. In the current architecture, each 
replication
context a server maintains contains a replica subentry that holds a single
CSN vector which is its own update vector. There is also a replica subentry
for each other server, which holds a copy of the other server's update 
vector
in the same replication context.

The combination of a server's own update vector and the update vectors
received from all the other servers constitute the purge vector for that 
replication
context. The purge vector tells a server which of the CSNs it holds are old
enough to be discarded, but plays no part in deciding which updates are 
propagated.

>and that (b) that CSN vector was to the level of attribute and entry.

A CSN in an update vector is a replication context wide value. It is the CSN 
of
the most recent update in the associated replication context received from 
the
corresponding server .

>Thus,
>I don't see the problem.

The critical bit I missed was that in the case where R2 is a complete 
subordinate
subtree of R1 the current architecture avoids losing updates by making R2 a 
separate
replication context. However, R2 can also be a fractional replica or, in 
future, a sparse
replica (although the latest version of the information model effectively 
allows sparse
replicas by allowing non-trivial subtree specifications).

If R2 is a fractional replica then R1 and R2 share the same replication 
context and
therefore there is only one update vector for each of S1, S2 and S3 in my 
example.
Consider the example again, but assume R2 is a fractional replica of  R1.
I've appended the example with corrections as required.

Steven

=======================================================

Consider the following replication topology:

  S1 ====== S2
    \      /
     \    /
      \  /
       S3

Servers S1 & S2 hold full copies of replication area R1, which can be 
considered
to be the entire contents of a particular replication context. S3 holds
replication area R2, a subset of R1, in the same replication context.
R2 could be a sparse replica or a fractional replica. The exact details 
don't matter
at this stage. It is enough to recognize that R2 is a subset of the
information in R1, and that both are in the same replication context.

Suppose that there are two successive update operations, U1 & U2, performed
at S2, where U1 affects information in R1 but wholly outside of R2 and U2
is wholly within R2 (and thus also within R1). The CSN alloted to U1 is
less than the CSN alloted to U2.

Suppose S3 and S2 establish replication sessions to exchange updates.
S3 has no changes to send. S2 will send U2 because it is within the scope
of the replication agreement S3 has with S2, but will not send U1.

S3 and S1 then establish replication sessions. S1 has no changes to send.
S3 sends U2 since the CSN for U2 is more recent than the CSN corresponding
to S2 in S1's update vector. S1 will set the CSN corresponding to S2 in
its update vector to be the CSN for U2.

Now, if S2 establishes a replication session with S1 it will send no
updates. In particular, it won't send U1 because the CSN corresponding to
S2 in S1's update vector is already greater than the CSN for U1. In fact,
S1 will never receive U1, so the requirement for all replicas to converge
will not be satisfied. In general, the current LDUP architecture only
works if the replication topology with respect to a particular replication
context has no cycles, or where there are cycles, if the replicas in each
cycle have replication agreements for exactly the same area of replication.

However we can get around this restriction by maintaining an update vector
and replica ID per replication area (per replication context) for which a 
server
has a replication agreement, instead of a single update vector and single
replica ID per replication context per server.

A single replication context is assumed in what follows.
Let UV(S,R) be a reference to the update vector maintained by
server S for replication area R. It becomes convenient at this point to
have global unique identifiers for replication areas, e.g. R.
ASIDE: It also makes sense to have replication area descriptions as distinct
managed objects, and for replication agreement objects to just reference
a replication area by its unique identifier, instead of itself describing
the information to be replicated.

Suppose there is a server, S, with replication agreements for replication
area, R. We require a replica ID to uniquely identify the copy of the
information in R maintained by S. It is convenient for the purposes of
this discussion to use the notation S.R for that replica ID.

Let T be some other server and let Q be a replication area maintained by T.
An element in UV(S,R) for replica T.Q with the CSN value, C, is an assertion
that S has received from T.Q all updates to R with CSNs less than or equal
to C.

If all such updates have been received then it is also true that S has
received from T.Q all updates (with CSNs less than or equal to C) to
every replication area P, where P is a subset of R.

All the client updates processed by T.Q must be within replication area Q,
so if Q is a subset of, or the same as, R then S has received from T.Q all
updates (with CSNs less than or equal to C) to every replication area P,
where P is a superset of R.

We can use these results to obtain the following rule for maintaining
multiple update vectors in the one server, which for the sake of argument
I will call the update vector cascade rule:

  Given that S is receiving updates for replication area R, when S
  receives an update with a CSN containing a replica ID of T.Q it shall
  revise the CSN corresponding to T.Q in UV(S,R) and in every UV(S,P)
  where P is a subset of R. If Q is a subset of, or the same as, R then
  S shall revise the CSN corresponding to T.Q in every UV(S,P) where P
  is a superset of R.

For each update we need to be able to determine the replication area to
which it has been applied. Provided the replica and replication area
administrative objects are available then a lookup using the replica ID
in the CSN associated with update can give us the replication area. We also
need to be able to determine the supersets and subsets of the replication
area. This can be precalculated and cached from examination of the
replication area objects.

Now I'll show how the new architecture supports the topology of the
original example. Conceptually, S1 will now hold two replicas S1.R1 and
S1.R2, and two update vectors UV(S1,R1) and UV(S1,R2). S2 will now hold
two replicas S2.R1 and S2.R2, and two update vectors UV(S2,R1) and
UV(S2,R2). S3 holds only one replica S3.R2 and one update vector UV(S3,R2).

The update U1 is within R1 but outside R2 so this update is necessarily
applied to the replica S2.R1. The replica ID in the CSN for U1 will be
S2.R1.

In applying the update U2, S2 has a choice between replicas S2.R1 and
S2.R2 since U2 is within both R1 and R2. The detailed steps following
each choice are different, but the final outcome is always the same.
Note that S2 doesn't hold duplicates of all the entries and attributes
in R2. U2 acts on the same instance of the target entry and its attributes
regardless of the selected replica. The only material difference is the
replica ID that goes into the CSN generated for U2.

Firstly, I'll run through what happens if S2 chooses to apply U2 within R2.
The replica ID in the CSN for U2 will be S2.R2. S2 will set the CSN
corresponding to S2.R2 in UV(S2,R2) to be the CSN for U2. It will also
set the CSN corresponding to S2.R2 in UV(S2,R1) to be the CSN for U2.
This is the result of S2 applying the cascade rule to itself (R = Q = R2,
S = T = S2).

S3 and S2 establish replication sessions to exchange updates to replication
area R2. As before, S3 has no changes to send, and S2 will send U2 but
will not send U1. S3 sets the CSN corresponding to S2.R2 in UV(S3,R2) to
the CSN for U2.

S3 and S1 establish replication sessions to exchange updates to replication
area R2. S1 has no changes to send, as before. S3 sends U2 since the CSN
on U2 is more recent than the CSN corresponding to S2.R2 in UV(S1,R2).
S1 will set the CSN corresponding to S2.R2 in UV(S1,R2) to be the CSN for
U2. S1 will also set the CSN corresponding to S2.R2 in UV(S1,R1) by
application of the cascade rule (S = S1, T = S2, R = Q = R2).

If S2 establishes a replication session with S1 to send updates to
replication area R1 it will obtain UV(S1,R1). S2 will send U1 to S1 since
the CSN for U1 is greater than the CSN corresponding to S2.R1 in UV(S1,R1).
It won't send U2 since the CSN corresponding to S2.R2 in UV(S1,R1) already
has the value of the CSN for U2.

So S3 gets U2 and S1 gets both U1 and U2, exactly as it should be.

Now, I'll run through what happens if S2 chooses to apply U2 within R1.
The replica ID in the CSN for U2 will be S2.R1. S2 will set the CSN
corresponding to S2.R1 in UV(S2,R1) to be the CSN for U2. It will also
set the CSN corresponding to S2.R1 in UV(S2,R2) to be the CSN for U2.
This is the result of S2 applying the cascade rule to itself (R = Q = R1,
S = T = S2).

S3 and S2 establish replication sessions to exchange updates to replication
area R2. As before, S3 has no changes to send, and S2 will send U2 but
will not send U1. S3 sets the CSN corresponding to S2.R1 in UV(S3,R2) to
the CSN for U2.

S3 and S1 establish replication sessions to exchange updates to replication
area R2. S1 has no changes to send, as before. S3 sends U2 since the CSN
on U2 is more recent than the CSN corresponding to S2.R1 in UV(S1,R2).
S1 will set the CSN corresponding to S2.R1 in UV(S1,R2) to be the CSN for
U2. Application of the cascade rule (S = S1, T = S2, R = R2, Q = R1)
results in NO changes to UV(S1,R1). We now have the situation that U2 is
notionally present in the replica S1.R2 but not in the replica S1.R1. As
I indicated earlier, a server doesn't hold duplicates of entries and
attributes that are in multiple replication areas. If S1 engages in any
replication sessions with other servers for the replication area R1 it
must exclude any changes with CSNs greater than the relevant CSN in
UV(S1,R1). This includes U2 when it has been originally applied within R1
and so far only received via S3.

If S2 establishes a replication session with S1 to send updates to
replication area R1 it will obtain UV(S1,R1). S2 will send both U1 and U2
to S1 since the CSNs for U1 and U2 are greater than the CSN corresponding
to S2.R1 in UV(S1,R1). S1 will receive U2 twice but URP will quickly
ignore the duplicate. Importantly, S1 will set the CSN corresponding to
S2.R1 in UV(S1,R1) to be the CSN for U2.

We can avoid the duplication if we arrange for S2 to obtain both UV(S1,R1)
and UV(S1,R2) (in general, any UV(S1,P) where P is a subset of R1) at the
start of the replication session, but we must still make some provision
for UV(S1,R1) to be revised correctly. It will be easier to just accept
that there may be some harmless duplication.

This example is too simple and narrow to show it but in general, applying
an update to the smallest subset replication area (e.g. R2 instead of R1)
allows it to propagate through more paths, more quickly and with less
duplication.

The following topology is more interesting but I'll leave example
walkthroughs as an exercise for the reader.

       S0
      /  \
     /    \
    /      \
  S1        S2
    \      /
     \    /
      \  /
       S3

Servers S0, S1 and S2 hold full copies of replication area R1 in some 
replication context.
S3 holds replication area R2, a subset of R1, in the same replication 
context.

In this situation S0 only has replication agreements for R1 and therefore
only needs to maintain one update vector UV(S0,R1). It doesn't need to
bother with R2. This is a particularly useful result because it means that
a server, having entered into a replication agreement with some peer
server, isn't signficantly affected by the replication agreements the peer
server might make with yet other servers.

The extended architecture described here also provides a mechanism for
supporting expedited changes, which aren't possible in the current
architecture. The information, changes to which are to be expedited, is
set up as a subset replication area. Additional replication agreements
are established with the peer servers for this subset replication area,
presumably with on-change replication schedules. Updates to the subset
area get propagated immediately, while other updates propagate less
frequently, but eventually all updates get through.

The extended architecture can also handle replication areas that are
subordinate subtrees in a replication context without needing to make
the subordinate subtree a separate replication context.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

---

From: "John McMeeking" <[email-masked]>
Date: Fri, 21 Dec 2001 08:00:42 -0600

Before I go on vacation too...

We seem to be operating on different understandings of LDUP with respect to
areas of replication, replication contexts, and update vectors.

You mention a "fourth option", being to maintain "an update vector per
replication area in a replication context and use the cascade rule to
maintain the update vectors."  As I understand LDUP: an area of replication
and a replication context are the same thing, with replication context
being the current LDUP  terminology.  They identify an area of the DIT that
is replicated -- a replication context has a single root entry and is
bounded by subordinate replication contexts (ldup-model 3.5 - Terms and
Definitions).  LDUP already defines a separate update vector per
replication context (per replica).  On the surface at least, your "fourth
option" appears to be LDUP as currently defined.

For a server to participate in a cycle (which ldup-replica-req now refers
to as a "replica group" precisely because of the misunderstanding I had
about your use of cyle), the server must hold a copy of the replication
context.  And just to make sure my assumptions about what this means are
clear:
- a replica group is defined in the context of a replication context.  It
is the servers that hold instances of a particular area of replication.  A
server may be part of several replica-groups.
- replication agreements are defined in the context of a replication
context.

In your example, with three servers and two replication contexts,
agreements between all the servers implies that there are two sets of
agreements between each server -- a set for each replication context.  The
existance of a replication agreement in one replication context does not
imply a corresponding agreement in other replication contexts.

I'm going to go out on a limb, and guess that part of our misunderstandings
has to do with "overlapping" replication contexts -- you mentioned
replicating ACL via sparse or fractional replication, while having a full
replica of some subtree).  This may be required by ldup-replica-req
(mentioned in terminology, but not in specific requirements), but is
currently listed as a non-objective of ldup-model (section 3.3e).  Would it
be fair to state that you think ldup-model (and friends) needs to address
overlapping replication contexts?  My responses have been in the context of
what ldup-model claims to support, and in that context I seem to be having
a problem understanding your concerns and properly communicating my
understanding.

John  McMeeking

                      "Steven Legg"                                                                                        
                      <steven.legg@adac        To:       John McMeeking/Rochester/IBM@IBMUS                                
                      el.com.au>               cc:       <[email-masked]>                                               
                                               Subject:  RE: Supporting Partial Replication                                
                      12/20/2001 11:51                                                                                     
                      PM                                                                                                   
                      Please respond to                                                                                    
                      steven.legg                                                                                          

John,

John McMeeking wrote:
> See responses marked <JAM>

> John,
>
> John McMeeking wrote:
> > For either S1
> > or S2 to replicate U1 to S3, replication context R1 must be added to
S3,
> > and the replication context properly initialized on S3 -- either via a
> full
> > update replication session, or via some other means (i.e. LDIF). At
that
> > point, U1 (and the rest of the entries in R1) are present on S3 and
> > replication continues normally. Replication of R1 is independent of R2.
>
> You're alluding to the flip side of what I'm saying. If the current
> architecture can't support a replication topology where the servers
> in a cycle hold different replication areas in the same replication
> context then the choices are to not replicate, or to force all the
> servers in the cycle to have the same replication area(s). Too bad
> if I don't want S3 to see stuff in R1.
>
> <JAM>
> Are you talking about setting up something like this?

No. The choices are:

1) don't replicate, i.e. break the cycle by throwing out S3 (in my original
example),

2) force all servers in the cycle to have the same replication area,
i.e. S1 holds R1, S2 holds R1 and S3 holds R1, forget about R2,

3) change the LDUP architecture to support the original topology.

> Server S1 hold R1 and R2
> Server S2 holds R2
> Server S3 holds R1 and R2
> Set up replication agreements such that S1 supplies S2, S2 supplies S3
> and S3 supplies S1.
>
> As defined (and I think we agree this is the current behavior), LDUP
> allows this to be done only for R2. As S2 does not hold R1, you can
> not set up replication for R1 to/from S2. As I understand it, the
> agreements for R1 and R2 are completely independent. For example, if
> I add R2 to S2, and then set up the cycle described above, there would
> be at least 6 replication agreements S1->S2(R1), S1->S2(R2), S2->S3(R1),
> ... Going back to the scenario described above, under LDUP you would
> set up two independent cycles: S1->S2->S1 (for R1) and S1->S2->S3->S1
> (for R2).

They're not independent since S1 and S2 each have a single update vector
for both R1 and R2 in the current architecture. Events in one cycle
affect the other.

>
> I don't see a problem.
> </JAM>
>
> > If R2 is a sparse/fractional replica of R1, R2 would not be considered
a
> > separate replication context. In this case, sparse/fractional
replication
> > is an attribute of the replicaSubentry for S3. If U1 falls within the
> > attributes and/or entries specified for S3, it will be replicated under
> > the replication agreements targeting S3 under R1, and the UV for S3
updated
> > accordingly.
> >
> > What happens when S3 is a fractional replica, and U1 does not contain
any
> > attributes replicated to S3? draft-ietf-ldup-model-06, section 8.2,
> > specifies "When fully populating or incrementally bringing up to date a
> > Fractional Replica each of the Replication Updates must only
> > contain updates to the attributes in the Fractional Entry
Specification."
> > This implies that S3 will never see U1, and thus not fully update its
> > update vector until such time as it receives an update originating at
the
> > same server.
>
> Do you agree that S1 will also never see U1 ?
> This breaks eventual convergence.
>
> <JAM>
>
> Okay, now I think I understand... Let me restate this scenario:
> S1 holds full replica of R1
> S2 hold full replica of R1
> S3 holds fractional replica of R1
> Replication agreements are defined such that S1 supplies S3, S3 supplies
S2,
> and S2 supplies S1.

I've assumed symmetry in the replication agreements for my original
example,
so the topology is a undirected graph. S1 supplies S2, S1 supplies S3,
S2 supplies S1, S2 supplies S3, S3 supplies S1 and S3 supplies S2. The
subset of these agreements that are significant to the example are S2
supplies S1, S2 supplies S3 and S3 supplies S1. The other agreements are
invoked but end up sending nothing new.

>
> Under such an configuration, U1 is not seen by S3, as S1 doesn't
replicate
> it to S2. Before proceeding, let me restate that there is a difference
> between holding a subtree of an area of replication and holding a
> fractional replica. As I understand it, holding a subtree implies the
> existance of another area of replication corresponding to that subtree
> -- as opposed to a sparse replica (not supported by the ldup model) which
> holds some entries in an area of replication.
>
> I see three solutions to the problem you describe:
>
> 1. Replace the restriction in ldup-model-06 8.2 such that all updates are
> sent to fractional replicas. When acting as a supplier, a fractional
replica
> replicates all replication updates, even those that are not within the
set
> of attributes held by the fractional replica. Also, the fractional
replica
> is responsible for applying only those update primitives that are within
> the fractional replica specification.
>
> I think this would cause major problems for state-based implementations.

Agreed. The server has to store the updates "somewhere" so that they
can be forwarded to other servers.

> It seems reasonable for log-based implementations.

I would expect there to be administrator concerns regardless of the style
of implementation. One reason for setting up a fractional replica is to
protect
certain information held by the supplier from being seen by the consumer.

>
> 2. Add a resriction to the model & info model to effect that a fractional
> replica cannot act as a supplier in LDUP.
>
> In your scenario that implies S3 cannot be a supplier to S1. Thus S2 must
> be a supplier to S2 and U1 and U2 are both replicated from S2 to S1. I'm
> not sure how this would be done -- either the configuration is rejected
> (preferred), or a fractional replica simply ignores requests to act as a
> supplier. I prefer rejecting the configuration -- why let someone set up
> a replication path that will never be used?
>
> 3. Add a restriction that a fractional replica can act as a supplier only
> to another fractional replica, where the consumers fractional
specification
> is a subset of the suppliers fractional specification (i.e. the supplier
> replica holds all entries/attributes held by the consumer, and may hold
more).
>
> For your scenario, this would preclude S3 acting as a supplier to S2
> (S2 - a full replica - does not hold a subset of the attributes held be
S3).
> I'm not sure where/when this restriction would be enforced. It seems that
> either the configuration has to be rejected outright -- topic for
management
> draft -- or that a supplier would have to evaluate the fractional
> specifications (if any) for itself and the consumer and determine whether
> it should, in fact use the agreement at all.

Solutions 2 and 3 both kill any possibility of updateable sparse and/or
fractional replicas. This seriously limits LDUP's usefulness in database
synchronization since external sources of data with which a directory may
be required to synchronize are likely to be both updateable and
sparse/fractional.

They also outlaw secondary shadowing topologies allowed by X.500
replication,
and which I already support. For instance, it would not be possible for a
server to shadow portions from two different naming contexts. In X.500,
administrative areas, e.g. for access control or schema, can and do span
naming contexts (replication contexts in LDUP). The administrative policy
inherited from superior naming contexts is called prefix information and
is included in X.500 replication updates. Prefix information is effectively
a read-only, sparse and fractional copy of information from a superior
naming context. The prefix information for two different naming contexts
will overlap, but neither will be a subset of the other. Solutions 2 and 3
will disallow the prefix information from two such naming contexts to be
replicated to the same shadow DSA.

>
> Assuming state-based replication remains in the standards, I think (2)
> would be a much cleaner solution, and most easily implemented.

... and very limiting. I don't want to have to choose between flexible
replication topologies and multiple masters. I want both.

You didn't enumerate the fourth solution: have an update vector per
replication area in a replication context and use the cascade rule to
maintain the update vectors.

P.S. I'm about to go off for a short break. I'll respond to any
follow-ups after I get back in two weeks.

Regards,
Steven

---

From: "Ed Reed" <[email-masked]>
Date: Fri, 21 Dec 2001 11:55:29 -0700

John - I think you're onto the right track in determining where the disconnect
exists.  

To begin, note that the model only talks about fractional, and not sparse,
replicas.  

Fractional replicas are those that hold entries having a subset
of all the attributes defined on compete replicas holding those entries.  All
entries of a replication context are present in a fractional replica, but not
all of their attributes are there.  It is the entries which are fractional.

Sparse replicas, we agreed, are those where not every entry of the
replication context are held on the sparse replica.  But every entry
that IS held is complete.  It is the namespace that is sparse.

A Sparse and/or Fractional replica (an incomplete replica, in earlier drafts
of the model) hold some of the entries of the replication context, and they
may or may not be complete (ie, some entries may be fractional entries).
In other words, the namespace is sparse and the entries held may be
fractional.

We dropped sparse replicas from the Arch Model when we couldn't
persuade ourselves that we knew how to deal with update vectors and
purge vectors for sparse replicas.  

Now, I've never contemplated a scenario in which a server holds two
replicas of same replication context.  There may be utility in
such a scenario, but it has never occured to me.  Thus, there is one
update vector for the replication context, on the replicaSubentry.

The LDUP model in my mind partitions naming contexts with replication
contexts.  Note that both naming contexts and replication contexts are
subjects of the DIT, not of any particular DIB.  A replica is a set of
entries from a naming context held in a particular DIB by a particular
LDAP server.  There may be multiple replicas of any replication context.

But as I said, it had never occured to me to consider a DSA holding
multiple replicas of the same replication context in its DIB.

Rather, I assumed that a DSA would be considered to hold in its DIB
all the entries from a replication context that it needed for its own
purposes, and for the purposes of forwarding updates to other servers
that it supplies updates to, if any.

So, subordinate to the replicaSubentry representing the replica in the
DIB of a DSA, there could be several replicationAgreements - some
of which place no additional filters on the updates being sent, and 
some that DO further restrict which attributes (for fractional entries)
are to be forwarded to the specific other DSA replica pointed to by
each replicationAgreementSubentry.

Thus - a replicaSubentry documents the entries held by the DSA and
whether there are any limits on the attributes held for those entries,
and replicationAgreementSubentries documents the flow of
entries (and their attributes, possibly filtered) between a replica
and another.

If the set of entries in replication area A held by replica 1 is 
designated A1 on Server S1, and there is a subset of A held on another
server S2 designated A2, A1 is a complete replica and A2 is an
incomplete replica.  It would be redundant to say that A2 and A1
are both held by S1, though they are, because all the entries of A2
(being a subset of A) are in A1 (the full set of A).

Now, A1 on S1 might very well have a replicationAgreement with A2
on S2 such that A1 only sends what A2 needs because of the filters
on the replication agreement, or even because of filters on the
replicaSubentry for A2.

But the notion that both A1 and A2 would be considered to both
be on a single server is simply not something I have ever considered.
I don't know if the model could work in such a scenario or not.

Ed
>>> "John McMeeking" <[email-masked]> 12/21/01 09:00AM >>>

John  McMeeking

                      "Steven Legg"                                                                                        
                      <steven.legg@adac        To:       John McMeeking/Rochester/IBM@IBMUS                                
                      el.com.au>               cc:       <[email-masked]>                                               
                                               Subject:  RE: Supporting Partial Replication                                
                      12/20/2001 11:51                                                                                     
                      PM                                                                                                   
                      Please respond to                                                                                    isingle server is simply not something I 
                      steven.legg                                                                                          

John,

S3,
that

No. The choices are:

a
replication
updated
any
Specification."
the
> > same server.
>Ile server is simply not something I 
S2,

replicate
replica
set
replica

specification
more).
S3).
management

Regards,
Steven

=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402
http://www.Reed-Matthews.COM
Note:  Area code is 585

---

From: "John McMeeking" <[email-masked]>
Date: Fri, 21 Dec 2001 11:18:03 -0600

Updated to add some thoughts on overlapping replication contexts...

John McMeeking

You mention a "fourth option", being to maintain "an update vector per
replication area in a replication context and use the cascade rule to
maintain the update vectors." As I understand LDUP: an area of replication
and a replication context are the same thing, with replication context
being the current LDUP terminology. They identify an area of the DIT that
is replicated -- a replication context has a single root entry and is
bounded by subordinate replication contexts (ldup-model 3.5 - Terms and
Definitions). LDUP already defines a separate update vector per replication
context (per replica). On the surface at least, your "fourth option"
appears to be LDUP as currently defined.

For a server to participate in a cycle (which ldup-replica-req now refers
to as a "replica group" precisely because of the misunderstanding I had
about your use of cyle), the server must hold a copy of the replication
context. And just to make sure my assumptions about what this means are
clear:
- a replica group is defined in the context of a replication context. It is
the servers that hold instances of a particular area of replication. A
server may be part of several replica-groups.
- replication agreements are defined in the context of a replication
context.

After thinking about overlapping replication contexts a bit more, IF we are
going to tackle it, I think we need to address the following:
1.  How do we define the bounds of a replication context that is not
bounded by nested replication contexts?  Kurt Zielenga's ldap-subentry
draft would be useful here (subtree specification).
2.  If a client update falls within multiple replication contexts, how
should LDUP behave?  Let's start with replicating changes under all
appropriate replication contexts, meaning that the same update will be sent
multiple times under different replication sessions (they are idempotent,
so this should be okay).  This should keep update vectors in the correct
state, as an update under one replication context may be replicated before
earlier updates (by CSN) that fall within other overlapping replication
contexts.
3.  Do we allow multiple replication contexts with different bounds to have
the same root?  I'd like to withdraw the question, because I'm sure that
once asked, the answer will be "YES!"  This makes my head hurt more than I
need just before Christmas, so I'll leave that for others to gnaw on.

John McMeeking

"Steven Legg" <[email-masked]>

                                "Steven Legg"                             
                                <steven.legg@adac To: John                
                                el.com.au>        McMeeking/Rochester/IBM 
                                                  @IBMUS                  
                                                  cc: <[email-masked]> 
                                12/20/2001 11:51  Subject: RE: Supporting 
                                PM                Partial Replication     
                                Please respond to                         
                                steven.legg                               

John,

S3,
that

No. The choices are:

a
replication
updated
any
Specification."
the
S2,

replicate
replica
set
replica

specification
more).
S3).
management

> would be a much cleaner solution, and most easily implemented.

.. and very limiting. I don't want to have to choose between flexible
replication topologies and multiple masters. I want both.

Regards,
Steven