To: perot@pallas.amp.uni-hannover.de
Subject: Re: [3] STiK 2 testing etc.                                                     


On Tue, 18 Feb 1997 13:53:05 Peter Rottengatter <perot wrote: 
>
----- snip ----- re: PLIP module
>
>You do not need much network knowledge. SLIP is so basic, it's done in 
>ten lines C code. I'll zip it and send it. The SLIP code is already put 
>in, so you don't even need to worry about it. The only tricky thing is to 
>find out when and if to start sending, as direction of traffic must be 
>switched. But first you'll receive the Dialer package.

Ok, I'll be expecting them both shortly then.


----- snip ----- re: netmasks

>> Oh, I see, then I was wrong above too.  It is actually only the router which
>> handles all the netmasks.  Then I think that mask should be in ROUTE.TAB too.
>> Not that this matters greatly, but I like being able to edit a single file to
>> adjust stuff that is related to each other.
>> 
>> Here we have four codes that affect routing and are handled by the router, yet
>> one of them is only alterable via CPX which I find inconvenient.
>
>I see your point. My choice was a conceptual one. The concept of several 
>layers impose this separation. The port netmask is a much more low level 
>thing than the routing netmask. In the OSI layered network scheme the 
>port netmask is in a completely different layer (the low level hardware 
>driver layer) than the routing netmask (transport layer).

I don't really see that the conceptual model needs any correspondence to where
configuration data is stored or otherwise manipulated.  Only their actual use
needs to correspond to the model.  The question is if I have understood this
use correctly yet.


>> I've noticed that STIK.INF also contains three IP-related numbers per port,
>> including the actual IP number and what I think is the port netmask.
>
>These are the ones from, and saved by, the STIKPORT.CPX

I assumed as much, and I do prefer it to the 'normal' CPX method of saving it
in the CPX itself.  But I would prefer a single file even more.


>> I'd prefer having all the routing info in a single editable file, which should
>> be read by the system on startup, although it can be overridden by CPX or even
>> reread by CPX command (as in the current CPX) to activate changes.  After all,
>> the gateway IP is in ROUTE.TAB, and its use is dependent on the port netmask.
>
>This is again due to the OSI layer scheme, the gateway is a part of the 
>transport layer.

But if it must be unique on the port it is defined for it does not belong in
a type of definition that a port may have several of, or do you mean that each
subnet definition for a port can have a separate gateway ?


>> I have assumed that it is legal to have more than one route line per port,
>> so that routing to several subnets needing indirect access is possible.
>> I just thought I should ask you to confirm that this is so, so I know.
>
>Yes that's alright. After all, a large portion of the Internet, which you 
>cannot describe accurately with one set of template and netmask, may be 
>beyond that port.

That was what I thought.


>> Actually this means that both port_mask (new) and port_gateway(old) would
>> have redundant definitions, so it may be better to split ROUTE.TAB into
>> two sections.

You didn't comment on this so I'd better ask you about this redundancy now.
Is it allowed to have many different gateways specified for a port ?
(One for each subnet definition.)
If so, then gateways do belong on the subnet lines, but otherwise they don't.

 
>> One section would specify:
>> 
>> subnet_number	subnet_mask	port_name
>> 
>> The other section would specify:
>> 
>> port_name	port_IP		port_mask	port_gateway

>If you put the second half of this splitted routing table file into CPX, 
>then you have my scheme, so you're not that far ;-)

No, you have port_gateway in ROUTE.TAB.  I see why you do, because it becomes
a route when used, but that is influenced by port_mask to. My opinion is that
they should both be here, but not on the lines for subnet definitions.
Or, if multiple gateways per port (one/subnet) are allowed, we could use:

Subnet section:

subnet_number	subnet_mask	port_name	subnet_gateway

Port section:

port_name	port_IP		port_mask	parameters

This is identical to your current model except for including the port data
as well,  which makes it possible to understand the routing of this machine
entirely from this single file.  That is currently not the case.

Actually I prefer this model.  A gateway should be specific to the ultimate
destination rather than to the port, but you described it as port specific.
Also, 'parameters' represents the other stuff currently put in STIK.INF

Note that I do not think COPS or XCONTROL should be necessary to use STiK.
Yet my suggestion is no hindrance for using the CPX to alter the data either.
As I said below:

>> The CPX could easily scan the file to find the lines beginning with port names,
>> and extract the needed information, but when writing CPX data it is necessary
>> to carefully copy those lines not beginning with port names, to preserve user
>> remarks.  This means a new file should be opened for this copying and that the
>> old file should be deleted after it so the new file can be renamed.  I think
>> ROUTE.TMP would be a good name for the intermediate file.
>> 
>> You must decide for yourself of course, but I really think the above method is
>> more logical and useful than the current one.
>
>Sure, it's a little more convenient for people who edit files instead of 
>using CPX. But IMHO it is less logical, because the clarifying OSI 
>structure is almost lost.

Actually I think the current ROUTE.TAB structure is misleading, in that the
gateway is defined without any mention of the port net_mask which will decide
when that gateway is used.

I don't really care whether the structure of config files resembles any network
programming model or not.  They should still allow editing of information that
is related in terms of their effect, in a simple convenient manner.

If you don't want to mix the info of STIK.INF and ROUTE.TAB, that is ok too,
though I would definitely prefer having a single file for this purpose.
But if the STIK.INF shall remain it must be user editable, or it will never
be accepted.  I'm not talking about myself now, but about the list members.

Sorry to disagree so much this time, but I really got tired of this split
configuration stuff in my tests earlier. I don't mind the CPX being available,
but I didn't like being forced to use it as the only way of setting things up.

-------------------------------------------------------------------------
Regards:  Ronald Andersson                     mailto:dlanor@oden.se
                                               http://www.oden.se/~dlanor
-------------------------------------------------------------------------
