cmf@UNIX.CIS.PITT.EDU (Carl M. Fongheiser) (02/12/90)
Yes, we should be concerned about how these new programs jibe with LSVBITFD.
That's *not* the most critical consideration, however. We need to make sure
that the use of these different route generators throughout BITNET/EARN/NETNORTH
doesn't cause any routing loops. *That* would be a true disaster.
Carl Fongheiser
University of PittsburghGETTES@PUCC.BITNET (Michael R. Gettes) (02/12/90)
On Sun, 11 Feb 90 04:13:19 EST Valdis Kletnieks said: >Will the main proponent of each new routing table generator please tell >me now the routings generated by their program will fit in with the >scheme used by Eric Thomas's LSVBITFD software? It seems to me that >if routing program X and LSVBITFD don't use the same scheme for deciding >'shortest', that we can get inconsistent results. Keep in mind that LISTSERV is simply an application within BITNET that happens to have knowledge about the underlying topology of the network. If LISTSERV makes decisions about LISTSERV traffic routing that are contrary to the physical network, then this is a LISTSERV application problem. Personally, I do not find this to be a concern, LISTSERV is doing a good job of co-relating its logical topology to the physical topology. You have the same problem with CHAT, NETNEWS feeds and various other services on the network. They all have their own view of the network and what they "believe" are the best places for these services. The topology of the network will change, and so these applications may have to change as well. /mrg
ERIC@SEARN.BITNET (Eric Thomas) (02/13/90)
Michael, I think what Valdis meant is this: if a new algorithm is used to determine how files are routed and this does not match the one LISTSERV is using, then fine, LISTSERV should be changed (the problem might be a bit more complex given the LISTEARN/LISTSERV duality, but let's forget this for now). However, if everybody is using a different tool, resulting in a topology that CANNOT be determined by LISTSERV using ANY algorithm, because it depends on how this or that NAD felt on the morning where he read the description of the new GR or of pathalias, then we are basically stuck. Another important point is that, as soon as we start having multiple connections between BITNET and EARN (and I think that is a highly desirable goal - I'm confident it will happen anyway, for political reasons if not just to improve the connectivity), even if CREN were to decide that pathalias is to be used for CREN routing, it will not be enough. EARN will also have to use the same software, at least on the nodes with BITNET connections, or we run the risk of getting some interesting loops. And EARN might well have formulated a directive saying that GR is an EARN standard and everybody should use it, so we might have a very interesting situation to sort out. Why wouldn't EARN accept pathalias? Well, EARN is paying money for the development of GR and I doubt that the politicians can act in a way that might suggest this money has been, basically, wasted on something completely useless. And, pf course, GR is not suitable for the kind of topology we have in BITNET-2... Anybody got an idea how the can of worms I have just opened can be closed? Eric
GETTES@PUCC.BITNET (Michael R. Gettes) (02/13/90)
On Mon, 12 Feb 90 20:15:41 N Eric Thomas said: >Another important point is that, as soon as we start having multiple >connections between BITNET and EARN (and I think that is a highly >desirable goal - I'm confident it will happen anyway, for political >reasons if not just to improve the connectivity), even if CREN were to >decide that pathalias is to be used for CREN routing, it will not be >enough. EARN will also have to use the same software, at least on the >nodes with BITNET connections, or we run the risk of getting some >interesting loops. And EARN might well have formulated a directive saying As long as international connections have equally high weights I do not believe loops are possible. What would be possible is that routing with EARN may be different than CREN would imagine it to be since EARN would be doing different routing, and vice-versa. Eric, as for the proof that loops would or would not exist, we could discuss this offline. >that GR is an EARN standard and everybody should use it, so we might have >a very interesting situation to sort out. Why wouldn't EARN accept >pathalias? Well, EARN is paying money for the development of GR and I >doubt that the politicians can act in a way that might suggest this money >has been, basically, wasted on something completely useless. Pathalias is free and in the public domain. Yes, this is a problem. This is exactly why I brought up the whole issue. In my mind, this is a political problem. First, I feel, it is necessary to put it out that there are alternative, and I believe better, ways of doing things. Putting pathalias into NETSERV would not be difficult -- just make pathalias look like GENROUTS to NETSERV and NETSERV won't care. I would hope that there are members of EARN who are aware of this issue. I don't think the US should just jump at GR, the future has to be considered and an agreement between CREN and EARN reached with respect to routing software. /mrg