2.1.9 LDAP Duplication/Replication/Update Protocols (ldup)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-02-12

Chair(s):
Chris Apple <capple@dsi-consulting.net>
John Strassner <john.strassner@intelliden.com>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>
Applications Area Advisor:
Patrik Faltstrom <paf@cisco.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. Therefore, this group will 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.

The WG's approach is 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 are the domain of other working groups.

The new replication architecture support 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

Engineering Team discussions, each leading to one or more documents to be published:

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 Mandatory Replica Management

Specifications required to allow 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 LDAPv3 Profiles

Including the LDAPv3 Replication Architecture, Information Model, Protocol Extensions, and Update Reconciliation Procedures for:

+ LDAPv3 Master-Slave Directory Replication

+ LDAPv3 Multi-Master Directory Replication

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 content.

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 perspective.

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.
JAN 01  LDAPv3 Directory Replication Requirements I-D goes to WG Last Call as Informational.
JAN 01  LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call as Proposed Standard.
Done  Submit I-D on LDAPv3 Mandatory Replica Management.
MAR 01  Submit I-D on LDAPv3 Multi-Master Replication Profile.
MAR 01  Submit I-D on LDAPv3 Master-Slave Replication Profile.Submit I-D on LDAPv3 Master-Slave Replication Profile.
APR 01  LDAPv3 Replication Information Model I-D goes to WG Last Call as Proposed Standard.
APR 01  LDAPv3 Replication Architecture I-D goes to WG Last Call as Informational.
APR 01  LDAPv3 Subentry Schema goes to WG Last Call (joint with LDAPEXT) as Proposed Standard.
JUN 01  LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed Standard
JUN 01  LDAPv3 Replication Information Transport Protocol I-D goes to WG Last Call as Proposed Standard.
AUG 01  LDAPv3 Extended Operations for Framing I-D goes to WG Last Call as Proposed Standard.
DEC 01  LDAPv3 Mandatory Replica Management I-D goes to WG Last Call as Proposed Standard.
DEC 01  LDAPv3 Multi-Master Replication Profile I-D goes to WG Last Call as Proposed Standard.
DEC 01  LDAPv3 Master-Slave Replication Profile I-D goes t WG Last Call as Proposed Standard.
DEC 01  Reevaluate Charter and Milestones
Internet-Drafts:
  • - draft-ietf-ldup-urp-07.txt
  • - draft-ietf-ldup-model-08.txt
  • - draft-ietf-ldup-infomod-06.txt
  • - draft-ietf-ldup-protocol-04.txt
  • - draft-ietf-ldup-usage-profile-04.txt
  • - draft-ietf-ldup-lcup-04.txt
  • - draft-ietf-ldup-mrm-02.txt
  • Request For Comments:
    RFCStatusTitle
    RFC3384 I LDAPv3 Replication Requirements

    Current Meeting Report

    See text below.
    
    Chris Apple - Principal Architect
    
    DSI Consulting, Inc.
    
    mailto:capple@dsi-consulting.net
    
    http://www.dsi-consulting.com
    
    
    ========================================
    =================================
    
    LDAP Duplication/Replication/Update Protocols WG (ldup)
    
    Tuesday, March 18 at 1300-1400
    
    ===============================
    
    CHAIRS:	Chris Apple <capple@dsi-consulting.net>
    	John Strassner <john.strassner@intelliden.com> 
    
    Minutes taken by:  John Strassner
    
    The meeting was run according to the posted agenda. The meeting minutes 
    therefore mirror the agenda topics.
    
    1. Consensus on a path to conclude - Chris Apple reporting
    
    It was obvious from the last meeting that we weren't going to be able to 
    achieve consensus to produce standards-based documents for all of the work 
    that is listed in our current charter. After an email exchange, 
    consensus was reached that the working group would try and move all 
    documents forward on an experimental path. The one exception to this is the 
    LCUP document,  which is targeted at the standards track.
    
    There were no comments to this presentation.
    
    2. Status of various documents.
    
    2a. LDAP Client Update Protocol - Rich Megginson reporting
    
    The URL for this is:
    
    
    http://www.ietf.org/internet-drafts/draf
    t-ietf-ldup-lcup-04.txt
    
    Rich opined that the draft is good as is and ready to be released, with the 
    one exception that Kurt Zeilenga and John Young are not happy with the 
    draft. Kurt has posted a counter draft, called LDAP Content Sync, 
    available at the following URL:
    
    
    http://www.ietf.org/internet-drafts/draf
    t-zeilenga-ldup-sync-01.txt
    
    First, it should be noted that the two drafts have moved closer to 
    agreement. However, there are still significant differences between these 
    two drafts, and the nature of the disputes are fundamental to the design of 
    each. The disputes boil down to three points of contention.
    
    The first point of contention is that while both protocols 
    synchronize directory information, LCUP operates within the user 
    information model, while LDAP Content Sync operates within the system 
    information model. An example of a 
    facsimileTelephoneNumber implemented as a virtual or a collective 
    attribute was used. The difference between how the two protocols operate for 
    this example is two-fold:
    
    LCUP provides the changed data, LDAP Content Sync doesn't.
    
    LCUP causes every entry with the collective attribute definition to be 
    reported as modified (which could in turn cause a large number of 
    entries to be returned to the client), while LDAP Content Sync only 
    returns one entry.  The difference in the above is that with LCUP, the 
    client doesn't need to know the details of the physical information 
    model, whereas with LDAP Content Sync, the client must know the details of 
    the physical information model.
     
    The second area of difference is that LCUP requires history to be 
    maintained, while LDAP Content Sync doesn't.
    
    LCUP sends one entry because it has historical data present; LDAP 
    Content Sync sends the full requested entry if modified, or sends the DN or 
    UUID of the entry for unchanged entries.  This means that the client is 
    responsible for deleting entries from its local store that are not 
    returned. This in turn means that if there are N entries in the result set 
    of the search, modifying one value will cause N messages to be sent.
    
    The final major difference is that in LCUP, changes to meta data, as well as 
    subtree operations may either cause the client to resync, or to send a 
    large  number of messages.  This is because LCUP assumes that these 
    operations are very infrequent and therefore relatively 
    inexpensive.  LDAP Content Sync doesn't have this side-effect because it 
    always sends a message for every entry.
    
    Kurt stated that as designed, LCUP doesn't meet the needs of OpenLDAP. Rich 
    stated that the issues that Kurt is raising are beyond the original 
    design scope of LCUP.
    
    The co-chairs recommended two action items, which were accepted by the 
    meeting attendees:
    
    1) Rich and Kurt should meet and try and resolve their differences by COB 
    Friday this week. If their differences can't be resolved, then they 
    should report that to the working group.
    
    2) Both drafts will need applicability statements added if they want to be 
    progressed.
    
    The co-chairs will propose a recommended course of action based on the 
    results of the meeting of Rich and Kurt.
    
    2b. LDUP Update Reconciliation Procedures - Steven Legg reporting
    
    The URL for this is:
    
      
    http://www.ietf.org/internet-drafts/dra
    ft-ietf-ldup-urp-07.txt
    
    Steven reported that there are no technical changes to this document; it was 
    reissued to avoid becoming obsolete. Some minor work needs to be done to 
    update references, and then it is ready to go.
    
    2c. LDAP Replication Architecture - Chris Apple reporting
                                        for Uppili Srinivasan
    
    The URL for this is:
    
      
    http://www.ietf.org/internet-drafts/dra
    ft-ietf-ldup-model-08.txt
    
    Chris reported that there are no technical changes to this document; it was 
    reissued to avoid becoming obsolete. Ed Reed is retiring as an author from 
    this effort, but John Merrells and Gerry Maziarski have both 
    volunteered to help. While the document is ready from the 
    point-of-view of the LDUP requirements and the Mandatory Replica 
    documents, it still has references to many issues that are outside the 
    scope of LDUP as it is currently defined. Examples of this include access 
    control and the administration model. Thus, the plans for finishing this 
    document are to first ensure consistency with other LDUP documents, then to 
    excise these other issues, and finally to do one last pass before a last 
    call.
    	
    2d. LDUP Replication Information Model - Chris Apple reporting
                                             on behalf of the authors
    
    The URL for this is:
    
      
    http://www.ietf.org/internet-drafts/dra
    ft-ietf-ldup-infomod-06.txt
    
    This is an important draft, especially because many other documents 
    depend  on it. An update for it is promised by mid to late April.  The 
    current update  was done to avoid it expiring.
    
    2e. The LDUP Replication Update Protocol - Chris Apple reporting
                                               on behalf of the authors
    
    The URL for this is:
    
      
    http://www.ietf.org/internet-drafts/dra
    ft-ietf-ldup-protocol-04.txt
    
    Chris reported that there are no technical changes to this document; it was 
    reissued to avoid becoming obsolete. It is in good shape for being 
    released. 
    
    Two actions need to be taken before that can happen:
    
    1) Document Editor needs to complete search of mail archives to ensure that 
    no open issues exist (currently doesn't believe that any exist).
    
    2) Changes to other LDUP docs that affect this document will of course 
    cause it to change; we'll need to see if any such changes happen or not.
    
    2f. General Usage Profile for LDAPv3 Replication - Chris Apple 
    reporting
                                                       on behalf of the 
    authors
    
    The URL for this is:
    
      
    http://www.ietf.org/internet-drafts/dra
    ft-ietf-ldup-usage-profile-04.txt
    
    Chris reported that there are no technical changes to this document; it was  
    reissued to avoid becoming obsolete.  The co-chairs would like to see 
    comments on this document.  One thing to think about as you comment is 
    whether this profile is sufficient, or whether the single- and 
    multi-master replication profiles are still needed.
    
    2g.  Mandatory LDAP Replica Management - Chris Apple reporting
                                             on behalf of the co-authors
    
    The URL for this is:
    
      
    http://www.ietf.org/internet-drafts/dra
    ft-ietf-ldup-mrm-02.txt
    
    This draft is dependent on the information model, and can't really be 
    updated until the Information Model is updated. It will be turned around as 
    quick as possible once this is done.
    
    3. WG Charter Revision/Review
    
    The only thing that has changed so far was the milestones. This is 
    because we have established consensus on a path to conclude our work. If the 
    co-chairs detect that there is significant slippage in these dates, then the 
    co-chairs will most likely recommend that the working group conclude 
    immediately.
    
    We need to discuss on the mailing list whether we need to keep the 
    single- and multi-master profiles in the charter, or whether the general 
    usage profile is sufficient.
    
    Kurt expressed concern over the charter wording, and would like to see  
    "re-evaluate" changed to "conclude." Chris responded that in the past, the 
    use of "conclude" was discouraged by the ADs.
    
    4. Next steps
    
    Chris will revise the charter posting.
    
    The LCUP gang will get together with Kurt and report progress (or lack 
    thereof) to the WG by this Friday (3/21).
    
    Information model draft needs to be discussed and revised as soon as 
    possible.
    
    End of meeting.
    

    Slides

    Selected LDUP Documents Status
    LDAP Replication Architecture