Subject: RE: naming contexts

From: "Ed Reed" <[email-masked]>
Date: Thu, 06 Dec 2001 08:35:51 -0700

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

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

---

From: "Timothy Hahn" <[email-masked]>
Date: Thu, 6 Dec 2001 09:42:36 -0500

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-masked]
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-masked]>
Sent by: [email-masked]
12/06/2001 10:35 AM

        To:     <[email-masked]>, <[email-masked]>, <[email-masked]>
        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

Kurt,

Regards,
Steven

---

From: "Ed Reed" <[email-masked]>
Date: Thu, 06 Dec 2001 09:51:07 -0700

<eer> comments </eer>

=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402

>>> "Kurt D. Zeilenga" <[email-masked]> 12/06/01 08:45AM >>>

>Kurt,
...

>portion (subtree Y) of context X.

Yes,
  A,B,C publishes the name of the vertex of X.

<eer> my interpretation is that yes, A, B, and C all publish X as a 
naming context on their rootDSE.  They also will publish X as a 
repliation context on their rootDSE.  B and C will also publish Y as a
replication context on their rootDSE.  

This example is why I was finally persuaded that naming contexts
are different from replica contexts, and that a different rootDSE
attribute was needed to hold the names of verticies of replication
contexts separately from the names of naming contexts.
</eer>

>entries.

You imply that context prefix information is not replicated
between masters and the definition of a context is local to
each master.

There are three basic ways one could define naming contexts
in face of multi-master replication.
        a) contexts are determined at each master
        b) contexts are determined across all masters
        c) contexts are determined at one master

I note that in single-master replication, naming contexts are
defined consistent with all three.  In multi-master, you need
to choose one.  You appear to choose a), yes?

<eer> My own personal preference is that naming contexts, as I understand
them, are determined for each server, describing the verticies of subtrees
held by that server.

Clearly, at that point, the naming context doesn't describe a vertix in the
DIT, but rather a vertix in a servers DIB.

Knowledge about subordinate subtrees not held locally are defined, in my
world view, in subordinate entries held by servers holding the immediately
superior namespace to the absent subtree.  

In my world view, those subordinate entries are a special type of replica
of the subordinate namespace - they hold only the name of the vertex
of the subordinate namespace and the replicaSubentries for the replication
area that begins at that vertex.  The replicaSubentries contain accessPoint
and replica type attributes for the server that holds each corresponding replica, 
so that a client can pick a replica of the appropriate type.  Alternatively,
if a server is conducting a subtree search for a client encounters one of the
subordinate entries, it can then refer the client to one of the other servers to 
continue the search.

I think this is the "normal" X.500 use of subordinate entries, though I'm fuzzy as
to whether they're simply "glue" entries or "real" entries in the superior
namespace.  I recall being told at one point that the scheme I'm describing
is similar to the one QUIPU used.  Certainly, it's a style of specific subordinate
entries, not nonspecific subordinant entries (NSSE).

The use of replica toplogy information seems useful, to me, as a natural
result of chosing to store the replica topology information in the directory.

I've not tried to be rigorous in my use of terms, here, but rather to convey
a broad impression of what's desireable.  Distributed operations based on
using this in-the-tree replica topology information need to be rigorously
specified, but alas, I know of no LDAP design group chartered to undertake
such an endeavor.

</eer>

>rather than "naming contexts".

Yes, one could consider the X and Y subtrees as "replication contexts".

>C can be said to hold two adjacent replication contexts (for subtree X and subtree Y).

Yes.  One could rephrase the question in terms of replication
contexts, not subtrees.

I think you are saying that where a server masters multiple
adjacent replication contexts, these replication contexts
comprise one naming context on that server.  Yes?

<eer>
yes, because that's our interpretation of what people expect to be told by a server when it is asked about the naming contexts that it holds.  And thus, the additional rootDSE attribute to hold information about the replication contexts it holds, which may well list more vertices than the list of naming contexts it holds.
</eer>

---

From: "Ed Reed" <[email-masked]>
Date: Thu, 06 Dec 2001 10:15:41 -0700

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

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

Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402

Kurt,

Regards,
Steven

---

From: "Timothy Hahn" <[email-masked]>
Date: Thu, 6 Dec 2001 10:58:10 -0500

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

12/06/2001 12:15 PM

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

8.2.8. replicaType 

Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402

Ed,

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

Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402

Kurt,

Regards,
Steven

---

From: "Ed Reed" <[email-masked]>
Date: Thu, 06 Dec 2001 12:02:46 -0700

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

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

Regards,
Tim Hahn

8.2.8. replicaType 

Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402

Ed,

Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402

Kurt,

> replication which maps reasonable well onto the X.500 models.a

Regards,
Steven

---

From: "Ed Reed" <[email-masked]>
Date: Thu, 06 Dec 2001 17:02:54 -0700

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-masked]> 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-masked]] 
Sent: Thursday, December 06, 2001 11:03 AM
To: [email-masked]; [email-masked] 
Subject: RE: naming contexts

Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402

Ed,

Regards,
Tim Hahn

8.2.8. replicaType 

Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402

Ed,

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

Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402

Kurt,

Regards,
Steven

---

From: "Ed Reed" <[email-masked]>
Date: Fri, 07 Dec 2001 19:10:24 -0700

No - I meant replica context.

I'll confess that when I started on LDUP I didn't understand what
naming contexts were, and I frankly thought they were just a list
of all the partitions replicated onto a DSA.  I've since learned
differently, but that confusion led to our initially talking about
naming contexts, and when I finally got it, we changed and
began talking about replication areas and replica contexts.  Some
of the earlier confusion may not have been wrung out of the info
draft, for which I'm sorry.

I'll make a special effort in the next round of doc cleanup to get
the two terms consistently used throughout the docs.

Ed

>>> "Kurt D. Zeilenga" <[email-masked]> 12/07/01 06:06PM >>>
At 02:34 PM 2001-12-07, Ed Reed wrote:
>What do you mean "how"?  I'm just not sure what you're
>asking the docs to describe - I have been assuming that the
>management operations doc would say something like...

LDAP [RFC 2251] says "namingContexts: naming contexts held in
the server. Naming contexts are defined in section 17 of X.501 [6]."

This, IMO, provides an adequate technical specification (the
"how") for the namingContexts attribute.

However, as we've discussed on this list, this definition
is inadequate in the face of LDUP multi-master replication.
Hence, LDUP needs to provide an adequate technical specification
(the "how") for the namingContexts attribute.

Currently, the LDUP Architecture seems to define "naming context"
as:
        A Naming Context is a subtree of entries in the
        Directory Information Tree (DIT).  There may be
        multiple Naming Contexts stored on a single server.
        Naming Contexts are defined in section 17 of [X501].

Though the first sentence I find a little misleading as a
Naming Context is a subtree of entries with very particular
properties, the second sentence indicates that the definition
of naming context is that in section 17 of [X501].  The
document then goes on to define "replication contexts".

The Information Model seems to equate a "naming context"
with a "replication context".

> [lots of stuff about how replication areas are created]

>Also, no server "X" should ACCEPT changes to replica "B" from any server
>"Y" that isn't represented in "X"'s set of replicaSubentries for "B".  The
>special control mentioned above should provide a specially
>access controlled mechanism to "persuade" "X" to receive
>the initial replica topology information about a new replica "B"
>context from the primary replica of the naming context.

Do you mean really mean "naming context" here?