comments.long-bud-intro-01.txt

[Allan Cargille <[e-mail]>]

draft-ietf-mhsds-long-bud-intro-01.txt                Kevin E. Jordan

                  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.
>>> Break, indent, or wrap text. 
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.''
>>> Break, indent, or wrap text. 
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.

....

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.
>>> Break, indent, or wrap text. 
In the MHS infrastructure, as compared to other protocols, a name
does not contain enough information to impose to the Message
Transfer Agents (MTAs) a route to be taken to reach 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.
>>> Break, indent, or wrap text. 
An MHS community gathers 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:  August 1994          [Page 2]



INTERNET-DRAFT     Introducing Project Long Bud     March 24, 1994


   * Manual propagation and installation of routing tables do not
     guarantee consistency of routing information (even in a
     loosely 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
managers will be released from configuring connections to the
other participants.
>>> Break, indent, or wrap text. 
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.

....

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.
>>> Break, indent, or wrap text. 
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.
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.

....

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.
>>> insert blank line
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.

....

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.
>>> Break, indent, or wrap text. 
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
scalability which it is currently encountering.

....

      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.
>>> insert blank line
      3. If not already done, participants must upgrade their
         X.400 and X.500 software to a level which conforms to,
         at least, [Kille 94].

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
         directory-capable MTA involved in the pilot.  At this
         stage, only connection information is required.
>>> insert blank line
      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.
>>> insert blank line
      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.


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


INTERNET-DRAFT     Introducing Project Long Bud     March 24, 1994


      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.  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 one of:
>>>      ^^^^^^^^^^^ one of what? 3 or 4?  If so...  renumber 3 to 3a
and 4 to 3b and 5 to 4 and change to "one of 3a or 3b"
>>> also, insert blank line
      3. 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
         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.
>>> insert blank line
      4. 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.

      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.
>>> Break, indent, or wrap text. 
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, ...).



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


INTERNET-DRAFT     Introducing Project Long Bud     March 24, 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.
>>> insert blank line
>>> This is now v06, but it should be published as an RFC very soon
(prior to this document).  Current date is Oct 1993.

....

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]
>>> insert blank line
James A. Romaguera
NetConsult AG
Mettlenwaldweg 20a
3037 Herrenschwanden, Switzerland
Phone:  [phone]
Email:  [e-mail]
X.400:  S=Romaguera;O=NetConsult;P=switch;A=arcom;C=ch