RE: naming contexts

Actually, I accept that example as support of at least part of my position - as you said, AD does single master for the creation and deletion of naming/replication contexts.  After that you may well be able to treat the topology information as multimaster...inspection (and time) will tell.  It's certainly worth trying.

Ed

>>> "Don Hacherl" <[email protected]> 12/06/01 03:04PM >>>
I'd offer a counter example.  Active Directory in Windows 2000 manages the replication topology in a distributed manner, with each DSA independently computing a fraction of the total replication topology such that the (overlapping) fractions together form a single connected replication network.  AD does single master the creation and deletion of naming/replication contexts, but once an NC exists on one DSA its replication topology (as well as all the data in the NC itself) is fully multi-master.

Don Hacherl

-----Original Message-----
From: Ed Reed [mailto:[email protected]] 
Sent: Thursday, December 06, 2001 11:03 AM
To: [email protected]; [email protected] 
Subject: RE: naming contexts



Yeah - there are those that believe they can manage the replication toplogy
information without resorting to using the Primary as the single-master for
replica topology information - I'm not one of them.  The draft verbage
invites those who think they can to actively participate in the management
operations draft work that Ryan and others are working on...

So, I'm trying not to impose the limits of my understanding on others...and
to leave the door open to other approaches...I simply don't have a clue as
to how to make those other approaches work.

The one I understand how to do is to designate one of the replicas as the
Primary replica, and to REQUIRE all replica topology information changes to
be made AT THE PRIMARY and to then allow the Primary to shadow that
replica toplogy information to those servers that have a replicaSubentry.

This approach admittedly presumes that the primary replica OWNS the
replica toplogy information, and in turn might be considered to be the
owner of all the data in the replication area of the DIT.  That later is 
subject to much more discussion, but it's a useful simplification.

That notion of ownership returns the X.500 notion of Master as Owner
of data to the multi-master model (and is why I've always used the
term "updateable" where others insist on using "master").  If there is
a "master" in the X.500 sense of the word...owning the data...that
would be the "primary" replica.  Other updateable replicas hold copies
that may be changed by users, but the data owner could still be viewed
as the primary replica.

What's nice about this approach is that it explicitly identifies who gets
to decide whether a new replica will be allowed to be added to the topology -
the primary replica does.  I think that ability to constrain who may
begin replicating an area is an important defense against trawling for
data, and from denial of service attacks that create replicas and then
destroy them willy-nilly (attack:  while (true) {add replica; replicate
knowledge of the new replica to everyone else so they add the replica
to their update vector and purge vector arrays; take the replica off line
without removing its information from the replica toplogy on all the other
servers so they can never purge themselves};)

This is an architypical case where even with a multi-master system, there
are still appropriate places where individual applications can and should
be able to  choose to cooperate by using the multimaster directory in
a single-master fashion for their own data - in this case, the application is
LDUP, and the data are the replica toplogy information.  Other applications
may similarly choose to do so, and the primary replica, used by LDUP
in this instance to designate the "chosen" replica that is to be used to
coordinate (strictly serialize) updates to its data, may be similarly used
by those other applications, though they could also use some other
mechanism to select their application-specific "single master".

Ed

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

>>> "Timothy Hahn" <[email protected]> 12/06/01 10:58AM >>>
Ed,

Yes, but the explanation in the DRAFT for this attribute is MUCH LESS 
restrictive than what you have been implying.

There are indications that NO Primary replica need exist, it need NOT be 
the same for different replication contexts, and even that MULTIPLE 
primary replicas might exist.  Thus, I have not interpreted the meaning of 
replicaType=Primary to be as "strong" as was implied in earlier postings 
on this thread.

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





"Ed Reed" <[email protected]>
12/06/2001 12:15 PM

 
        To:     <[email protected]>, Timothy Hahn/Endicott/IBM@IBMUS
        cc: 
        Subject:        RE: naming contexts

 

Tim - from the currently posted draft...

8.2.8. replicaType 
 
   (2.16.840.1.113719.1.142.4.4 NAME 'replicaType' 
      DESC 'Enum: 0-reserved, 1-Primary, 2-Updateable, 
            3-ReadOnly, all others reserved' 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 
      EQUALITY integerMatch 
      SINGLE-VALUE 
      NO-USER-MODIFICATION 
      USAGE dSAOperation ) 
 
   ReplicaType is a simple enumeration, used to identify what kind of 
   replica is being described in a Replica object entry.

It is replicaType 1-Primary that I'm speaking of.

Ed

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

>>> "Timothy Hahn" <[email protected]> 12/06/01 09:42AM >>>
Ed,

In its current state, the information model does not yet contain 
indicators of "primary master".  I believe we are, currently, requiring 
that IF replicaSubentry information is entered at different server 
instances, that it WILL be entered consistently with respect to what was 
entered on the other server instances.  If not, then results are 
indeterminant.  If so, then the two servers will "synchronize".

Either that or we were thinking that the "initial set of replicaSubEntry" 
information would be entered on ONE OF the servers" and then replicated to 

(and so be consistent) with the OTHER servers that were referenced.  The 
idea being that no SINGLE server is noted as "primary master" - just that 
ONE server is used to enter the "initial settings".

This is what I recall anyway,
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





"Ed Reed" <[email protected]>
Sent by: o should
be able to  choose to [email protected] 
12/06/2001 10:35 AM

 
        To:     <[email protected]>, <[email protected]>, 
<[email protected]>
        cc: 
        Subject:        RE: naming contexts

 


1) I'm pleased to see Kurt referring to a "Primary Master", as I think 
such a concept is needed to represent the single-master of replica 
topology information about a replication context.  However,

2) I agree with Steven that what becomes interesting in a multi-master 
environment is the replication context, not the naming context, held by a 
server.  Frankly, in the mostly-distributed directories I've worked with, 
replication contexts were all that were available, since they're more 
informative about what is actually held, allow clients to piece together a 

minimal set of servers needed to fully traverse a distinguished name when 
searching for a named entry, etc.

But here the interesting point - there IS a place for a "Primary Master" 
when you ABSOLUTELY NEED some data in the DIT to be single-mastered, even 
if the rest of the data can be multi-mastered.  In my example 1 above, 
those data are the operational attributes and subentries associated with 
the definition, description and management of a replication area.

Thus, the Model (Architecture) document and, I think, the Information 
Model, still retain the Primary master replica type, even if the 
requirements document has dropped it.

One fine point, though - I don't know how to represent nor manage a 
scenario where DIFFERENT DATA are "owned" by different PRIMARY MASTER 
replicas in the same replication area...I know how to deal and manage 
having a single replica designated as the primary of all the masters, but 
not how to tag ownership of specific schema elements. 

So, the information model places the replica type designation on the 
replicaSubentry, and only one replica of the replication area is deemed to 

be the "primary master" of the replication context.

Ed

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

>>> "Steven Legg" <[email protected]> 12/06/01 02:35AM >>>


Kurt,

> It seems to me that the definition of a "naming context"
> in LDAP/X.500 makes little sense in the face of multi-master
> replication.  A LDAP/X.500 naming context is subtree of
> entries held in a single master DSA.
>
> Consider three DSAs A, B, C where
>                A masters subtree X
>                B masters subtree Y
>                C masters subtrees X and Y, and
>                Subtrees X and Y are adjacent.

>From what follows, I assume that Y is subordinate to X.

> If A and B are masters and C is a shadow of each,
> LDAP/X.500 says that
>                A holds context X, B holds context Y, and
>                C holds contexts X and Y.

C holds a shadow copy of contexts X and Y.

> If C masters X and Y and A and B are shadows,
> LDAP/X.500 says that:
>                A, B, C holds context X

C holds context X, which is now the union of the subtrees X and Y,
i.e. there is no longer a context Y. A holds a shadow copy of a
portion (subtree X) of context X. B holds a shadow copy of a different
portion (subtree Y) of context X.
>
> If A, B, and C master the subtrees they hold, which
> contexts does LDUP say they hold?

Having an entry mastered by more that one master DSA doesn't invalidate
the definition of naming context as far as I can see, but we do need
to be a bit more careful how we phrase things.

A holds a naming context with the context prefix being the root of the
subtree X. B holds a naming context with the context prefix being the
root of the subtree Y. C holds a naming context with the context prefix
being the root of subtree X, the same root as A but with a superset of the
entries. Off the top of my head I can't think of anything that is broken
because A and C have the same context prefix but unequal sets of entries
in their naming contexts.

For LDUP we're okay if we say we are replicating "replication contexts"
rather than "naming contexts". C can be said to hold two adjacent
replication
contexts (for subtree X and subtree Y).

>
> I can only find one reasonable way to answer this question,
> it requires each entry to have held by one and only one
> "primary" master DSA and defining the LDUP naming context
> as a subtree of entries held in a single "primary" master
> DSA.  I believe this same solution can be used to define
> other terms and to detail directory models for multi-master
> replication which maps reasonable well onto the X.500 models.a

I don't think we need impose this restriction for
what is only a definitional problem.

>
> I recommend the WG consider defining the LDUP multi-master
> replication directory models such that, for any particular
> entry, there is only one "primary" master DSA and zero or
> more "secondary" master DSAs.   Otherwise, defining the
> models consistent with the LDAP/X.500 models will be
> extremely difficult.

Regards,
Steven