Subject: operations that cross areas of replication

From: "John McMeeking" <[email-masked]>
Date: Wed, 28 Mar 2001 15:13:19 -0600

At the last IETF LDAP WG I raised a question about how a given server knows
what the bounds of an area of replication are, and how LDUP should behave
in cases where an operation crosses those boundaries.  Any given server may
not know what other areas of replication exist (the boundaries) and thus a
client could do things like create an entry that conflicted with the root
of another area of replication on another server, or delete the parent of
an area of replication.  These can result in areas of replication getting
renamed, moved into lost and found, etc., when replicated, which seemed
undesirable.

I have a possible solution for this problem.  First, to restate the
problem[s]:

If an area of replication has nested areas of replication, and a given
replica contains the parent area of replication, but does not contain all
of the nested areas, that replica does not know the bounds of the area of
replication.  This can give rise to situations where a client does
something on that replica that affects the other areas of replication.

There are two variants of this problem:
1.  There is no server which contains both the parent and child areas of
replication.
2.  The parent area of replication is present on at least one server that
also contains the nested areas of replication.
In some sense both of these are "broke" without replication.  A DIT that
has been distributed across servers ought to have within it knowledge of
the entire DIT.

One approach to this problem is to define referrals representing the roots
of the areas of replication that are not present on a server.  In variant
1, this can be accomplished by an administrator creating the appropriate
referral entries to link the directories/DIT.  Variant 2 cannot be
addressed in quite this fashion; there would exist two conflicting
definitions of the areas of replication root entries which could be
replicated to the same servers; one entry being the true entry, the other
entry being a referral.

A related question is whether LDUP supports (should support?) renaming
entries which are roots or parents of areas of replication.  I do not
believe that LDUP can handle this situation properly in all circumstances.
LDUP replication identifies the root of the area of replication as part of
the StartReplicationRequest operation.  If an area of replication is
renamed, what DN should be specified?    The new name will not be
recognized by other replicas, which suggests the old name be used.  In the
face of both supplier and consumer initiated replication, it implies that
any server that has received the change must be able to handle replication
under either name for some period of time.  This is not unsolvable by any
means, but I think it would be much cleaner to disallow any operation which
has the effect of renaming an area of replication, moving it into lost and
found, etc..

Here is the solution I propose:

If a server has knowledge of nested areas of replication that are not
present on that server, it can behave appropriately, by failing a client a
request that might otherwise have been allowed, returning a referral, etc..
Any one server has knowledge of all areas of replication present on that
server.  Suppose we define an operational attribute of the replicaSubEntry
objectclass, areasOfReplication, that identifies the areas of replication
present on that server.  This operational attribute is replicated to other
servers via LDUP (replicaSubentry is replicated?).  Every server that has a
replica of a given area of replication thus has knowledge of all other
areas of replication in the replica group.  A server can now fail or refer
operations which reference non-present areas of replication: add, delete,
and modRdn/Dn operations fail, search or modify operations can return a
referral.  CSNs for this operational attribute are generated like any other
CSN based on the addition or removal of areas of replication, with the
possible restriction that this be replicated as delete attribute/add
attribute value primitive pair, similar to a modify-replace.  The attribute
may have to be replicated each time a server is started; if a server is
restored to an ealier state, assuming the clock is set properly, this will
ensure that other servers are properly informed.

By way of example:

DIT:

            AR1
             |
       ---------------
       |             |
      AR2           AR3
                     |
                    AR4

Servers and replicas they hold:

S1: AR1, AR2, and AR3
S2: AR1, AR2
S3: AR3, AR4

replicaSubEntries would have the following "otherAreasOfReplication"
values:

   naming convention: Sx-ARy = replica subentry for server x in area of
replication y

DN: S1-AR1,-AR2,-AR3
areasOfReplication:
   AR1
   AR2
   AR3

DN: S2-AR1,2
areasOfReplication:
   AR1
   AR2

DN: S3-AR3,4
areasOfReplication:
   AR3
   AR4

- S1 knows about AR1,2,3 since they are present on the server.  From S2-AR3
it learns about AR4.
- S2 knows about AR1,2 since they are present on the server.  From S1-AR1
(or AR2) it learns about AR3 and 4.
- S3 knows about AR3,4 since they are present on the server.  From S1-AR3
it learns about AR1 and 2.

This allows a server to learn what other areas of replication are
"reachable" via replication of a area of replication present on that
server.  It is done automatically via LDUP.  No administrative action is
required to set this up or ensure that referrals remain correct as replicas
and areas of replication are added and removed.

Also, using this attribute to populate the root DSE altServer attribute
would be helpful to a replication management app, or to clients that need
to direct all requests to one server (it might be able to find one).  The
server could use the areasOfReplication information to generate better
referrals.

John  McMeeking, IBM
OS/400 Directory Services
[email-masked]