RAF@NIHCU.BITNET (Roger Fajman) (02/08/90)
> 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 How is this turned into a JES2 routing table? The necessary node number information isn't there.
GETTES@PUCC.BITNET (Michael R. Gettes) (02/08/90)
On Wed, 7 Feb 90 22:35:18 EST Roger Fajman said: >> 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 > >How is this turned into a JES2 routing table? The necessary node >number information isn't there. I ad replied to Roger offline -- I shall repeat what I have stated to him. Yes, the node number information is not present. For the JES systems, it would be trivial to extract a report that has an association of node names and node numbers. I figure a pascal or c programmer could develop a program to chow down on the pathalias map and this node number association file in a day to generate a jes2 routing table. If I remember correctly, the jes3 tables do not require node numbers. /mrg
GETTES@PUCC.BITNET (Michael R. Gettes) (02/09/90)
On Thu, 08 Feb 90 12:04:22 EST you said: >I guess I need to be more clear in the way that I say things. >Obviously I knew that node number information is available from other >sources. The question should have been stated as "Why is this >information needed to generate JES2 routing tables not included?" I >assume that the answer is probably that pathalias does not allow for >it. Couldn't it be bundled in with the name, though? As in something >like acadia-1234? As Mr. Hrybyk noted, it could easily be added to a generic table using his specifications in a config file. I also think it would be a trivial modification to include the nodenumber in the generic routing table of base pathalias. Now, before Ed gets annoyed that I am meeting Roger on this point for pathalias, the reason I feel the inclusion of nodenumbers is important in a generic table is that the symmetry of BITNET is brought about by the nodenumbers. In other words, this is how we break ties and can be important information during topological analysis, and would greatly simplify some of the analyzing tools I have developed for myself. So, from the standpoint of routing and analysis, I feel nodenumbers in a generic table is justified. Additionally, I think I can argue that if we did not need nodenumbers to break ties on BITNET, then the :NODENUM tag is no longer necessary since this too would be a "local" configuration problem. If I am wrong on this -- I am sure Roger or LDW will be quick to correct me ;-). >More generally, my question was intended to point out that generating >routing tables from the above described pathalias output is sometimes >more involved than a simple textual transformation. This may be true. And maybe not. I have already written something to do the RSCS tables in REXX. It was easy. Adding some additional information to the problem will not make the problem an order of magnitude greater. >A second question that I asked Michael offline is "Why would anyone >want to spend any time at all writing such a program when GENROUTS is >already available?" Well, I feel I have described quite a number of the merits of pathalias. I will include below what I had answered to Roger offline. >The current GENROUTS is no good. The new GR uses a yet to be proven >algorithm for generating routing tables. Pathalias has been in use >for years. It works great! It is already in C, only one version needs >to be maintained. If we remove the function of formatting a routing table >from GENROUTS, then we no longer have to worry about people getting the >right version of GENROUTS to generate a specific table. Every time a >new format is required, because somebody writes a new NJE emulator in >a fishbowl and dreams up some new file format, then GENROUTS will have >to be modified to handle it. Then everyone must get a copy of the new >program to be up to level since it is possible to slip in changes to >the routing algorithm. Everyone is affected by this change. This way, >if a new table format is needed, then just write a post-processor for >the pathalias map. You could then give that program to some central >clearing-house, like BITNIC, so others having your system would not >have to re-invent the wheel. >Lastly, the generic table is a map of routing, something >GENROUTS does not produce and will not produce in the new program. >These pathalias maps are extremely useful. /mrg
mwh@IVORY.EDUCOM.EDU (Michael Hrybyk) (02/10/90)
Mike G. and I agree wholeheartedly here. My additions to pathalias include a generic postprocessor, obviating the need for new software releases every time table format changes occur in the network. Format changes, site tailoring, and other issues *that have nothing to do with general network routing* are thereby kept separate, and are relegated to a policy decision (what should the config file look like, what information to include in a routing table, ...). As for the amount of work involved: 1. the pathalias core was already done. 2. the NODES parser front end was needed for other tools (hasn't everybody done this? why don't we standardize some access routines in C, Pascal, REXX, ...?) 3. the postprocessor was an add-on, and would seem to cut down on the amount of maintenance needed later. This produces a net savings in time over the life of the code. It also eliminates the need for a set of programmers per OS developing system-dependent post processors. Of course, one can still generate a generic table that some arbitrary post-processor can transform. Mike Hrybyk BITNIC
RAF@NIHCU.BITNET (Roger Fajman) (02/10/90)
> nodenumbers in a generic table is justified. Additionally, I think > I can argue that if we did not need nodenumbers to break ties on BITNET, > then the :NODENUM tag is no longer necessary since this too would be > a "local" configuration problem. If I am wrong on this -- I am sure > Roger or LDW will be quick to correct me ;-). As far as JES2 is concerned, node numbers are local information in the sense that they are used only internally within JES2 and do not appear in the NJE protocol. It is important that they not change from month to month, as they are used to queue files within JES2. But maybe we should step back a little here and think about what the purpose is in all this. Personally, I think we should encourage sites to generate their own routing tables. To do that we need to provide the tools, or make them as easy to write as possible. If that requires a little more information in BITEARN NODES, then so be it as long as it does not place an excessive burden on the network administration (BITNIC, etc.). If, for one reason or another, a site cannot generate it's own routing tables, then fine, have NETSERV for something else generate them. But a site that can't run the tools to generate their own routing tables may well not be able to spend a lot of time and effort converting some sort of generic table format to something they can use. So, to summarize, I think it's more important to make it easy for as many sites as possible to generate their own routing tables than it is to keep the size of BITEARN NODES to an absolute minimum.
GETTES@PUCC.BITNET (Michael R. Gettes) (02/12/90)
On Fri, 9 Feb 90 20:11:51 EST Roger Fajman said: >If, for one reason or another, a site cannot generate it's own routing >tables, then fine, have NETSERV for something else generate them. But >a site that can't run the tools to generate their own routing tables >may well not be able to spend a lot of time and effort converting some >sort of generic table format to something they can use. Obviously we should be in a mode where both services are achievable. However, a set that cannot run the tools to generate their own routing table certainly can get some previously written tool to post-process a pathalias map. And, if the site is a brand new node and there exists no other node on the network with their table format, they are going to have to develop some tools anyway. I believe this is not a valid nor realistic point. /mrg
U0A61@WVNVM.BITNET (Bryan, Jerry) (02/13/90)
The discussion of the Princeton proposal for reorganizing BITNET nodes and using VMNET was moved over to NODMGT-L, to which I duly subscribed. Ever since, I have had about 50 notes per day discussing pathalias and GENROUTES and so forth which I would really rather not see. Could I persuade anybody to move the discussion of the Princeton proposal back to POLICY-L or BITNET-2 or somewhere so I can get off NODMGT-L but still follow the discussion of the Princeton proposal?
VALDIS@VTVM1.CC.VT.EDU (Valdis Kletnieks) (02/13/90)
On Mon, 12 Feb 90 13:22:31 EST Bryan, Jerry said: >The discussion of the Princeton proposal for reorganizing BITNET nodes and >using VMNET was moved over to NODMGT-L, to which I duly subscribed. >Ever since, I have had about 50 notes per day discussing pathalias and >GENROUTES and so forth which I would really rather not see. Could I >persuade anybody to move the discussion of the Princeton proposal back >to POLICY-L or BITNET-2 or somewhere so I can get off NODMGT-L but >still follow the discussion of the Princeton proposal? Jerry: The reason you are seeing so much pathalias and GENROUTS traffic is because it is an issue that HAS to be resolved at least partially before we can move ahead on the Princeton proposal. If we were to plunge ahead without being sure that we can generate proper routing tables, large number of both users and systems administrators would be ready to lynch us... Valdis Kletnieks Virginia Tech P.S. Insert the usual disclaimers here..