draft-ietf-mhsds-long-bud-intro-02.txt for comments

[Sylvain Langlois <[e-mail]>]

You will find enclosed a new version of the LongBud Pilot Project
Introduction. Please note that this draft is an updated version of the
Internet draft (version 01) which was discussed at last IETF meeting in
Seattle but was not widely distributed.

Comments are welcome. A PostScript version is also available upon
request. Both versions (txt and ps) will be put on the MHS-DS
repository soon.

MHS-DS Working Group                             Harald T. Alvestrand
INTERNET-DRAFT                                                UNINETT
draft-ietf-mhsds-long-bud-intro-02.txt                Kevin E. Jordan
Expires:  December 1994                          Control Data Systems
                                                     Sylvain Langlois
                                                Electricite de France
                                                   James A. Romaguera
                                                           NetConsult
                                                        June 29, 1994

                  Introducing Project Long Bud:

   Internet Pilot Project for the Deployment of X.500 Directory
             Information in Support of X.400 Routing



Status of this Memo
This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups.  Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months.  Internet-Drafts may be updated, replaced, or obsoleted
by other documents at any time.  It is not appropriate to use
Internet-Drafts as reference material or to cite them other than
as a ``working draft'' or ``work in progress.''
To learn the current status of any Internet-Draft, please check
the 1id-abstracts.txt listing contained in the Internet-Drafts
Shadow Directories on ds.internic.net, nic.nordu.net,
ftp.isi.edu, or munnari.oz.au.

Abstract
The Internet X.400 community (i.e.  GO-MHS) currently lacks a
distributed mechanism providing dynamic updating and management
of message routing information.  The IETF MHS-DS Working Group
has specified an approach for X.400 Message Handling Systems to
perform message routing using OSI Directory Services.  The MHS-DS
approach has been successfully tested in a number of local
environments.  This INTERNET-DRAFT  describes a proposed Internet
Pilot Project that seeks to prove the MHS-DS approach on a larger
scale.  The results of this pilot will then be used to draw up
recommendations for a global deployment.



INTERNET-DRAFT     Introducing Project Long Bud      June 29, 1994


1 Background

The 1988 edition of X.400 introduces, among other extensions or
revisions, the concept of O/R Names which assumes the existence
of a widely available Directory Service.  This Directory Service
is needed to support several MHS operations (support for names to
identify senders and receivers of messages in a user-friendly
fashion, support for distribution lists, authentication of MHS
components, description of MHS components capabilities...).

The prime advantage of Directory Names, as perceived by many
users, was to release users from the remembering of complex O/R
Addresses for their correspondents.
In the MHS infrastructure, as compared to other protocols, a name
by itself does not contain enough information to allow the
Message Transfer Agents (MTAs) to route a message to the User
Agent (UA) servicing this name.  The routing process is based on
information provided by different MHS Management Domains, whether
they are public or private.
An MHS community combines several administrative MHS domains
among which agreements for cooperative routing exist:  the GO-MHS
community is the set of MTA's taking care of X.400 mail
operations on the Internet [Hagens et al.  93].

In the absence of a distributed Directory Service, an interim
technique has been developed within the GO-MHS community to
collect and advertise routing information.  This resulted in an
experimental protocol specification published as [RFC 1465].


2 Rationale

A number of routing problems are preventing the present Internet
X.400 service from expanding its number of participating message
transfer agents to a global scale.  The two most critical
problems are:

   * The present mechanism of centrally maintained and advertized
     MTA routing tables has been optimized as far as possible.
     Increasing the number of directly connected MTAs increases
     also the workload on the MHS managers.  The current solution
     does not scale.  Routing must be a fully dynamic and
     distributed process.



Alvestrand et al.         Expires:  December 1994         [Page 2]



INTERNET-DRAFT     Introducing Project Long Bud      June 29, 1994


   * Manual propagation and installation of routing tables do not
     guarantee consistency of routing information (even in a
     loose fashion) when it is accessed by different MTAs
     scattered across the globe.

It is commonly accepted that a distributed mechanism providing
for dynamic updating and management of X.400 routing information
is highly desirable.  The focus of the project is to establish
X.500-based support of X.400 routing, at a very large scale.


3 Benefits


Using the Directory as a dynamic means of information storage and
advertisement will guarantee participants in Project Long Bud
that their updated data are globally available to the community.
As a direct consequence of the above, a participating MHS manager
will be released from configuring connections to the other
participants.
Directory-capable MTAs will be able to discover more optimal and
more direct routes to X.400 destinations than are practical
today.  This will enable faster delivery of messages.

The infrastructure reliability will be improved:  the information
stored in the Directory will allow automatic use of backup
connections in case of remote MTA or network problems.
X.400 mail managers in the GO-MHS Community should then be
released from the need to know the complexity of the whole mail
routing infrastructure.  Providing a dynamic routing
infrastructure will eliminate inconsistencies introduced by
unsynchronized static tables and improve quality of service.
Furthermore, besides the robustness and the optimization of the
new routing infrastructure, the Long Bud approach should bring to
the participating organizations better control over how they
establish and maintain their interconnection with the GO-MHS
community.

Participants will share in building an X.400 network which can
expand to a very large scale.  They will collect early know-how
about a global messaging architecture which scales well and needs
minimal administrative overhead.  They will be able to discuss
experience with the MHS-DS experts and architects in the
development stage.


Alvestrand et al.         Expires:  December 1994         [Page 3]



INTERNET-DRAFT     Introducing Project Long Bud      June 29, 1994


4 Definition of project LONG BUD

The Long Bud pilot wishes to demonstrate that the X.500 Directory
is able to provide a global-scale service to messaging
applications.

Although MHS-DS provides ways to use private routing trees, Long
Bud will focus on the Open Community Routing Tree as used by the
GO-MHS community.

4.1 Project Goals

Project Long Bud has the following goals:

   * Gather pilot experience of the defined framework for X.500
     support of MTA routing, as defined by the IETF MHS-DS
     Working Group [Kille 92].

   * Actively investigate migration of the existing operational
     X.400 service from a routing method based upon distribution
     of centrally maintained static tables, as specified in
     [RFC 1465], to a method based instead upon X.500:

      -- Deploy X.400 MTAs which are directly capable of reading
         routing information from the X.500 Directory, in
         compliance with the specifications of the MHS-DS Working
         Group.  This type of MTA is called a directory-capable
         MTA.
      -- Deploy tools which read routing information from the
         X.500 Directory and use it to generate static routing
         tables for MTAs which are not directory-capable.

   * specify a set of minimal operational requirements needed
     before X.500-based routing of X.400 messages can be widely
     deployed.


4.2 Phasing

The first phase of Project Long Bud consists in deploying a small
number of directory-capable MTAs operated by members of the
MHS-DS Working Group and GO-MHS community.  These MTAs must be
capable of using information in the X.500 directory to route
messages to all other members of the project as well as to the


Alvestrand et al.         Expires:  December 1994         [Page 4]



INTERNET-DRAFT     Introducing Project Long Bud      June 29, 1994


existing GO-MHS community.  As of this writing, an initial set of
MTAs is already operational.

At the end of this phase, the following goals should be achieved:

   * The X.500 DIT must be populated with enough routing
     information to allow the participating MTAs to route
     reliably messages to each other and to the existing GO-MHS
     community.
   * The X.500 DSAs holding the routing information must operate
     at a quality of service that is acceptable for an
     operational X.400 service.

As a prerequisite, a sufficient number of MTA managers must be
willing to participate in Project Long Bud for the first set of
results to be significant.  Support for a protocol stack
conforming to [RFC 1006] is mandatory.  All MTAs participating in
the Long Bud pilot need to register in the Open Tree and must be
prepared to accept connections from anyone.

Note that in the first phase, default routes will be established
in the DIT such that messages addressed to destinations outside
of the Long Bud community will be routed to designated MTAs in
the GO-MHS community.  This will allow for full connectivity
between the Long Bud community and the GO-MHS community which are
separate communities.  Interworking between these two must be
decided and established.
In the second phase of Project Long Bud, a greater number of MTAs
should be added to the experiment.  Cooperation with non
directory-capable communities must be addressed.


4.3 General Approach

No large scale resources have been committed to this project.
Yet, expedient deployment is desirable.  Therefore, the pilot
project needs to be focused and relatively short-lived.  The
general approach for satisfying these requirements includes:

   * Use as many existing MHS-DS tools as possible.  Also,
     continue to track the progress of tools being developed by
     project members and facilitate their deployment as soon as
     they are ready.
   * Coordinate efforts with existing GO-MHS community service.


Alvestrand et al.         Expires:  December 1994         [Page 5]



INTERNET-DRAFT     Introducing Project Long Bud      June 29, 1994


   * Establish a core infrastructure:  4 DSAs (two in the United
     States and two in Europe) are set up to serve MHS-DS
     information.

   * Wherever it is technically feasable, DSA managers will
     establish bilateral agreements with one (or more) of the
     core DSAs in order to duplicate their routing information.
     For example, the core DSAs support the replication protocol
     specified in [RFC 1275] as a duplication technique.

   * the Long Bud pilot needs to cooperate actively with DANTE
     NameFlow (the continuation of the PARADISE Pilot) and other
     directory providers in order to promote stability.

4.4 Tools Needed

To facilitate widespread deployment of MHS-DS routing technology
and to foster interworking between directory-capable MTAs and
MTAs which are not directory-capable, tools providing the
following functionality need to be developed:

populate the Directory with routing information :  such a tool
     must accept routing information, specified in the standard
     syntax used by the GO-MHS community (see [RFC 1465]) as
     input, and it will load or update entries which convey the
     same information in the X.500 Directory.

downloading of routing information from the Directory :  in order
     to provide a migration path for organizations not using
     directory-capable MTAs, a tool is needed which will read
     X.400 routing information from the X.500 Directory and
     generate static routing information from it.  The syntax of
     the static information generated will conform to the syntax
     defined by the GO-MHS community, so that ``classical'' MTAs
     run as they currently do.

displaying route taken by a message between two end-points :
     this tool should accept two parameters as input:  the X.500
     distinguished name of an MTA, and an X.400 O/R name.  It
     will display the possible routes which may be taken in order
     to deliver a message from the specified MTA to the specified
     X.400 destination.  This tool looks very much the same as
     the traceroute facility used at the IP level.



Alvestrand et al.         Expires:  December 1994         [Page 6]



INTERNET-DRAFT     Introducing Project Long Bud      June 29, 1994


These tools should be implemented using Internet standard APIs
such as LDAP so that they can be ported easily to multiple
platforms.  Other standard APIs (e.g.  X/Open XDS) will be used
when sufficiently deployed in the Internet community.


A note on quality

Pilot use of this Directory information depends heavily on data
quality and availability.  Although the administration of DSA
availability and global Directory data accuracy are not in the
scope of Long Bud, care must be taken that Directory resources
used by Long Bud participants are administrated well.
The currently proposed solution to improve data availability is
to advise Long Bud participants to create a web of bilateral
agreements for replicating data.
Directory data used by the pilot must be accurate:  the pilot
must be able to propose solutions to this problem in its own
context.


5 Participation Guide


The existing operational X.400 service, the GO-MHS service, uses
the following method to distribute and manage X.400 routing
information.
A group of MTAs is organized into a routing community.  The
community keeps its routing information up to date by assigning
to each MTA manager the responsibility of determining the routing
information for his/her MTA, formalizing this routing information
in the syntax defined by the community and sending the result to
the GO-MHS coordination service.  Once the information has been
validated against the other data provided by all managers in the
community, the coordination service will advertize it to the
whole community.  Each manager will then have to update his/her
MTA configuration with the verified information.
The purpose of Project Long Bud is to allow a manager to operate
an MTA without having to perform ANY manual steps when another
MTA manager adds new or changes existing routing information.
This will facilitate efficient, dynamic, and manageable
interconnection of very large communities of MTAs.  It will allow
the Internet X.400 community to overcome the limitations in



Alvestrand et al.         Expires:  December 1994         [Page 7]



INTERNET-DRAFT     Introducing Project Long Bud      June 29, 1994


scalability which it is currently encountering.


5.1 Prerequisites for participation

The prerequisites for joining Project Long Bud are:

Step 1 :  participants in the pilot must have a good knowledge of
     the IETF MHS-DS Working Group activities and documents:

      1. Participants must join the MHS-DS distribution list:

              RFC-822:  [e-mail]

                X.400:  PN=mhs-ds; OU=mercury; OU=OSS;

                        OU=ARH; O=CPG; P=CDC; A=ATTMail; C=US


         Requests to join the MHS-DS distribution list may be
         sent to the following email address:

             RFC-822:  [e-mail]

               X.400:  PN=mhs-ds-request; OU=mercury; OU=OSS;

                       OU=ARH; O=CPG; P=CDC; A=ATTMail; C=US


      2. Participants must retrieve and become familiar with all
         relevant tools and documents stored on the Project Long
         Bud anonymous FTP server

                      Host name:  ftp.css.cdc.com

                      Directory:  pub/mhs-ds/long-bud

         In particular, openly available software related to Long
         Bud activities will be kept up-to-date at this location.

      3. If not already done, participants must do one of:
           * Upgrade their X.400 and X.500 software such taht it
             supports the MHS-DS specifications as in [Kille 92].



Alvestrand et al.         Expires:  December 1994         [Page 8]



INTERNET-DRAFT     Introducing Project Long Bud      June 29, 1994


           * Use the tools which extract MHS-DS information from
             the directory and generate whatever local
             configuration files are necessary to allow local
             MTA's to use the information.  This should be done
             frequently (at least once per day).

Step 2 :  participants must register required entries in the
     Directory so that their MTA(s) is (are) known to the
     Directory.

      1. arrange with the appropriate DSA Manager (who can be a
         local manager if the DSA is run by the participating
         organization, or a manager who is in charge of running
         the organization's DSA) to create an entry for the local
         MTA(s) involved in the pilot.  At this stage, only
         connection information is required.
      2. Check, test and verify the connection information with
         at least one other participant.  The mhs-ds distribution
         list should be used for announcing the new registration
         and asking volunteers for testing.

      3. Participants must establish sensible default X.400
         routes to existing GO-MHS destinations for which
         X.500-based routing information will not exist
         initially.
Step 3 :  participants can then enter their routing information
     in the Directory.

      1. Before any routing is entered in the DIT, participants
         must check with the GO-MHS Coordination Service that the
         routes they want to register can be properly handled by
         the GO-MHS community.  RFC-1465 format is used for this
         purpose.  It is crucial for the Pilot that any routing
         information entered in the Directory is kept carefully
         accurate if the experiment is to be meaningful.

      2. Once the above step is validated by the GO-MHS
         Coordination Service, participants must record routing
         information for their MTA(s) in the Internet X.500
         directory service.  This requires that a participant
         does the following:
           * Arrange with the appropriate DSA Manager (who can be
             either a local manager if the DSA is run by the
             participating organization or a manager which is in


Alvestrand et al.         Expires:  December 1994         [Page 9]



INTERNET-DRAFT     Introducing Project Long Bud      June 29, 1994


             charge of running the organization's DSA) to enter
             X.400 routing information in a routing tree held by
             the participating organization.  This routing tree
             should contain all necessary information for the
             local mail domain.
           * Check, test and verify the registered routing
             information with at least one other participant.  The
             mhs-ds distribution list should be used for
             announcing the new registration and asking volunteers
             for testing.

      3. If a participant adds new nonleaf entries to the Open
         Community Routing Tree, then s/he must find at least one
         other participant who will maintain a slave copy of the
         children of the nonleaf entry.  Send email to the mhs-ds
         distribution list in order to find a partner who is
         willing to do this.
      4. If a participant adds new nonleaf ADMD or PRMD entries
         to the directory, then s/he must contact the managers of
         the Long Bud core DSA's and arrange to provide slave
         copies of the children of the ADMD and/or PRMD entries
         to all of the core DSA's.  Send email to the mhs-ds
         distribution list in order to contact the core DSA
         managers.
      5. Once the above testing is completed, send email to the
         mhs-ds distribution list announcing the establishment of
         new X.500-based routes.


6 Notes on side effects

The Long Bud Pilot Project, with its specific scope, is
investigating a new direction in X.500 service usage.  This
should facilitate and expedite the global deployment of X.500 on
the Internet.

Once the routing infrastructure illustrated by the Long Bud
experiment is in place, the routing process will be able to take
into account additional information to improve quality of service
(minimizing messages conversions, enforcing various security
policies established by MHS domains, taking advantage of
recipients's capabilities stored in the Directory, ...).
While the Open Tree provides global connectivity, multiple
private routing trees allow the use of various routing trees.


Alvestrand et al.        Expires:  December 1994         [Page 10]



INTERNET-DRAFT     Introducing Project Long Bud      June 29, 1994


7 Acknowledgements

The authors would like to thank Urs Eppenberger (SWITCH) for his
sharp but constructive comments on earlier drafts of this
document.


References


[Hagens et al. 93]  R.A. Hagens and A. Hansen. Operational
                    Requirements for X.400 Management Domains in
                    the GO-MHS Community. X400-OPS Internet-Draft
                    draft-ietf-x400ops-mgtdomains-ops-05.txt
                    (working draft). March 1993.
[Kille 92]          S.E. Kille. MHS use of Directory to support
                    MHS routing. MHS-DS Internet-Draft
                    draft-ietf-mhsds-routedirectory-03.txt
                    (working draft). July 1993.

[RFC 1006]          Marshall T. Rose and Dwight E. Cass ISO
                    Transport services on top of the TCP. Request
                    for Comments 1006, May 1987.

[RFC 1275]          S.E.  Hardcastle-Kille. Replication
                    Requirements to provide an Internet Directory
                    using X.500. Request for Comments
                    1275,November 1991.
[RFC 1465]          U. Eppenberger. Routing Coordination for
                    X.400 MHS Services Within a Multi Protocol /
                    Multi Network Environment Table Format V3 for
                    Static Routing. May 1993.


8 Security Considerations


Security Considerations are not discussed in this INTERNET-DRAFT.


Author's Address

Harald T. Alvestrand
UNINETT


Alvestrand et al.        Expires:  December 1994         [Page 11]



INTERNET-DRAFT     Introducing Project Long Bud      June 29, 1994


P.O. box 6883 Elgeseter
N-7002 Trondheim, Norway
Phone:  [phone]
E-mail:  [e-mail]

Kevin E. Jordan
Control Data Systems, Inc.
4201 Lexington Avenue North
Arden Hills, MN 55126, USA
Phone:  [phone]
Email:  [e-mail]
Sylvain Langlois
Electricite de France
Direction des Etudes et Recherches
1, avenue du General de Gaulle
92141 Clamart Cedex, France
Phone:  [phone]
E-Mail:  Sylvain [e-mail]
James A. Romaguera
NetConsult AG
Morgenstrasse 129 3018 Bern, Switzerland
Phone:  [phone]
Email:  [e-mail]
X.400:  S=Romaguera;O=NetConsult;P=switch;A=arcom;C=ch






















Alvestrand et al.        Expires:  December 1994         [Page 12]

Sylvain

----------------
Sylvain Langlois
([e-mail])