RE: Replica Management - subtreespecification attribute

"John McMeeking" <[email protected]> Wed, 27 Feb 2002 16:11:50 -0600

Newsgroups	gmane.ietf.ldup
Message-ID	<[email protected]>

My two bits worth:

First, I have to confess that I am not sure that supporting overlapping
areas of replication is worth the effort. But that may be just because I
haven't had a need for it.

Here's what I would do:

An area of replication is defined by a "replicationAreaSubentry" placed
immediately below the root of the area of replication. If the
replicationAreaSubentry has a subtree specification, the subtree
specification defines the bounds of the area of replication. In the
absense of a subtree specification, the area of replication extends
downwards through the DIT until reaching another area of replication. That
much should be in keeping with x.500 administrative areas. The
replicationContext auxiliary class would go away.

A replicaSubentry describes a single server's role in a single area of
replication. The area of replication that the subentry applies to is
identified by a new single-valued "areaOfReplication" attribute.
ReplicaSubentries can be located anywhere within the area of replication;
there is no need to be just below the root entry. subtreeSpecifications on
a replicaSubentry are not allowed.

Do not allow refinements on agreements, unless someone can describe a
realistic scenario where the consumer server claims to support certain
attributes, but those attribute should not be replicated to it by certain
servers.

Otherwise, the rest of replicaSubentry and replication agreements can stand
is is.

>From a replication protocol perspective, an area of replication would be
identified by the DN of the replicationAreaSubentry. If a server holds
overlapping areas of replication, any change which applies to multiple
areas would be replicated under all areas of replication. The change
should be idempotent (and hopefully fast compared to a new update) from
perspective of the consumer, but it does chew up extra bandwidth. This is
necessary to make update vectors work properly.

And here's why -- my experience says I really need people in a room and a
whiteboard to get through these discussions,but I'll try a note anyway:

There is some behavior related to the use of update vectors that requires
careful consideration when defining multiple areas of replication rooted at
the same entry, or further refining replication at the subentry or
replication agreement level.

First, imbedded in the protocol is the notion that an update vector is
associated with a replicated area. When starting a replication session,
the supplier identifies the replicated area and the consumer responds with
its update vector for that area. A consumer server ignores replication
updates that have CSNs covered by its update vector. Right now, it is
assumed that the replicated area is identified by the DN of an entry that
is decorated with the replicationContext auxiliary class. That could be
changed, but right now, it happens that the update vector is associated
with a replicaSubentry, and each replica is represented by a single
replicaSubentry immediately subordinate to the replicationContext. I think
most people expect that each server corresponds to exactly one replica and
replicaSubentry.

If I have all this right, then it follws that each server has one update
vector associated with each replicationContext entry.

Second, purge processing makes use of the update vectors. A server can
purge meta-data based on a purge vector that is the minimum of all the
update vectors for a given replicated area. Currently, this would be the
update vectors associated with each replicasubentry beneath a
replicationContext.

Consider the following scenarios...

Scenario 1:

I have three servers, S1, S2, and S3, all containing replicas of replicated
area A. There are agreements between all of these servers, and the
agreement S2 to S3 has a subtreespecification (or other refinement). A
series of changes, C1 (CSN = T1-1) and C2 (CSN=T1-2), is made at S1, such
that C1 is outside the subtreespecification attached to the S2 to S3
agreement. Finally, lets assume that scheduling of replication is such
that S1 replicates to S2, then S2 replicates to S3, and then S1 replicates
to S3.

- S1 replicates to S2: S1 replicates both C1 and C2 to S2. S2 sets its
update vector to <T1-2, 0, 0> reflecting that it has received changes
through T1-2 originating at S1.

- S2 replicates to S3: S2 replicates C2 to S3, but not C1 (due to
subtreespecification on the agreement). S3 sets its update vector to <T1-
2, 0, 0>.

- S1 replicates to S3. S3 sends its update vector to S1. S1 notes that S3
has seen all changes through T1-2, and sends nothing. S3 does not receive
change C1.

Based on this, I believe that we cannot allow refinements on agreements.

Scenario 2:

I have three servers, S1, S2, and S3, all containing replicated area A.
However, the subentry for S2 has a subtree specification that excludes some
portion of the area. There are agreements between all these servers. A
series of changes, C1 (CSN=T1-1 and C2 (CSN = T1-2) is made at S1 such that
C1 is outside of the subtree specification for S2. Finally, lets assume
that scheduling of replication is such that S1 replicates to S2, then S2
replicates to S3, and then S1 replicates to S3.

- S1 replicates to S2. S1 does not replicate C1 to S2 (not within the S2's
subtree specification), S1 does replicate C2. S2 sets its update vector to
<T1-2, 0, 0>

- S2 replicates to S3. S2 sends C2 to S3. S3 sets its update vector to
<T1-2, 0, 0>.

- S1 replicates to S3. S3 sends its update vector to S1. S1 notes that S3
has seen changes through T1-2 and sends nothing. S3 does not ever receive
change C1.

Based on this, I believe that S2 cannot be allowed to replicate to S3 --
Replica S2 cannot act as a supplier to replica S3 if S2 is a proper subset
of S3. One alternative is that S2 accept changes outside its subtree
specification and that it replicate them, but does not store them in its
DIT. I don't imagine that flying well.

Scenario 3:

Take scenario two, but make a series of changes at S1 -- C1, C2 ... , such
that only C1 falls within the subtree specification for S2.

- S1 replicates to S2. S1 sends C1, but not C2...Cn. S2 sets its update
vector to <T1-1, 0, 0>

- S2 cannot replicate to S3 (S2 is a subset of S3).

- S1 replicates to S3. S3 sends its update vector to S1, and S1 sends
C1...Cn to S3. S3 sets its update vector to <T1-n, 0, 0>

- S1 does purge processing. It notes that its copy of the update vector
for S2 has T1-1. No changes after T1-1 are purged until a change is made
at S1 that falls within the subtree specification for S2. This violates
the requirement that meta-data cannot grow without bound. One alternative
is that S2 accept all changes for purposes of setting the updatde vector
properly, but that S2 does not store or replicate changes not within its
subtree specification. Once again, I don't see this flying.

This suggests that S1 cannot act as a supplier to S2 if the subtree
specifications for S1 and S2 are not the same. That doesn't make sense: if
S1 is a superset of S2, as is the case here, it ought to be able to act as
a supplier, but the current architecture seems to prevent that.

Where next?

I think we need a few things to make overlapping areas of replication work
[or we can disallow it]:

- We need a way to define/identify each of the areas of replication.
replicationContext objectclass doesn't cut it if two areas can have the
same root. Subtree specification as part of a subentry (as opposed to a
referenced specification) pretty much makes each subentry its own area of
replication, which might simplify to "no replication". A separate object,
as you suggest, seems to make the most sense.

- We need a way to associate an update vector with each area of
replication, where two areas of replication rooted at the same entry
requires two update vectors. Update vectors are an attribute of
replicaSubentries. I don't see anything in InfoMod which would prevent
there being multiple subentries representing the same physical server, so
one solution would be to create separate replica subentries for each area
of replication that a server participates in.

John McMeeking

"Ed Reed"
<eer@OnCallDBA. To: <[email protected]>, <[email protected]>
COM> cc: <[email protected]>
Sent by: owner- Subject: RE: Replica Management - subtreespecification attribute
ietf-ldup@mail.
imc.org

02/26/2002 09:04
AM

I can't tell if concensus was reached on this or not, so I'll bring it up
again...

The purpose of placing the subtree specification, along with other scoping
information, onto the replicaSubentry was precisely to create a single
entry
that would define the replication context.

The purpose of allowing additional scoping information to refine what is
to be passed along certain replicationAgreements between particular
replicas was to control the flow of changes across certain links in the
replica topology. By refinement, I mean further contraint.
ReplicaAgreements
inherit, by subordination in the namespace, the knowledge about
what entries and attributes are contained in the replica they're
subordinate
to, and to which they refer (by the very DN syntax method you suggest).

If my proposed model of name subordination is abandoned for
replicaAgreements,
then of course, there will need to be a DN reference to the second endpoint
of
the replicaAgreement association (falling into DEN-eese, here). Or to all
of them,
if it's to be multivalued.

Tim - have we decided to move away from hierarchical subentries, so as to
more completely and "purely" embrace the X.501 subentry syntax?

If so, you'll wind up with a "bag" of replicaSubentries, together with a
"bag"
of replicationAgreements, all necessarily shared/known by all replicas,
with
some arbitrary graph where replicaSubentries are nodes of the graph and
replicationAgreements are the edges. It will then be encombant on
administrators (and their tools) to ensure that the graph remains
connected,
that there are no black holes (replicaSubentries which are updateable but
have no outbound path of propagating changes to others), etc. In
otherwords,
that there remains a "correct" graph, for some definition of "correct".

I must say I dislike designs that place the responsibility for insuring
"correct"
deployment on the administrators. I much prefer designs which create
systems that are correct to begin with, and that can then be broken, if
necessary, with enough mule-headed persistance of those administrators.

Anyway.

Rick - I think your desire for an entry, somewhere, that describes the
replication context (scope) that will be shared by all the
replicaSubentries
(and possibly refined by them) is a good one. In the absense of a
"primary"
replica (my preferred method of solving this problem), I suggest that a
subentry be defined that explicitly is used to designate the anchor point
for the ldup administrative area that coincides with the replication
context.

For clarity, here, I reproduce from memory what I mean by those words...

A replication context is a partion of the DIT for which there are one or
more replicas. Each replica is represented by a replicationSubentry
immediately subordinate to the base entry of the replication context.
Replicas of the replication context may be full or partial. If they are
administratively constrained to hold less than the full replication context
(ie, all the entries and all their attributes in the partion of the DIT
represented by the replication context), the refinements (constraints)
for each replica are represented by filters on the respective
replicaSubentry
for that replica. Note that I'm explicitly using terminology here to
preclude the notion that a replica holds MORE than ALL the entries
and attributes of the DIT, because that seems nonsensical. The data in the
DIT is the data in the DIT.

(Aside - if the replica context EXPLICITLY
lists the entries or attributes, by including filters in its very
definition, then
it is effectively PROHIBITING subordinate replicas from holding information
not permitted in those filters. On the other hand, if it's not prohibited,
as would be the case when there are no filters on the replica context
definition, then subordinate replicas MIGHT define schema elements
locally that THEY can hold, but which cannot be held by other replicas
unless the changes to the schema can be propagated via LDUP - which
may or may not be possible, depending on the replication agreements
and constraints defined on those other replicas).

As aluded to, above, replicationAgreements, which document the
dataflow between replicas, may themselves have constraints as to
the entries and/or attributes which may be passed across them. Again,
though, those constraints, if present, cannot by definition exceed the
set of entries and attributes permitted by replica context definition
(however
it is represented). So, again, if the replica context definition is
permissive,
subordinate replicas and their replicationAgreements can create local
extensions of the schema they share among themselves. But if
explicitly defined through constraints, the replica context schema
definition
cannot be expanded upon in ways to permit in a replica or
replicationAgreement
what is prohibited by the replica context definition.

Make sense?

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

>>> "Steven Legg" <[email protected]> 01/28/02 11:45PM >>>

Rick,

Richard V Huber wrote:
> We noted in a previous email that, to allow overlapping areas of
> replication, we feel that an area of replication is defined by a
> replicaSubentry. The replicaSubentry defines the boundary of the area
> via the subtreespecification attribute.

Note that a subtree specification identifies a collection of entries,
but not a subset of the attributes within them. That is, it specifies the
sparseness of a partial replica. Something else in addition to the subtree
specification is required to specify the fractionalness of a partial
replica,
i.e. the attributeExclusionFilter and attributeInclusionFilter attributes.

Regarding terminology, you appear to be using "area of replication" to mean
some part, possibly but not necessarily all, of the information in a
replication
context. Thus a single replication context can have more than one area
of replication within its scope. This is what I assume it means, however
areas of replication (a.k.a replication areas) are not defined in the
architecture and model drafts and tend to be used as synonyms for
"replication context".

> Because a subtreespecification may need to be shared across a
> number of
> subentries (e.g. all the replicaSubentries that refer to a common area
> of replication), we would like to have a single subtreespecification
> that can be referenced from multiple subentries. Accordingly, we
> would like to change the subentry objectclass to use
> subtreeSpecificationDN and allow the subtree specification to
> be stored
> as a separate entry which can be referenced as needed.

This separate (sub?)entry would contain the attributeExclusionFilter and
attributeInclusionFilter attributes as well.

An alternative to a subtreeSpecificationDN attribute would be to place
the replica subentries subordinate to the (sub)entry describing their
area of replication.

Either way, I would support making such a change to the information model.

Regards,
Steven

>
> This may be useful in other cases where a single subtreespecification
> needs to be used consistently in several places.
>nis effectively PROHIBITING subordinate r
> Rick Huber
> John McMeeking
> Ryan Moats
>

graycol.gif (image/gif, 105 B) - not displayed

ecblank.gif (image/gif, 45 B) - not displayed