Xref: utzoo comp.dcom.lans:8229 comp.sys.novell:1696
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!basset.utah.edu!haas
From: haas%basset.utah.edu@cs.utah.edu (Walt Haas)
Newsgroups: comp.dcom.lans,comp.sys.novell
Subject: Re: Netware 386 NFS capabilities
Message-ID: <1991May28.230655.6545@hellgate.utah.edu>
Date: 29 May 91 05:06:54 GMT
References: <42116@cup.portal.com> <1991May8.184807.29998@dsuvax.uucp> <1991May10.142129.18462@jhereg.osa.com> <5744@gazette.bcm.tmc.edu>
Organization: University of Utah CS Dept
Lines: 27

In article <5744@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes:
>I have seen many, many problems with multiprotocol networks. If you have
>limited resources and can only do one protocol well because of the limited
>resources, what do you do?

We have resources about as limited as anybody.  It takes less of them to 
support five protocols on the wire than to support encapsulation.

>With the availablity of tunneling on NW/386, why run IPX on the backbone 
>anyway?

I would expect better performance in native mode, since there are that many
fewer bytes of header to process.  Perhaps more important there is less 
demand on our human resources since Novell RIP can do what it's designed to
do, instead of forcing us to duplicate the same effort with static routes.

>Appletalk has been doing well for a long time using tunneling.

Could have fooled me- the problems with AppleTalk convinced us that was a
bad approach.

>Even DECnet can be encapusulated.

As DECnet IV sinks slowly in the west this gets less interesting.  DECnet V
will be ISO, which should replace IP (they tell me)(I'm not holding my breath)

-- Walt