Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!umich!samsung!brutus.cs.uiuc.edu!psuvax1!psuvm!DHDIBM1!PASCH From: PASCH@DHDIBM1.BITNET (Berthold Pasch +49 (6221) 404-242) Newsgroups: bit.listserv.nodmgt-l Subject: ROUTTAB explanation. Warning: long text Message-ID: Date: 1 Feb 90 11:19:24 GMT Sender: Node Management Discussion Reply-To: Node Management Discussion Lines: 155 Approved: NETNEWS@PSUVM Gateway 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