headers
John Merrells | 6 Jan 1999 00:35
Picon

Re: Affect on client/server interactions


Mike_Spreitzer.PARC <at> xerox.com wrote:
> 
> The possibility of conflicts and resolutions may affect the applications (LDAP
> clients and whatnot).  I can imagine at least four positions on this issue; the
> requirements and architecture drafts should explicitly say which is taken.
> 
> 1.  Completely unmodified clients and users.  Clients use "plain" LDAPv3, and
> nothing else, to access the data.  Users use only these plain clients.

There will be no new client access protocol. Clients will not be able to
influence conflict resolution. LDUP will define one and only one resolution
algorithm.

John
Permalink | Reply | 0 comments |
headers
John Merrells | 6 Jan 1999 00:48
Picon

Re: Replication agreements between partial replicas


Mike_Spreitzer.PARC <at> xerox.com wrote:
> 
> Wouldn't the replication relationships of partial replicas need to be
> restricted, to cases where the consumer is strictly "more partial" (i.e., holds
> a subset of the entries, and a subset of the attributes) than the supplier?

Yes, each replication agreement can only define a replication area 'equal to'
or 'more partial than' the supplier replica. So, a supplier will not pass
through more data than it itself holds. I see that the architecture document
doesn't explicitly state this condition. Perhaps Sections 8.3.1 'Full Update
Transfer' and 8.3.2 'Incremental Update Transfer' should state that the entry
and attribute filters are applied to each update so that partial replicas
receive no more data than specified by the replication agreement.

John
Permalink | Reply | 0 comments |
headers
John Merrells | 6 Jan 1999 01:13
Picon

Re: Out-of-order and partial propagation


Mike_Spreitzer.PARC <at> xerox.com wrote:
> 
> The existing verbiage about these is not specific enough for me to fully
> understand what's being proposed.  A question I ask myself is "what are the
> consistency and closure constraints on what the consumer has accepted?".  That
> is, although the sender may be allowed to send updates out-of-order, and
> transmission is interruptable (whether you explicitly say so or not!), the
> question is: does the consumer simply accept everything it receives, or must it
> (due to various atomicity considerations) either accept or reject received
> updates in some larger batches?
> 
> For example, the verbiage about using update vectors to prune transmission
> suggests the consumer must accept either all or none of the updates with a
> given CSN.  And that the consumer can't accept the updates with a given CSN
> until after it has accepted all the updates with a lesser CSN.  The fact that
> these can be spread across the entire data space suggests to me that the
> consumer can't actually accept any updates unless and until it has received all
> the updates the provider has to send.

The consumer may apply the updates as they are received, even through they
are out of order. Should the replication session be interrupted, and restarted,
then the supplier will begin resending the same set of updates. Because the
updates are idempotent reapplying the same updates will have no effect.

John
Permalink | Reply | 0 comments |
headers
Alan Lloyd | 13 Jan 1999 02:32
Picon

comments on multi master replication proposals

Dear all, some comments.

As an intro though there are a number of ways of achieving multimaster
operation.

One approach is "N*N protocol modify/interaction approach and to label
every attribute value in the system with unique Ids/CSNs and testing
these in time and space to see what is the best and latest update when
the specialised protocols are received..

The other is a system approach which does not pollute DIT operations and
adds nothing at the directory entry level - (ie. almost (slightly
upgraded) standard DSAs can be used for replicas) . This approach
nominates a master node which has all of the DIT or a master portion of
the DIT for which it is responsible for.  All updates in the system are
(via LDAP, DAP, DSP) directed to that node by other replica DSAs, and
then the master nodepropogates this to its secondary (replicas).
Primary, secondary and tertiary masters (alternate DSAs) can be
nominated to support fail over of the master, etc.

In the first case  problems encountered at the entry attribute/protocol
level of the system and the complexity grows on an N*N fashion.
N=updateoperations*number of nodes....ie. it can become unworkable - and
specialised DSAs must be used everywhere.

In the second case a nominated master is responsible for broadcast mode
of operation. All total failures and recovery processes can be handled
"out of band". Note: These recovery processes will also be required for
the first case also.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robertson, Tony | 14 Jan 1999 04:04
Picon
Picon

RE: comments on multi master replication proposals

Alan,
	I would like to respond to some of your comments on multi
master replication.
You have some general comments, as well as some issues with
"the MM proposal". I assume you mean the proposals as
represented by the following draft internet documents, and related
discussions on this mailing list.
  draft-merrells-ldup-model-01.txt (replication architecture)
  draft-reed-ldup-infomod-00.txt (replication information model)
  draft-legg-ldup-crp-00.txt (update reconciliation procedures)

Alan.Lloyd <at> OpenDirectory.com.au wrote:
> As an intro though there are a number of ways of achieving multimaster
> operation.
> 
> One approach is "N*N protocol modify/interaction approach and to label
> every attribute value in the system with unique Ids/CSNs and testing
> these in time and space to see what is the best and latest update when
> the specialised protocols are received..
> 
> The other is a system approach which does not pollute DIT operations and
> adds nothing at the directory entry level - (ie. almost (slightly
> upgraded) standard DSAs can be used for replicas) . This approach
> nominates a master node which has all of the DIT or a master portion of
> the DIT for which it is responsible for.  All updates in the system are
> (via LDAP, DAP, DSP) directed to that node by other replica DSAs, and
> then the master nodepropogates this to its secondary (replicas).
> Primary, secondary and tertiary masters (alternate DSAs) can be
> nominated to support fail over of the master, etc.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Lloyd | 14 Jan 1999 06:24
Picon

RE: comments on multi master replication proposals

Thanks for that. Comments in line.

> -----Original Message-----
> From:	Robertson, Tony [SMTP:TRoberts <at> vtrlmel1.telstra.com.au]
> Sent:	Thursday, 14 January 1999 14:04
> To:	'ietf-ldup <at> imc.org'
> Subject:	RE: comments on multi master replication proposals
> 
> Alan,
> 	I would like to respond to some of your comments on multi
> master replication.
> You have some general comments, as well as some issues with
> "the MM proposal". I assume you mean the proposals as
> represented by the following draft internet documents, and related
> discussions on this mailing list.
>   draft-merrells-ldup-model-01.txt (replication architecture)
>   draft-reed-ldup-infomod-00.txt (replication information model)
>   draft-legg-ldup-crp-00.txt (update reconciliation procedures)
> 
> Alan.Lloyd <at> OpenDirectory.com.au wrote:
> > As an intro though there are a number of ways of achieving
> multimaster
> > operation.
> > 
> > One approach is "N*N protocol modify/interaction approach and to
> label
> > every attribute value in the system with unique Ids/CSNs and testing
> > these in time and space to see what is the best and latest update
> when
> > the specialised protocols are received..
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robertson, Tony | 15 Jan 1999 04:28
Picon
Picon

RE: comments on multi master replication proposals

Hi Alan,

	....
> > Alan.Lloyd <at> OpenDirectory.com.au wrote:
> > > As an intro though there are a number of ways of achieving
> > multimaster
> > > operation.
> > > 
> > > One approach is "N*N protocol modify/interaction approach and to
> > label
> > > every attribute value in the system with unique Ids/CSNs and testing
> > > these in time and space to see what is the best and latest update
> > when
> > > the specialised protocols are received..
> > > 
> > > The other is a system approach which does not pollute DIT operations
> > and
> > > adds nothing at the directory entry level - (ie. almost (slightly
> > > upgraded) standard DSAs can be used for replicas) . This approach
> > > nominates a master node which has all of the DIT or a master portion
> > of
> > > the DIT for which it is responsible for.  All updates in the system
> > are
> > > (via LDAP, DAP, DSP) directed to that node by other replica DSAs,
> > and
> > > then the master nodepropogates this to its secondary (replicas).
> > > Primary, secondary and tertiary masters (alternate DSAs) can be
> > > nominated to support fail over of the master, etc.
> > > 
> > > In the first case  problems encountered at the entry
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Lloyd | 15 Jan 1999 05:29
Picon

RE: comments on multi master replication proposals


> -----Original Message-----
> From:	Robertson, Tony 
> Sent:	Friday, January 15, 1999 2:29 PM
> To:	'ietf-ldup <at> imc.org'; Alan Lloyd
> Subject:	RE: comments on multi master replication proposals
> 
> Hi Alan,
> 
> 	....
> > > Alan.Lloyd <at> OpenDirectory.com.au wrote:
> > > > As an intro though there are a number of ways of achieving
> > > multimaster
> > > > operation.
> > > > 
> > > > One approach is "N*N protocol modify/interaction approach and to
> > > label
> > > > every attribute value in the system with unique Ids/CSNs and
> testing
> > > > these in time and space to see what is the best and latest
> update
> > > when
> > > > the specialised protocols are received..
> > > > 
> > > > The other is a system approach which does not pollute DIT
> operations
> > > and
> > > > adds nothing at the directory entry level - (ie. almost
> (slightly
> > > > upgraded) standard DSAs can be used for replicas) . This
(Continue reading)

Permalink | Reply | 4 comments |
headers
Robertson, Tony | 15 Jan 1999 07:20
Picon
Picon

RE^4: multi master replication proposals

Alan,

	[...cut ... cut...]
> > If you want a failover or contingency model to work without requiring
> > administrator intervention on re-connection, then you still need
> > a set of conflict resolution rules very similar to what the current
> > proposal has.
> 	[Alan Lloyd]  However, out of band conflict resolution and
> reconciliation does not rely in millisecond resoultion and clock
> syncronisation across servers which can be globally dispersed.
[Tony Robertson]
The current proposal also does not require clock synchronisation or
millisecond resolution.

> 	On this point, I did work in Europe on multi nodal systems that
> required i) a system wide unique clock with a resolution of 2
> milliseconds (although it operated in microseconds) and ii) the
> guarantee that any transaction being processed in any node was not
> stamped with the same system time. This involved a system clock concept,
> resource locks, clock recovery and management processes and 50 megabits
> of glass. This was needed in order to comply with financial transaction
> rules in multi node systems.
> 
> 	If one percieves that directories are emerging as the
> information infrastucture to many systems including that of banking and
> defence command and control systems, then the grade of multi node/multi
> mastering has to be high. The model proposed just cannot guarentee such
> quality with just a "directory" protocol.
[Tony Robertson]
I think we can agree that the directory protocols, both current and
(Continue reading)

Permalink | Reply | 0 comments |
headers
List Manager of ietf-ldup | 15 Jan 1999 17:43
Picon

How to be removed from this list

Greetings again. Occasionally, people will sign up for a mailing list and
forget how to be removed. This message is a reminder for those folks.

First off, when you subscribe to a mailing list, you almost always get a
first message from the list owner telling you about the mailing list, and
explaining how to unsubscribe. It is always a good idea to keep those
messages, since you never know when you will need to unsubscribe. This is
particularly useful when you change email addresses, because it is difficult
to unsubscribe from a list after you have a different mailing address.

In the case of this list, the method to unsubscribe is to send a message
to:
     ietf-ldup-request <at> imc.org
with the single word:
     unsubscribe
in the body of the message. This is the same as it always has been.

To make this easier for you, I have crafted this message so that you should
be able to simply reply to this message, and the reply address should be
ietf-ldup-request <at> imc.org (although some mail clients screw this up...).
Remove everything from the body of the reply, and put in the single word:
     unsubscribe

If you have tried this method, and the mailing list software won't let you
unsubscribe, it is probably because your address has changed. In that case,
please send a message to subs <at> imc.org stating which list (or lists) you
want to unsubscribe from, and what you think your previous address was.
There is a human (that's me!) who will then try to take care of your
request, often within a few days.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane