RE: Supporting Partial Replication

John,

John McMeeking wrote:
> I agree with Ryan on the first part of the note (I haven't gotten through
> the flurry of LDUP notes).

See my reply to Ryan for corrections and clarifications.

> But, we may have a problem with update vectors
> under partial/fractional replication.

Yes.

> Update vectors are defined per replica and per replication context
(actually,
> defined per replica, where a replica is a replicated instance of a
> replication context).
>
> If R2 is a subtree of R1, separate update vectors are maintained for both
> R2 and R1, and the problem Steven describes doesn't occur.

Yes (doh!).

> 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.

> 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.

> Steven's example described U1 and U2 as successive updates
> originating at S2. Suppose U1 originated at S1 and U2 originated at S2:
>
> Initially, the update vector for S3 (UV3) looks like
> < Tx#1#0#0, Ty#2#0#0, null > (latest CSNs from S1 and S2, no updates
> originating at S3)

BTW, you have the second and third components of the CSNs transposed.

> At time T15, on server 1, client performs update U1: CSN = T15#1#0#0.
>
> This is replicated to S2, and eventually S2 replicates to S3. But since
> no attributes in U1 are present in S3's fractional entry specification,
> no replication occurs.
>
> Update vector for S3 remains < Tx#1#0#0, Ty#2#0#0, null >

There are some subtleties in the way that the update vector is maintained
that are not explicitly called out by the architecture draft. The update
U1 at S1 causes the update vector for S1 to be revised, but since the
CSN < T15#1#0#0 > in the update vector for S1 is an attribute value it is
tagged with a CSN! Common sense suggests this CSN should also be < T15#1#0#0
>.
Changes to the update vector are always replicated (as add-attribute-value
primitives), so S3 will receive the change to S1's update vector because
of U1, even though it doesn't receive U1. On receiving the
add-attribute-value primitive for S1's update vector, S3 will change its
copy of S1's update vector. It will also change the CSN for S1 in it's own
update vector to < T15#1#0#0 >, the CSN on the add-attribute-value
primitive.

The update vector for S3 actually becomes < T15#1#0#0, Ty#2#0#0, null >.
The purge point advances in due course.

Regards,
Steven