PASCH@DHDIBM1.BITNET (Berthold Pasch +49 (6221) 404-242) (02/07/90)
The following is the result of a discussion between
Ed Skochinski and me. What we are now looking for
are additional suggestions, considerations or objections
(if there are reasons why it should not work).
GR (genrouts) will support the NJEF routing table format.
However, the tables for NJEF require additional information which is
not (yet) provided in the nodes file (neither new nor old format).
The missing information is the 3-character local link-id ("lid")
to which NJEF will associate the linkname (adjacent nodename).
This "lid" MUST appear in the NJEF routing tables.
In order to avoid that NJEF node administrators have to edit the table
manually for inserting the proper "lid"s in more than 3000 route
statements, the correct "lid"s should be generated by GR (genrouts).
Thus GR has to know which linkname is associated with which "lid".
The most logical place to specify such a link-attribute would be
the linkdefinitions in the :linksNN tags. However, I'm reluctant
to extend the linkdefinition to include such local information.
The next logical place would be the :routtab tag since the "lid"s are
only used for generating the routing table and the tableformat in the
:routtab tag contains local information anyway.
The tableformat for NJEF could then be:
NJEF linkname1=lid1 < linkname2=lid2 ... >
Since at present the maximum number of linkname=lid associations
used by any NJEF node is four, and it is unlikely to ever grow beyond
ten, I think this is a practical solution.
The total length of such a :routtab tag would still fit into the maximum
length allowed for tags (max is 255).
If there are no objections or better proposals, then I'll specify
the NJEF tableformat in :routtab as shown above.
Regards, Berthold PaschGETTES@PUCC.BITNET (Michael R. Gettes) (02/08/90)
On Wed, 7 Feb 90 11:09:31 CET Berthold Pasch +49 (6221) 404-242 said: >If there are no objections or better proposals, then I'll specify >the NJEF tableformat in :routtab as shown above. Yes, I have a problem with this. I will restate that this kind of information is not necessary within BITEARN NODES. This is a "table-format" problem and not a routing problem. If NJEF nodes need some additional information in their routing table, that happens to be tied to network topology, then they should devise a program that figures out network topology and the associated links and do the right thing with generating a routing table. I believe this to be the case for HOMEBREW site as well. We should be providing a routing table in a generic format, something similar to what a standard pathalias map looks like (which I will show below), and then auxiliary software would be developed to convert this generic map into a routing table of appropriate format by software developed or acquired by the local node. I do not like the idea of riddling the BITEARN NODES file (and especially the :routtab tag) with additional tidbits of information that is not necessary. And, saying that a limit of 4 or 10 is ludicrous -- Murphy says it WILL exceed whatever theoretical limit you set. I vote no for this additional information being introduced into the :routtab tag and to adding this type of information to BITEARN NODES in general. A few lines from the PUCC MAP produced by pathalias. I have a program that then turns this map into a RSCS routing table. acadia punfsv2!cornellc!utorvm!unbmvs1!dalac!acadia!%s acmvm punfsv2!cunyvmv2!cunyvm!acmvm!%s acusd punfsv2!ucbcmsa!uclacn1!uscvm!ucivmsa!sdsc!acusd!%s acuvax punfsv2!ricevm1!uhou!utgate!acuvax!%s aearn punfsv2!cunyvmv2!frmop22!cearnv2!aearn!%s aeclcr punfsv2!cornellc!utorvm!mcgill1!qucdn!uottawa!aeclcr!%s agu punfsv2!psuvm!psubit!gwuvm!agu!%s ainuni01 punfsv2!cunyvmv2!frmop22!cearnv2!aearn!ainuni01!%s aip punfsv2!yalevm!sbccvm!hofstra!aip!%s akron punfsv2!ohstvma!csuohio!akron!%s If you will notice, you get more information with a pathalias map then you do just a routing table. ACADIA is routed via the link PUNFSV2. But, it also shows the full path taken from PUCC to ACADIA. Additionally, from this map I can display all the published links for any node on the network with one pass of this file. /mrg
mwh@IVORY.EDUCOM.EDU (Michael Hrybyk) (02/08/90)
I would not like to see routtab cluttered with things that genrouts should take care of. The unique linkid can be manufactured and output; why is it necessary to specify? Mike
1GTLEJS@CALSTATE.BITNET (Ed Skochinski) (02/08/90)
On Wed, 7 Feb 90 11:53:34 EST, GETTES@PUCC.BITNET said, > We should be providing a routing table in a generic format, something > similar to what a standard pathalias map looks like 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. > This is a "table-format" > problem and not a routing problem. > ... > I do not like the idea of > riddling the BITEARN NODES file (and especially the :routtab tag) with > additional tidbits of information that is not necessary. 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 defined table formats, they can either a) mourn their exclusion, or b) respond to the individuals responsible for :routtab and GR who posted requests for information on table formats so that the service could be extended to as many as possible. The information for NJEF *is* necessary to generate run-ready configuration directives. The JES2 offsets "O=nn" are of exactly the same nature. Ed Skochinski Operating Systems Support The California State University
ERIC@SEARN.BITNET (Eric Thomas) (02/08/90)
I think you have to be reasonable. One thing is to include in BITEARN NODES information which is needed for a particular OS only but which cannot be added locally into the file, eg node numbers for JES. It is another thing entirely to start putting purely local information into BITEARN NODES. Let's say GENROUTS were to make NJEF routing tables with, for instance, the string '*linkname*' in lieu of the LIN identification. How many lines of code does it take to make a FORTRAN program that will read a file where each record contains a linkname and the associated LIN, and then read the output of GENROUTS and replace all the *linkname* with the corresponding value? Let's put the problem another way. Let's say that I'm the techrep of a new node running software XYZ, which needs routing tables but which is not supported by GENROUTS, and requires the specification of the colour of the cable going from my communication controller to my modem in the routing tables. I would already be VERY grateful if the GENROUTS developers took time to write the code to create a routing table that contains everything except the colour of the cable. I would gladly spend some of my time to write the necessary additional software, and send it to whomever might need it. And I would find it normal that the BITEARN NODES specifications are not changed for my system, since it is not an absolute requirement for the information to be there (that is unfortunately not the case of JES node numbers), and since other sites obviously do not care about the colour of my modem cables. To summarize, let's try to keep whatever is local local. Eric
GETTES@PUCC.BITNET (Michael R. Gettes) (02/09/90)
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
mwh@IVORY.EDUCOM.EDU (Michael Hrybyk) (02/09/90)
fastrout/pathalias will generate a linkid by truncating a nodename in a given format specification. The post-processor handles the problem, so no node specific information is necessary in the :routtab tag. Moreover, this is the proper place (post-proc) for making adjustments in format. Note that GR could do the same thing, but new code would be necessary. fastrout shares the shortest path and cycle trimming code as in pathalias. It will have none of the liabilities of GR to which Mike Gettes alluded. I'm just about ready to ship fastrout to folks that volunteered for porting. I'm running a bit late, and have had little spare time of late to tidy up loose ends. Mike Hrybyk BITNIC
1GTLEJS@CALSTATE.BITNET (Ed Skochinski) (02/09/90)
Michael Gettes wrote: > 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 could live with this. I'm taking fair advantage of the *current* :routtab definition. JES node numbers may be taken from existing tags, but the OFFSET "O=nn" most certainly is local information. Since there is this precedent of :routtab containing local information, I see no problem with NJEF needing local information. Without the precedent, I wouldn't be defending my position. I suppose I could insist, "If you forbid NJEF local parameters, then you *must* remove O=nn." Acceptance of this would be a Pyrrhic victory. It's just dumb luck that JES2's local part is cosmetically clean and NJEF is somewhat messy. Eric Thomas wrote: > Let's put the problem another way. Let's say that I'm the techrep of a > new node running software XYZ, which needs routing tables but which is > not supported by GENROUTS, and requires the specification of the colour > of the cable going from my communication controller to my modem in the > routing tables. > ... > And I would find it normal that the BITEARN > NODES specifications are not changed for my system, since it is not an > absolute requirement for the information to be there (that is > unfortunately not the case of JES node numbers), and since other sites > obviously do not care about the colour of my modem cables. How about this way: Let's say that software XYZ needs bizarre text strings, such as "ROUTE" in front of the destination node and neighbor node. And, I can determine this as side effect of the name of their networking software. I should find it normal that BITEARN NODES does not carry this information, and should not expect the routing table generator to be special-cased to handle this side effect, no matter how deterministic it might be. Other sites obviously do not care about the spelling and format of my configuration statements, so long as I keep up to date. Furthermore, a large percentage of the hosts on the network have this software, but their weighty presence is not sufficient to force a network supported program to special-case only the software with clout derived from their quantity. I should be VERY happy to receive a list containing only two columns of data: A destination node name and a neighboring node name to whom I can pass. Eric's argument is excellent support of the format-independent table proposed by Michael. However, GR creates configuration statements, not just a tailored network snapshot. NJEF sites have as much right to run-ready congiguration statements as do the rest. Eric Thomas writes: > To summarize, let's try to keep whatever is local local. We now treat :netsoft as informational only. This is obviously local data, let's remove it. If I read the descriptions correctly, tags :nodedesc, :machine, :system, and :remarkN are local. Keep them out of BITEARN NODES. I assume that the wars over inclusion of these tags are long since over. Why should we tolerate this local data, and at the same time forbid information which enhances the service provided to a member's site? Ed Skochinski Operating Systems Support The California State University
GRZ027@DBNGMD21.BITNET (Peter Sylvester +49 228 8199645) (02/09/90)
There is not much difference between the JES2 node numbers and the lids. The requirement for JES2 node number is that they have to be the same from one table to he next. Nobody forces us to have the same node numbers in all JES2 systems (actually the offset makes them different.) The old GENROUTS could have read a previous JES2 initialization file for that node, and reserve some range for free assignments of node numbers. The next month these node number would be taken. Of course this only works when the JES2 table are available where GENROUTS is used, but in the beginning of EARN the tables had been created at the central NETSERV. The central assignment of node numbers was a simple solution. For GR and NJEF we have the situation that we need some three character names associated to the direct neighbours, and these names must not change and they should not be arbitrily choosen because of local naming conventions. If GR is used at a remote NETSERV to create an NJEF table then either local post processing must be done, or the information about the lids has to be in BITEARN NODES. The current GR writes LIDnnnn where nnnn is the JES2 nodenumber,i.e. an erroneous file is created. Peter
ERIC@SEARN.BITNET (Eric Thomas) (02/09/90)
This is getting ridiculous. >JES node numbers may be taken from existing tags, but the OFFSET "O=nn" >most certainly is local information. I'm not the one who decided to put JES node number offsets in BITEARN NODES, and I can certainly see problems stemming from this (eg node X had O=40, installs 10 new nodes, and it takes 6 months for the update of their node entry to take place so they have to correct tables "manually" for 6 months). However, this is something which has been in place for years, which has nonzero usefulness, and it would therefore be stupid to remove this support. >How about this way: Let's say that software XYZ needs bizarre text >strings, such as "ROUTE" in front of the destination node and neighbor >node. And, I can determine this as side effect of the name of their >networking software. I should find it normal that BITEARN NODES does not >carry this information, How about this way: given a good dictionary and a bit of imagination, it is possible to translate simple statements from, say, spanish to foreign languages. Therefore in a country like Switzerland where there are significant amounts of german-, french- and italian-speaking people, I should find it normal that, for instance, train time-tables and touristic information be given only in spanish; everybody would just buy the appropriate dictionary and translate as necessary. As you may know, VMS and VM are the two most common operating systems on BITNET; I have run a quick search on BITEARN nodes and found 1.8% of NJEF sites. You can hardly compare the "value-for-effort" ratio of the two solutions. >We now treat :netsoft as informational only. This is obviously local >data, let's remove it. Sorry Ed, but *I* definitely care about what type of networking software a site is running. This field is used by the LISTSERV 'BITEARN NODES' database formatter, and is useful information FOR HUMAN BEINGS. The same is true, by definition, of :remarkN. Now I'm starting to get fed up with this issue. Ed, I'm making an offer. Send me a description of the format of your routing tables and, if I can find a FORTRAN compiler on site, I'll make you a FORTRAN program to update it as per a local LID file. It will probably take me less time than I needed to write this note. Eric
MAINTCMS@PUCC.BITNET (John Wagner) (02/09/90)
On Thu, 8 Feb 90 14:03:02 PST Ed Skochinski said: >We now treat :netsoft as informational only. This is obviously local >data, let's remove it. If I read the descriptions correctly, tags >:nodedesc, :machine, :system, and :remarkN are local. Keep them out of >BITEARN NODES. I assume that the wars over inclusion of these tags are >long since over. Why should we tolerate this local data, and at the same >time forbid information which enhances the service provided to a member's >site? Ed, I would argue that :nodedesc, :machine, :netsoft and :system are not local data. I often use these in my job as postmaster to try to detemine what I should be seeing in mis-routed mail (i.e. why did I get back PMDF Receives: from a VM system that I know is running MAILER?). :netsoft tells you what kind of commands you can issue to the node. To me these are not the same sort of entity as the additional info in the :routtab tag that started the whole discussion. These are people usable. Despite my earlier statement to the contratry, the :routtab can not be used by a person, except to see if a node claims someone is generating routing tables for it. Maybe I'm crazy, but to me it seems much more important to know the routing tool is producing valid routes. That to me is the most important service being provided. It is already known that GENROUTS cannot produce correct routing tables for some network configurations. I don't know if GR has been validated, but I sure hope it will be. I do know that the time to validate it will be substantial. In the same vein of removing local info from the :routtab tag, Mike Gettes and I have talked a little about the O= value for JES2 systems. I'm not familiar with how the routing tables for JES2 works. Is there any reason a generic table couldn't be created (with the node number in the appropriate field but without the offset applied) and then post process this table to add the local offset value? Would some JES2 folk post how those numbers are used?
GETTES@PUCC.BITNET (Michael R. Gettes) (02/09/90)
On Thu, 8 Feb 90 14:03:02 PST Ed Skochinski said: >local parameters, then you *must* remove O=nn." Acceptance of this would >be a Pyrrhic victory. It's just dumb luck that JES2's local part is >cosmetically clean and NJEF is somewhat messy. I submit that the O=nn is not necessary either. This too could be handled by the table generating post-processing software for a pathalias map. > I should be VERY happy to receive a list >containing only two columns of data: A destination node name and a >neighboring node name to whom I can pass. You get this in a pathalias map, along with additional information of what the next hop is after the neighboring node, and so on. I believe this to be beneficial. >Eric's argument is excellent support of the format-independent table >proposed by Michael. However, GR creates configuration statements, >not just a tailored network snapshot. NJEF sites have as much right >to run-ready congiguration statements as do the rest. These configuration statements have been removed in the new GR. The current configuation statements in the current GENROUTS is simply a guideline. I like having something at the top of the routing table that says "these are the directly connected links..." which signifies how the routing table was generated. >We now treat :netsoft as informational only. This is obviously local >data, let's remove it. If I read the descriptions correctly, tags >:nodedesc, :machine, :system, and :remarkN are local. Keep them out of >BITEARN NODES. I assume that the wars over inclusion of these tags are >long since over. Why should we tolerate this local data, and at the same >time forbid information which enhances the service provided to a member's >site? My feeling is that there are various systems that run on BITNET, and unfortunately, due to lack of standards and specifications, these systems vary enough that it is absolutely necessary to know the type of system, software and machine in order to communicate with these various nodes (and to diagnose problems as well). I do not agree that this is "local" information. /mrg
GOMIDE@BRFAPESP.BITNET (02/10/90)
> To summarize, let's try to keep whatever is local local. > We now treat :netsoft as informational only. This is obviously local > data, let's remove it. If I read the descriptions correctly, tags > :nodedesc, :machine, :system, and :remarkN are local. Keep them out of > BITEARN NODES. I assume that the wars over inclusion of these tags are > long since over. Why should we tolerate this local data, and at the same > time forbid information which enhances the service provided to a member's > site? Why should the Universe bother with such local info as :planet.EARTH - where is that planet anyway? Somewhere near Andromeda, I heard.
GETTES@PUCC.BITNET (Michael R. Gettes) (02/10/90)
On Fri, 9 Feb 90 09:45:15 PST Ed Skochinski said: >The new GR does in fact produce run-ready configuration statements for its >supported table formats (or in the case of NJEF, comes close, and thus >this entire argument...). I would hope that it is somewhere documented that these "run-ready" statements are not recommended to be used and included for documentation purposes only (since they are commented records). >I would support a change to [the new] GR such that it produces an >agreed-upon generic format. Additionally, GR could add to each line (or >logical output record) sufficient data for a post-processor to create a >complete configuration statement. The sufficient data could come from >BITEARN NODES *only*, and would be based upon the :routtab.table-type. >The reason for this addition: it would be wasteful to require another >program to parse and extract BITEARN NODES tags while GR has already done >the task and can align it node-for-node upon output. This would satisfy This is getting ridiculous. Mike Hrybyk has already provided a bitnet version of pathalias that can deal with BITEARN NODES. I am not in favor of having GR generate a generic format. I recommend the use of pathalias because its routing algorithm works and has been proven over the last 7 or 8 years of its use. Obviously this point is of little concern to persons who do not deal with the network topology -- but it is of great concern to me. >Furthermore, with GR being written in Pascal, it would satisfy the lowest >common denominator criteria. Wrong. This criteria is not formally recognized. C is far more prevelant in the world today, and this is my opinion just as Pascal is yours. As I stated before, I believe the true LCD is FORTRAN, and I believe that this is not an option at this time. If you want to transform the pathalias C program into Pascal, fine. As for use of pathalias, at least in the US, I think it is time to either have a public referendum or decision by a higher authority. I do not believe that GR is the way to go. I believe pathalias is the right direction, especially considering the possible dynamics of the future. I feel I have clearly stated my case. I think it is at the point where enough explanation has been set forth where people can make their own decisions or at least ask appropriate questions. This is, of course, my opinion. /mrg
RAF@NIHCU.BITNET (Roger Fajman) (02/10/90)
> In the same vein of removing local info from the :routtab tag, Mike > Gettes and I have talked a little about the O= value for JES2 systems. > I'm not familiar with how the routing tables for JES2 works. Is there > any reason a generic table couldn't be created (with the node number > in the appropriate field but without the offset applied) and then post > process this table to add the local offset value? Would some JES2 > folk post how those numbers are used? Here's a sample from NIHCU's January 1990 routing table, created by GENROUTS: N0200 NAME=CUNYVM,NONETATH,NODEVATH,NOJOBATH,NOSYSATH,SNA CONNECT NODEA=0200,MEMBA=1,NODEB=1852,MEMBB=1,REST=2 /* -> CUNYVMV2 */ N0201 NAME=AKRON,NONETATH,NODEVATH,NOJOBATH,NOSYSATH,SNA CONNECT NODEA=0201,MEMBA=1,NODEB=0227,MEMBB=1,REST=2 /* -> CSUOHIO */ N0202 NAME=ANLCHM,NONETATH,NODEVATH,NOJOBATH,NOSYSATH,SNA CONNECT NODEA=0202,MEMBA=1,NODEB=0207,MEMBB=1,REST=2 /* -> ANLOS */ The Nnnnn statements are defining the node numbers and names, plus other attributes of the nodes. We use a starting node number of 200 (O=199). The CONNECT statements are defining the connections between the nodes. NODEA and NODEB are specifying the node numbers of the two ends of the connection. MEMBA and MEMBB are specifying particular machines in a loosely coupled complex. "/* whatever */" is a comment. We run JES2 2.2.0. Other versions use somewhat different formats, but the information is the same. JES2 uses the CONNECT statements to figure out what link it needs to send a particular file on. If the Network Path Manager is used, then the CONNECT statements are omitted and JES2 figures out for itself dynamically what is connected to what. Information is passed around the network for this purpose. Currently only JES2 has a Network Path Manager, so all BITNET nodes are defined with CONNECT statements. By the way, it is possible to define multiple connections, loops, etc. JES2 will use resistances to figure out with path to use. The BITNET tables to do make use of this capability because other NJE software does not support it. To answer the question, yes, it would be possible to post process a routing table to add in the offset. Why that would make sense is a lot less clear to me. If you are going to do that, you might as well run some program to generate your own routing table from scratch (GENROUTS or a replacement for it). GENROUTS and GR do run on MVS. I don't know about Pathalias/Fastrout. I've been using GENROUTS for several years and am quite satisfied. Before that my routing table got lost in transit more than once.
RAF@NIHCU.BITNET (Roger Fajman) (02/10/90)
> As for use of pathalias, at least in the US, I think it is time to > either have a public referendum or decision by a higher authority. > I do not believe that GR is the way to go. I believe pathalias is > the right direction, especially considering the possible dynamics of > the future. > > I feel I have clearly stated my case. I think it is at the point where > enough explanation has been set forth where people can make their own > decisions or at least ask appropriate questions. This is, of course, > my opinion. > > /mrg What would such a vote or decsion be on? I suppose it could decide what tools to use on BITNET for centralized generation of routing tables, although that in itself wouldn't get the rest of the necessary software written to replace what is being done with NETSERV and GENROUTS. I certainly don't see how individual sites could be prevented from using whatever tools they deem proper to generate their own routing tables. I also don't think it is desirable to try to prevent that.
GETTES@PUCC.BITNET (Michael R. Gettes) (02/12/90)
On Fri, 9 Feb 90 20:56:55 EST Roger Fajman said: >What would such a vote or decsion be on? I suppose it could decide >what tools to use on BITNET for centralized generation of routing >tables, although that in itself wouldn't get the rest of the necessary >software written to replace what is being done with NETSERV and >GENROUTS. I certainly don't see how individual sites could be >prevented from using whatever tools they deem proper to generate their >own routing tables. I also don't think it is desirable to try to >prevent that. If "standards" were ever implemented for our fine network, then I believe a standard should exist such that all nodes on the network MUST use the same routing table generation programs. We cannot have nodes generating routing tables that do not use similar algorithms or similar data. I believe that a vote or decision would be on the use of pathalias as a tool for centralized generation of routing tables as well as distributed (local) generation of routing tables. Basically, to decide whether or pathalias should replace GENROUTS for CREN. /mrg