🚀 go-pugleaf

I wrote:

> K-Star is able to be statically configured, and is better [than KIP]
> in other ways as well (though worse in some others . . .).

By way of clarification (by popular demand), here are some True Facts
As I Understand Them (errors are certainly due to Post-Holiday
Depression):

1)  KIP (any version, 0688 is the latest) runs only on KFPS-[123]
models; it does not run on KFPS-4s or "upgraded" [123]s.  Kinetics'
K-Star, which is 99% equivalent to KIP in functionality, runs only on
KFPS-4s and upgraded [123]s (known perhaps as KFPS-2U, -3U, etc).  The
"old" FastPath Manager program must be used to load and configure KIP;
the FastPath Manager II program must be used to load and configure
K-Star. 

2)  Things KIP and K-Star do the same:

 * support Mac/IP and NCSA Telnet, including static or dynamic IP
address assignment in the "address-spoofing" (rather than
separate-subnet) style;

 * support AppleTalk bridge (ie, router) functions between LocalTalk,
AppleTalk-in-UDP (known to some as IPTalk, which may TM of somebody),
and EtherTalk;

 * are able to download configuration info from an "atalkad" server
running on a Unix host.

3)  Things KIP and K-Star do differently:

 * KIP has fixed table sizes for many managed variables, including
AppleTalk routes, zone names, etc.  Large nets may bump into these
limits, and suffer.  K-Star uses some sort of dynamic scheme that may
make it less likely to run out of room for these things, but how do you
know?

 * KIP supports a kludgey but useful protection scheme for keeping
Laserwriters or other servers from being visible between zones.  K-Star
does not.

 * KIP supports optional use of the newly-defined "official" UDP port
assignments for AppleTalk functions (as does CAP).  K-Star supports
only the traditional port assignments.

 * K-Star, in addition to being an order of magnitude easier to
configure since you don't have to edit hex fields in text files, is
able to be configured for use entirely from FastPath Manager II, unlike
KIP which must get configuration info from an atalkad server.

3) Why a KFPS-4 is better than a KFPS-[123]:

 * Much better performance.  We observed that on busy Ethernets file
service across two KFPS-[123]s was impossible.  With KFPS-4s it's fine.
Similarly a KFPS-[123] is marginal when translating EtherTalk-to-IPTalk
(for a MacII to use Aufs, typically), but the -4 does fine.

 * More memory.  In addition to meaning fewer dropped packets,
presumably, it also means not running into table size limits like those
in KIP that have forced us to partition our campus AppleTalk nets.

 * It can be loaded from the Ethernet side.  Also, it remembers its
Ethernet address.

 * I can't think of any reasons why a KFPS-[123] is better, except
possibly that it can run KIP for those who need it.  It's not clear
how many of the KFPS-4 benefits are achieved by the upgraded
KFPS-[23]U, however.

4) The KFPS-4 has had a number of PROM revisions.  The first version
we got, in August/September 88, was almost unusable in our environment
because of a bug that prevented more than one box from being in a
zone.  I think this version was labelled "C0X5" on the chip but called
itself "3.1" when viewed from the FastPath Manager.  A second version,
called (I think) "C0X7" on the chip and "4.0" in the FPM, solved that
bug, but seemed to crash a lot.  The current version (as far as I
know) calls itself "4.1" in the FPM and I'm not sure what on the chip,
and seems much improved all around.  Each of these came, of course,
with a new version of the Manager and of K-Star (currently 4.1 and
5.03, respectively).  My impression is that most of the problems
people report to the list sound like the ones caused by these earlier
versions.  Kinetics' handling of these multiple versions has been less
than stellar (though it appears to have improved recently), and it
sounds like others have had a worse time of it than we have.

Disclaimer: Kinetics and Stanford have some sort of relationship.
Call our lawyers if you're interested, then explain it to me if you
understand it.

 - RL "Bob" Morgan
   Networking Systems
   Stanford University