RE: Comments on ldup-replica-req-00.txt

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

John - first I apologise for my sad humour - I have been told by many
that it needs some attention. :-({

> -----Original Message-----
> From:	John Merrells [SMTP:merrells@xxxxxxxxxxxx]
> Sent:	Wednesday, April 22, 1998 4:56 AM
> To:	Alan Lloyd
> Cc:	ietf-ldup@xxxxxxx
> Subject:	Re: Comments on ldup-replica-req-00.txt
> 
> Alan Lloyd wrote:
> 
> >         Of course - its just that these servers just become "normal"
> > users of the directory that must be authenticated and if one changes
> the
> > credentials of a server in one server - how does that get into the
> > second - unless servers need to use their old credentials depending
> if
> > they have replicated them or not... is this chicken and egg stuff.
> 
> That hasn't been raised as a requirement either.  An administrator's
> intention may indeed be to permanently or temporarily deny access to
> some other server.  In any case, the administrators should sort it
> out.
> 
	Thats good but the point should go in the spec.


> > > >         Does this mean changes to the LDAP RFC?
> > >
> > > Probably, in the form of new controls, and possibly extended
> > > operations.
> > >
> > > >         You see replication needs to be initated by either
> server
> > > and
> > > > replicas transferred in either direction so its either a
> > > bi-directional
> > > > LDAP server to server with transaction control and server based
> > > > management and a lot of Gods help (this is not a religious
> statement
> > > > ;-))
> > >
> > > It could be a session in each direction.
> >         With God in most cases it seems to be simplex - but I
> realise it
> > is bothways with LDAP :-) see above.
> 
> Alan, you've lost me with the God acronym.
> 
	Its not an an acronym - and I pray for forgiveness :-(

> An LDAP Replication session could be implemented as one bi-directional
> session, or two uni-directional sessions.
> 
> >         Protocol fields  are easy to
> > write down . eg ip6 address is just 16 bytes - now try and deploy it
> and
> > make it work as a global network.
> 
> Um, LDAP Replication might require some extra controls to definethe
> start and end of a replcation session.
> 
	Well yes that is one way - but may I suggest that if one starts
with a wooded wheel to build a car - the rest of the car will get worse
not better. This is not meant to be blunt again - but.

	perhaps LDAP replication is not the right thing to do - because
it now needs a lot more on top of it to make it work for replication.
One is starting with the tool. ie. to drill a hole I dont use a saw.
replication requires a protocol which can be processed (or pre
processed) in one lump to see if it can be applied before it is applied.
Perhaps LDAP "transactions" can do that - but we will see.

> >         Want to ask Oracle, Ingres or Sybase about transaction
> locking
> > systems and deadlock issues?
> 
> No, I've got a book all about it.
	teriffic!

> An LDAP Replication protocol specifiction could mandate the use of
> transactions, but it's probably not essential that it does.
> 
> >         If they stay like DISP there is a chance of success - : -)
> ..
> > existance proof is good.
> 
> Is that documented in X.525?
	DISP specification  is - the success parts are usually in
product specs.

> Are there any documents that address using DISP for multi-master
> directory topologies?
> 
	well there a few papers and the discusion is still open. Multi
master again has taken (or bagged) a few issues including the areas
about split entries and that global backbone stuff I did. At the lowest
level multi mastering can be easily achieved with the protocols exitsing
(DISP) or DSP writethrough features with some tweaks to the processing
for updates/deletes and looking for cooperative MM DSAs. Not really
rocket science that one.
	Split entry issues do require some changes to the search results
correlation processing and may be some tweaking to "base object" start
points based on preconfiguration - as one would want to target the
search range more effectively for split entry responses. Thats tuning

	Global Backbone issues as described in the paper - ie. addmd and
prdmd require some radical changes to search algorithms and "modes" of
working processing +
	plus of course the ability to deal with split subordination and
multi homing on superiors
	and some trace info upgrades as defined

> > > So far, no one's suggested this as a requirement.
> > >
> >         May I suggest a feature which.........................
> 
> Are you suggesting identifying an entry as a master/shadow as
> arequirement then?
> 
	Yes - otherwise X.500 will have the advantage or be different.

> > > I'd wonder though... that if your application has real-time
> > > constraints then
> > > you probably don't want to store your data in some loosly
> consistent
> > > store.
> >         X.500 permits inconsistencies - but leaves the ops people to
> > sort that out- but X.500 provides the services to always get the
> master
> > entry just in case the ops people dont make it.
> 
> Who are ops people?
> 
	Those are the guys that design systems and run them from an
operational perspective to provide a service "Operational support
staff".


> 'One of the master copies', seems no better than 'One of the replica
> copies'.
> 
> > > Also... if an entry is mastered by many servers... then you won't
> know
> > > which server holds the 'correct' value anyway.  So it doesn't
> sound
> > > like
> > > this buys you much.
> > >
> >         In X.500 one does via the information being tagged as copies
> > (internally in the DSA because it arrived via DISP) - and with the
> > knowledge information in the replication agreements the replica DSA
> > knows of the master - and the via DSP (distribution again - an LDAP
> > deficiency) I can request of the replica I am connected to to go to
> the
> > master via DSP to get it by specifying Dont Use Copy - all
> seamlessly to
> > the user - you see replication and distribution in X.500 work
> together.
> > In LDAP land all the parts arn't there yet. So replication on its
> own is
> > very limited....
> 
> I think you're missing my point. Which of the master copies is the
> onetrue correct copy? You'll just never know.
	A master copy is that a master copy - if there is two masters
its the ops people that have decided that as well as decided what are
copies. ITs a system design issue that uses technology features like
file systems - if the two masters have different create/modify time then
that is a distinction. However, inreality users will use a copy - demand
a master when required - but if there is two masters its the ops people
that must say that this is the way to go and then manage the consistency
of these. 

> >         through replication agreements and using op attrs.
> >
> >         The replication scaling problem is reduced with distributed
> > directories in the first place.
> 
> Reduced, but not elliminated. Say you have a set of N masters for an
> entry.Each server maintains an increasing counter which is
> used to tag attribute
> values as they're updated.  These tags are then used to determine
> which
> values are communicated to each of its peers. The question is: 'How do
> you avoid each server having to know the highest tag value sent from
> each other server?'  This seems to be the big scalability problem for
> multi-master directories.  How does X.500 solve this?
> 
	see above. I think my statements re replication and distribution
are correct. And one can continually hypothetically imagine replication
scenarios that wont work and all sorts of mechanisms that can be used
and at some point dont scale.

	As said I have seen a number of directory systems designed
around replication only strategies - simply because I believe that the
market push is "replication, replication, replication and replication -
or  the products used dont distribute well (in terms of performance) so
that part gets left behind.
	Then what happens one ends up with a hundred or so replication
agreements between 20 or so DSAs and if one DSA croaks - its 10
agreements that have to be switched - ie. the system design is
unworkable, unscaleable and unnecessary. ie. the last thing you want is
when one thing goes wrong is twelve other things that can go wrong.

	Back to the issue - one cannot visibly add to the schema design
of a directory the tags and counters to deal with this replication
issue. We are looking at systems with 10s of millions of entries in and
interconnected - distributed DSAs. That level of management on the scema
would make the system a mess.
	One has to "internally" tag schema as per X.500 to deal with
copies and secondaries.
	One can define a transaction in LDAP controls - to bound a
replication unit but so what.
	what happens if I bound a set of persistent searches in a
transaction, what happens if i get referrals passed back within a
transaction - see some controls in LDAP wont mix- are inconsistent -
will confuse servers and therefore will be an operational mine field.


	I can only state my beliefs based on 12 years of experience with
directories and 20+ with large scale system designs - using LDAP for
replication just seems one is using a saw to drill a hole.
	The concern - LDAP will end up like a swiss army knife - lots of
options - some you can use sometimes, but watch out if all the
attachments fly open all at once and its in your pocket...

	regards alan

> John
> 
> --
> John Merrells
> Netscape Communications
> Directory Server
> Software Engineer
> 
> http://people.netscape.com/merrells
>