unavailable X.400 routing entries in the COSINE-MHS community

Urs Eppenberger <Eppenberger@switch.ch> Thu, 18 March 1993 08:16 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02023; 18 Mar 93 3:16 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02019; 18 Mar 93 3:16 EST
Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa01320; 18 Mar 93 3:16 EST
X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Thu, 18 Mar 1993 01:47:47 +0000
Date: Thu, 18 Mar 1993 01:47:47 +0000
X400-Originator: cargille@cs.wisc.edu
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=XNREN/ADMD= /C=US/; mhs-relay..766:18.02.93.07.47.47]
Priority: Non-Urgent
DL-Expansion-History: ietf-osi-x400ops@cs.wisc.edu ; Thu, 18 Mar 1993 01:47:46 +0000;
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Urs Eppenberger <Eppenberger@switch.ch>
Message-ID: <1194*/S=Eppenberger/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS>
To: rd-mhs-managers <rd-mhs-managers@chx400.switch.ch>
Cc: ietf-osi-x400ops <ietf-osi-x400ops@cs.wisc.edu>
Subject: unavailable X.400 routing entries in the COSINE-MHS community

Tony does not give up as easy, and he is right ;-)
We had a lengthy discussion on several aspects of this problem at the last
MHS Managers meeting in Zurich, I might even say that most of the agenda
items tried to attack one or the other aspect of this problem. It has also
been discussed on the mhs-managers list on initiatives from Ingacio for
example. The waves have calmed down with most managers shrugging their
shoulders since no obvious solution was handy.

Problem statement:
  There are at least two ways for non routable X.400 addresses to creep
  into our network:
  - on secondary recipient fields
  - as result of mapping
  This is increasingly hampering our service!

For most addresses a route can be found:
- in the COSINE-MHS domain documents
- through the ADMD backbone
- gatewaying into Internet


o If the software allows to check all possibilities first and then decide
  which 'channels' to use, then you have at least the technical possibility
  to do it. (PP as for 6.0 has a serious problem there since it decides on 
  the protocol first, but I do not want to discuss PP problems here.)

o An algorith for the routing has been proposed, but it is of little use
  since there is no software supporting it yet.
  a) check X.400 routing, (either in the X.500 routing tree or in the
     static tables) if there is a usable route.
  b) if a) did not work, then check for an MX record in DNS
  c) if b) did not work, send a non-delivery report back

  This works only if the routing decisions are done on a gateway. You can
  easily run into loops if the main routing hub is X.400 and you just have
  a 'default' route to the gateway.

Most of you will detect from this scribbling above, that I'm certainly not
wiser (on this issue ;-)) than you are.
Would it be appropriate to use the next IETF x400ops meeting to stick our
heads together and try to find something really working, easily manageable,
automatically updateable, self learning, self healing, ...
(Most IP routers do not know the whole world, but they have ways to find
 it out where to send their packets. Can we copy something from there? Ok,
 we probably do not need BGP4.)


Kind regards,

Urs Eppenberger, SWITCH, MHS Coordination Service

PS: if it gets an item for the x400ops meeting, then please let's move the
    discussion to the x400ops list.