Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!umich!samsung!brutus.cs.uiuc.edu!psuvax1!psuvm!BITNIC!ROBINSON
From: ROBINSON@BITNIC.BITNET (Andrew T. Robinson)
Newsgroups: bit.listserv.policy-l
Subject: Topologies
Message-ID: <POLICY-L%90021123410983@BITNIC.BITNET>
Date: 12 Feb 90 04:24:34 GMT
Sender: Discussion about BITNET policies <POLICY-L@BITNIC>
Reply-To: Discussion about BITNET policies <POLICY-L@BITNIC>
Lines: 24
Approved: NETNEWS@PSUVM Gateway
In-Reply-To:  Your subject -- Re: A new LISTSERV

Valdis,

You miss the point.  LISTSERV tries to implement routing on top of
routing.  Ideally, a LISTSERV-type server would run at every site,
eliminating the need for "smart" routing within the LISTSERV "network."
The servers could take advantage of the local node's routing tables
to perform distributions, knowing only adjacencies and how nodes are
routed through the adjacencies (I assume here that the BITNET table
generation method is effective enough so the server does not need to
second-guess routing descisions).

As it stands now, LISTSERV compensates for its lack of portability
by producing what amount to its own routing tables:  It determines the
topologically "closest" LISTSERV server for distribution purposes.
This can lead to conflicts if an alternate routing generator is used
for BITNET routes as opposed to LISTSERV routes--a point you raised
in an earlier posting.  In addition, it introduces an extra level of
overhead and programming complexity to LISTSERV which have little to
do with its intended role.

The idea that BITNET routing descisions should be tied to LISTSERV is
very bothersome to me--kind of a tail-wagging-the-dog situation.

Andy