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 PaschRAF@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