Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!bionet!raven.alaska.edu!milton!nntp.uoregon.edu!duff.uoregon.edu!jqj
From: jqj@duff.uoregon.edu (JQ Johnson)
Newsgroups: comp.dcom.lans
Subject: Re: Netware 386 NFS capabilities
Message-ID: <1991Jun4.162808.13010@ns.uoregon.edu>
Date: 4 Jun 91 16:28:08 GMT
References: <1991May10.142129.18462@jhereg.osa.com> <5744@gazette.bcm.tmc.edu> <1991May28.230655.6545@hellgate.utah.edu> <5795@gazette.bcm.tmc.edu>
Sender: news@ns.uoregon.edu
Organization: University of Oregon Network Services
Lines: 29

haas%basset.utah.edu@cs.utah.edu (Walt Haas) writes:
>We have resources about as limited as anybody.  It takes less of them to 
>support five protocols on the wire than to support encapsulation.

sob@tmc.edu (Stan Barber) writes:
>Is this just a guess, or do you really know? I really know. We tried to
>support multiple protocols in the beginning (back in 1984-86). It just 
>didn't work for us. 

I think I have experience doing it both ways.  In general, I agree with
Walt that in this era of multiprotocol routers it is much cheaper to
route multiple protocols than to encapsulate them.  However, your mileage
may vary, particularly if you need to provide non-IP connectivity outside
of a single campus network or homogeneous pool of routers.

In general, I find that the cost of protocol routing is much lower than
other costs associated with multiple protocols, notably the training
my staff need to do a good job of understanding the interaction of the
routers with host software.  From that perspective, it doesn't matter
whether you route or encapsulate.  The important thing is to keep the
number of protocols actually in use and supported down to a manageable
level.

-- 
JQ Johnson
Director of Network Services		Internet: jqj@oregon.uoregon.edu
University of Oregon			voice:	(503) 346-1746
250E Computing Center			BITNET: jqj@oregon
Eugene, OR  97403-1212			fax: (503) 346-4397