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.
- unavailable X.400 routing entries in the COSINE-M… Urs Eppenberger
- Re: unavailable X.400 routing entries in the COSI… Ignacio Martinez
- Re: unavailable X.400 routing entries in the COSI… Allan Cargille
- Re: unavailable X.400 routing entries in the COSI… Urs Eppenberger
- Re: unavailable X.400 routing entries in the COSI… (Tony Genovese)
- Re: unavailable X.400 routing entries in the COSI… Allan Cargille