Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!psuvax1!psuvm!PUCC!GETTES From: GETTES@PUCC.BITNET (Michael R. Gettes) Newsgroups: bit.listserv.nodmgt-l Subject: Re: :routtab tableformat for NJEF Message-ID: Date: 8 Feb 90 16:07:43 GMT Sender: Node Management Discussion Reply-To: Node Management Discussion Organization: Princeton University, CIT Network Systems Lines: 67 Approved: NETNEWS@PSUVM Gateway In-Reply-To: Message of Wed, 7 Feb 90 20:22:31 PST from <1GTLEJS@CALSTATE.BITNET> On Wed, 7 Feb 90 20:22:31 PST Ed Skochinski said: >According to this thinking, the only thing that we should be providing is >a copy of BITEARN NODES. BITEARN NODES is generic in format and supplies >all the necessary BITNET/EARN/NETNORTH topology data needed to describe >the networks managed by the entities of the same names. True. However, you will need a program to read BITEARN NODES and extract the topological information for the network and create a view of the network from the local node (or other nodes). This is the purpose of pathalias (and GR). >The :routtab tag exists for the purposes of generating ROUTing TABles, as >well as for specifying responsible parties (in the form of NJE addresses). >If "table-format" problems are improper data for BITEARN NODES, then argue >for the removal of :routtab and the demise of GENROUTS and GR, not for the >beauty of the tag contents. > >There is an effort to provide routing tables for members of the >above-named networks by automatic methods. Right or wrong, this service >is available to anyone who has a defined table format. For those without Very good. So, I argue for the removal of the table-format information from the :routtab tag. Table format is not an issue if we create generic tables such as the one created by pathalias. I argue for the continued use of :routtab to have the originator and recipient fields for the purposes of providing the generation of the generic table by network services such as NETSERV (or other such needed processors). I completely agree that the service of providing routing tables for the network is good and still necessary, however I believe that the format of the table should be generic so as to resolve the problems of various table formats. Now, as for the NJEF lid stuff... I appreciate your problem. However, I believe that what you stated in your description is a "network management" problem within CALSTATE as for your naming conventions. You need lid information for NJEF only for NJEF software at your site. Then, you can use the pathalias map in conjunction with some other table that specifies the lid information for your organization and connecting sites. The entire network does not need to know about this (at least this is my understanding). Yes, this means some additional work on the part of NJEF systems to develop software to generate routing tables for their systems, well this has to be done for UREP, RSCS, JNET, HOMEBREW and FOOBAR systems as well. The point is, with pathalias and generic routing tables, we will not have to worry about routing for BITNET for quite some time. Pathalias is extremely robust and features that BITNET cannot even begin to consider until it removes its restrictions for symmetry. Lastly, in response to Andy Robinson suggesting a new tag... given what I have stated here, if one agrees with what I have suggested, then the need for a new tag to describe parameters for routing tables is no longer needed -- a generic table does not need parameters, by definition. Now, to add one last piece of information to this pathalias discussion. For the new topology proposed for the restructuring of BITNET the current GENROUTS has trouble generating routing tables for certain nodes. This is a known problem with certain pathological views of the network. It only happens in certain cases. I have come up with realistic views of what BITNET may look like over the next year or so and have successfully generated generic routing tables for every node in the US using pathalias for each topology. The current GENROUTS did not work. I have not had the time to test out the new GR program, my apologies to Peter Sylvester (only 25 hours in a day) and redoing those tests a quite time consuming, verification is tedious. /mrg