RFC 1802 (rfc1802) - Page 3 of 11

Introducing Project Long Bud: Internet Pilot Project for the Deployment of X

RFC 1802              Introducing Project Long Bud             June 1995


   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 develop experience using a global
   messaging architecture which scales well and requires minimal
   administrative overhead.  They will be able to discuss experience
   with the MHS-DS experts and architects in the ongoing standards
   development cycle.

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 94].

   * 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:





Alvestrand, et al            Informational