2.1.6 LDAP Duplication/Replication/Update Protocols (ldup)

Last Modified: 2003-06-18

Chris Apple <capple@dsi-consulting.net>
John Strassner <john.strassner@intelliden.com>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Ted Hardie <hardie@qualcomm.com>
Applications Area Advisor:
Ted Hardie <hardie@qualcomm.com>
Mailing Lists:
General Discussion: ietf-ldup@imc.org
To Subscribe: ietf-ldup-request@imc.org
In Body: subscribe
Archive: http://www.imc.org/ietf-ldup/
Description of Working Group:
As LDAPv3 becomes more widely deployed, replication of data
across servers running different implementations becomes an
important part of providing a distributed directory service.
However, the LDAPv3 community, to date, has focused on
standardizing the client-server access protocol. This group
was originally chartered to standardize master-slave and
multi-master LDAPv3 replication as defined below:

o Multi-Master Replication - A replication model where
      entries can be written and updated on any of several
      replica copies, without requiring communication with
      other masters before the write or update is performed.

o Master-Slave, or Single-Master Replication - A replication
      model that assumes only one server, the master, allows
      write access to the replicated data. Note that
      Master-Slave replication can be considered a proper
      subset of multi-master replication.

Recently, the WG established consensus on a change of
direction to pursue publication of a standards track
protocol for LDAPv3 client synchronization, an experimental
LDAPv3 replication protocol, and supporting informational
documents. Thus the new work program is largely the same
as the original work program with one notable exception,
the LDAPv3 replication protocol is intended to be an
experimental rather than a standards track protocol.

The WG's approach was to first develop a set of requirements
for LDAPv3 directory replication and write an applicability
statement defining scenarios on which replication requirements
are based. An engineering team was formed consisting of different
vendors and the co-chairs in order to harmonize the existing
approaches into a single standard approach. All of these have
been accomplished during the pre-working group stage. It should
be noted, however, that replication using heterogeneous servers
is dependent on resolving access control issues, which were
the domain of other working groups. Because the responsible
WG failed to achieve consensus on a standard access control
model for LDAPv3, the LDUP WG formed a design team to explore
the issue of how to address the lack of such a model
in the context of LDAPv3 replication. This design team made
recommendations to the working group. The working group
considered these recommendations and consensus was
established on addressing these recommendations in
the context of revising other working group deliverables
rather than adding new deliverables specific to access
control for replication. Largely because of the lack of
a standard access control model for LDAPv3, the working
group also established consensus on pursuing an experimental
or informational publication path for a majority of working
group documents formerly intended to become proposed standards.

The new replication architecture supports all forms of
replication mentioned above. Seven areas of working group
focus have been identified through LDUP Engineering Team
discussions, each leading to one or more documents to be

o LDAPv3 Replication Architecture

        This documents a general-purpose LDAPv3 replication
        architecture, defines key components of this architecture,
        describes how these key components functionally behave,
        and describes how these components interact with each
        other when in various modes of operation

o LDAPv3 Replication Information Model

        Defines the schema and semantics of information used to
        operate, administer, maintain, and provision replication
        between LDAPv3 servers. Specifically, this document will
        contain common schema specifications intended to
        facilitate interoperable implementations with respect to:

              + replication agreements

              + consistency models

              + replication topologies

              + managing deleted objects and their states

              + administration and management

o LDAPv3 Replication Information Transport Protocol

        LDAPv3 extended operation and control specifications
        required to allow LDAPv3 to be used as the transport
        protocol for information being replicated

o LDAPv3 Replica Management

        Specifications designed to support administration,
        maintenance, and provisioning of replicas and
        replication agreements. These specifications may
        take the form of definitions for LDAPv3 extended
        operations, controls, and/or new schema elements.

o LDAPv3 Update Reconciliation Procedures

        Procedures for detection and resolution of conflicts
        between the state of multiple replicas that contain
        information from the same unit of replication.

o A General Usage Profile of the LDAPv3 Replication Architecture,
      Information Model, Protocol Extensions, and Update

o LDAPv3 Client Update

        A protocol that enables an LDAP client to
        synchronize with the content of a directory
        information tree (DIT) stored by an LDAP server
        and to be notified about the changes to that

The work being done in the LDUP WG should be coordinated
to the closest extent possible with similar work being done
in the ITU. This is necessary both because LDAP depends
on X.500 and because it makes sense from an operational
Goals and Milestones:
Done  Submit I-D on LDAPv3 Directory Replication Requirements.
Done  Submit Internet-Draft on LDAPv3 Replication Information Model
Done  Submit I-D on LDAPv3 Update Reconciliation Procedures.
Done  Revise I-D on LDAPv3 Directory Replication Requirements.
Done  Revise I-D on LDAPv3 Replication Architecture.
Done  Revise I-D on LDAPv3 Replication Information Model.
Done  Submit I-D on LDAPv3 Replication Information Transport Protocol.
Done  Revise I-D on LDAPv3 Replication Architecture.
Done  LDAPv3 Directory Replication Requirements I-D goes to WG Last Call as Informational.
Done  Submit I-D on LDAPv3 Mandatory Replica Management.
Done  Submit I-D on LDAPv3 Replication General Usage Profile
Apr 03  Revise LDAPv3 Replication Information Model I-D
Done  Revise LDAPv3 Client Update Protocol I-D
Done  LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed Standard
May 03  Revise LDAPv3 Update Reconciliation Procedures I-D
May 03  Revise LDAPv3 Replication Architecture I-D
Jun 03  LDAPv3 Replication Information Model I-D goes to WG Last Call as Informational
Jun 03  LDAPv3 Replication Architecture I-D goes to WG Last Call as Informational.
Jun 03  Revise LDAPv3 Replication General Usage Profile I-D
Jul 03  Revise LDAPv3 Replication Information Transport Protocol I-D
Jul 03  Revise LDAPv3 Replica Management I-D
Jul 03  Evaluate Deliverables Status
Aug 03  LDAPv3 Replication Information Transport Protocol I-D goes to WG Last Call as Experimental
Aug 03  LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call as Experimental
Aug 03  LDAPv3 Mandatory Replica Management I-D goes to WG Last Call as Experimental
Sep 03  LDAPv3 Replication General Usage Profile I-D goes to WG Last Call as Informational
  • - draft-ietf-ldup-urp-07.txt
  • - draft-ietf-ldup-model-08.txt
  • - draft-ietf-ldup-infomod-07.txt
  • - draft-ietf-ldup-protocol-04.txt
  • - draft-ietf-ldup-usage-profile-05.txt
  • - draft-ietf-ldup-lcup-06.txt
  • - draft-ietf-ldup-mrm-02.txt
  • Request For Comments:
    LDAPv3 Replication Requirements (RFC 3384) (66871 bytes)

    Current Meeting Report

    15:15.LDAP Duplication/Replication/Update Protocols WG (ldup)
    Tuesday, July 15, at 1300-1400
    CHAIRS:	Chris Apple <capple@dsi-consulting.net> John Strassner 
    Minutes taken by:  John Strassner
    The meeting was run according to the posted agenda. The meeting minutes 
    therefore mirror the agenda topics.
    LDAP Duplication/Replication/Update Protocols WG (ldup)
    Tuesday, July 15 at 1300-1400 
    CHAIRS: Chris Apple <capple@dsi-consulting.net> John Strassner 
    1) Agenda Additions?
    No additions were asked for, so the meeting proceeded according to the 
    2) LCUP WG Last Call & Status 
    No further discussion occurred on this document.
    3) Remaining WG Documents
    InfoMod Draft 
    Rick Huber presented slides describing the progress of this draft. This 
    presentation reflects the new group of authors that are picking up the 
    work. The authors presented a number of questions to the working group 
    involving various attributes defined in the draft. The first was whether the 
    two RootDSA attributes are really useful. They were originally defined to 
    help discovery, but the classes all have unique names, so this need is no 
    longer crucial. Steven Legg proposed removing them, and people in the 
    meeting agreed. No one asked to have them left in the draft. Thus, since the 
    MRM draft will by definition discover any problems with these or other 
    similar attributes not being defined in the draft, it was decided to 
    remove these for the next revision of the draft.
    Other attributes – attributeExclusionFilter, 
    attributeInclusionFilter, secondsToWaitDefault, and 
    secondsToWait2 – were defined as disallowing user modification. This 
    didn’t seem like a good idea, and the working group agreed. The new 
    draft will change this as well.
    The next subject was whether multiple replicas can exist at the same 
    context root (see slide 2 of the presentation). This would facilitate 
    copying replica information. Slide 3 shows an alternative. The working 
    group preferred slide 2.
    General Usage Profile Draft 
    The main work done on this draft since the last meeting was to go 
    through the draft and clean up references. In doing so, two issues arose. 
    The first involved the status of the locate draft. The status on this 
    draft is that it went through Last Call, and was reviewed by the IESG. The 
    IESG had some technical issues with the draft. Bob Morgan will try and 
    update this draft as soon as possible, probably one month from now. Kurt 
    thought that it depended on 2247bis, and that it shouldn’t be 
    normative. Since the Usage Profile is informational, it doesn’t need to be 
    held up by this draft.
    The other problem was a reference to the taxonomy draft. Note that CRISP 
    also has a reference to taxonomy. Roland said that he and Ryan would try and 
    update taxonomy by mid-August. Thus, it was agreed that the reference to 
    locate could be removed, and the authors would wait to see if taxonomy was 
    indeed updated by mid August.
    MRM Draft  
    This draft needs to wait for the InfoMod draft to complete. Then, it can be 
    updated. Kurt was uncomfortable with the word “Mandatory” in the title of 
    the draft because of its implications. It was agreed to change the title to 
    “Replica Management”, but to keep the file name the same for 
    administrative reasons.
    Architecture draft 
    Uppili sent a note to the chairs providing the following status (since he 
    was unable to attend). He will be submitting a draft shortly that in his 
    opinion will be ready for last call. 
    Jerry Maziarsky and Uppili have discussed the following four types of 
    edits that must be fixed before the document is ready for 
    consideration for last call. The first is that the discussions on 
    different deployment configurations (single vs multi-master) and 
    consistency models (synchronous vs asynchronous) should be separated and 
    cleaned up. The second is that the architecture implies that the DITs of 
    replicating directories have to be symmetric, but in actuality only the 
    areas under replication need be.  The third is that the document should 
    include discussion on how nodes are added, deleted or upgraded without 
    adversely affecting total system up-time, since one of the objectives of  
    replication is high availability. The final edit is that they need to 
    clarify whether LDUP scope is only among homogenous DSAs (same vendor) or it 
    supports heterogeneous DSAs (multi-vendor). The authors believe that it is 
    URP Draft 
    The URP Draft is waiting for InfoMod to complete. Then, Steven will check 
    all references and submit the document for final group Last Call.
    URP Draft 
    An update of this draft will be issued shortly.
    4) Any Other Business
    As there was no other business, the meeting 


    Infomod - Attributes