PASCH@DHDIBM1.BITNET (Berthold Pasch +49 (6221) 404-242) (02/01/90)
I hope that the following explanation answers most of the questions concerning :routtab. I intend to include a short excerpt of this into NODETAGS DESCRIPT to make the use of :routtab clearer. The purpose of the :routtab tag is twofold: ------------------------------------------- 1. Tell ANY table generation program about the required table format for this node. The possible tableformats are predefined according to what the available generation programs (e.g. GENROUTS) will accept. 2. Tell ANY person or server that he/she/it is responsible for generating the table and where to send it. The recipient may be a person or another server who installs the table in the networking software of the node. From the above we can conclude that: ------------------------------------ a) A :routtab tag must be specified for each node which uses a table generation program. Such programs should use the information from :routtab rather than from other sources (:netsoft, :info). b) The table format in :routtab MUST be valid for the table generation program that is used to generate the table for this node. (Other formats than the currently specified ones may be allowed when other programs become available. What a program does if it finds an unknown format in :routtab depends on program design. It may either ignore the generation request or generate a default format.) c) If a node does not need a routing table (e.g. leaf nodes with default routing) then no :routtab tag is required (technically). However, in order to signal to the network administrators that :routtab was not forgotten, you should code :routtab.NONE d) "provider" and "recipient" are only required if the "provider" needs to be informed that he/she/it is responsible for generating the table. It is useless to specify: (NONE,NONE) The following scenarios may exist: ---------------------------------- - A node entry does not contain a :routtab tag: The node administrator has forgotten to specify one. He/she should provide the :routtab information to indicate whether and how he/she gets the table. - :routtab.NONE The node administrator indicates with this tag that he/she has not forgotten to specify :routtab but his/her node doesn't need a table. - :routtab.any_table_format This indicates that some person at the node/site/member location takes care of generating and installing the table. No "provider" or "recipient" are necessary because the people at that node know who is responsible and for what reason should they make this information public? The table format must be acceptable for the tool they use locally. (see below for GENROUTS table formats) - :routtab.any_table_format (provider_nje_addr,recipient_nje_addr) The administrator indicates that he/she wants the table to be generated by the "provider" and be sent to "recipient". "provider" is usually a remote user or server who is to be informed via this way of his "duty". The table format must be acceptable for the tool that is used by the "provider". (see below for GENROUTS table formats) *** If "provider" is "NETSERV" then the NETSERV for the node's region will generate and send the table. *** If "provider" is "NETSERV@nodeid" then the specified NETSERV will generate and send the table. This format should not be selected by node administrators but should only be specified by network administration if load distribution among servers is desired. Since NETSERV uses GENROUTS for generating the tables, the valid table formats for NETSERV subscribers are predefined by GENROUTS. Valid table formats for GENROUTS: --------------------------------- There has been some confusion as to what table formats are valid for GENROUTS. There are some people who mix up information that was/is specified in :netsoft with what should be specified in :routtab. Another source of confusion may have been the interleaving discussion about the new GENROUTS program. Please forget (for a while) everything you may have heard about the new tableformats. The currently defined formats are valid for the old GENROUTS program: RSCS V1 rest ignored (for RSCS version 1) RSCS V2 rest ignored (for RSCS version 2) JES2 V1 O=nn rest ignored (for JES2 assembler style tables) JES2 V2 O=nn rest ignored (for JES2 pli style tables) JES3 rest ignored JNET rest ignored UREP rest ignored Why are there nodes which don't have a :routtab tag yet (in BITNET): -------------------------------------------------------------------- Last year I prepared a list of nodes with their appropriate :routtab tags according to the subscriptions found in :inform/:info tags. The :routtab tag contained NETSERV as "provider" and the person from the :inform tag as "recipient". I omitted from this list all nodes for which the tables could easily be generated locally because they are VM or MVS sites or are managed by an administrator at a VM or MVS site. (At that time it was not yet clear that :routtab should be enforced and that it should also be specified for nodes which generate the tables by themselves. Therefore the list included only such :routtab information for which "provider" (NETSERV) and "recipient" was available.) I sent this list to BITNIC and asked them to include the :routtab tags into the appropriate node entries. According to the old BITEARN NODES description the :inform/:info tags have been used by Chris Thomas to generate and ship the table. Thus all nodes which received tables from Chris AND are not expected to generate them locally should now receive the tables from their assigned Region-Netserv. Conclusions: ------------ Check your node entry (entries) whether a :routtab tag is specified. If not, specify: :routtab.NONE if you need no table :routtab.table_format if you generate your table with GENROUTS :routtab.table_format (NETSERV,recipient_nje_address) if the table is to be sent from NETSERV Send the update request for your node entry to your network administration (BITNIC or Country Coordinator). Regards, Berthold Pasch
RAF@NIHCU.BITNET (Roger Fajman) (02/02/90)
Makes a lot of sense to me, Bert. Just one quibble. I thought that I heard others say that all versions of RSCS use the same routing table format. If that's true, there's no reason for Vn in the :routtab tag. Or are they really different?
POSTMAST@TECMTYVM.BITNET (Juan M. Courcoul) (02/02/90)
Fortunately, the ROUTE statements placed in a RSCS DIRECT (for RSCS V1) or RSCS CONFIG (for RSCS V2) file are identical. This makes for an easier upgrading from V1 to V2. The only difference between a NETINIT file generated for V1 and one for V2 is the commented out auxilliary statements placed at the beginning by GENROUTS. If you make no use of these statements (i.e., you never uncomment them; you just GET the file into your DIRECT or CONFIG and save it as-is), then there is no difference and the V1/V2 section of the tag is irrelevant. There might only be a slight confusion for an untrained helper, since the file does state 'RSCS Vxx Routing ...', where the xx might not agree with your installed version. If you do use those statements, then you do need to have the proper V1/V2 in the tag. However, in these cases, you have to 'fill in the blanks', regarding the vaddr for each of your LINKs, and other info, anyway. Hope this helps. Juan