HDTenEightyP/NetNews huggingface dataset:
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: Another Application
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Sun, 13 Sep 1992 06:24:50 GMT

In article <ppjv318@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> ...[attack on proposed application deleted]....


Sorry, I left out the important point.

I think if you stop and think for a moment about these proposed
applications, you see that none of them require anything unique in the
hypothesized frame-relay or cell-relay networks.

Not all of those nasty network layers exist just to give Standards
Committee Go-ers something to argue about.  The "hassle, muss,
management, and extra layers" of the currently successful protocols
such as TCP/IP exist because the obvious, simple stuff did not work
when it was tried 10 or 20 or 25 years ago.

Most of the applications you have proposed involve "broadcast" or
"multicast".  As I understand those notions and The Phone Companies,
the telephony guys have never before been interested in such notions.
Don't you think it will be a while before they get multicasting
together?

Most of us hope The Phone Companies' ATM or other frame relay offerings
will be useful, successful, inexpensive, and available.  If expections
of magic in those networks is wide spread, then our hopes are ill
founded, because the inevitible disillisionment will kill the
offerings.  Don't you think a big part of the current problem with ISDN
is that it was over sold a long time ago, and now many people refuse to
believe in it?

The few ATM switches I know almost nothing about (I know nothing about
the rest) have strange kludges to support multicast--or so they seem to
me.  It's not clear to me how you do the necessary resource reservation
in such "cross bar" switches for multicasting.


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.dcom.cell-relay
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: Another Application
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 15 Sep 1992 15:53:57 GMT

In article <318@usdoof.DaytonOH.NCR.COM>, uucp@usdoof.DaytonOH.NCR.COM (uucp administrative login) writes:
> ...
> The service user prepares an exploratory wave, sends it (via TCP/IP) to 
> the local wave launching point, lets it loose into the hotel spanning net.  
> The wave collects data back to the launching point, where it is transferred
> back to the agent.
> 
> Some few minutes later come back a series of digital brochures from a
> desktop in each hotel in the region.  
> 
> No hassle, no muss, no management, no extra layers.


As I asked last time,, if you leave out those hassles, musses, management
and layers,
  1.  how do you ensure that all of the hotels receive the query, 
  2.  how do you ensure that all of the answers get back, and
  3.  how do you ensure that you do not crash the network by asking
	something that causes every hotel in the world to answer?

Every time your system fails (1) or (2), some of the hotels will 
sue you.  (And sometimes even if your system works but travel agents
decide to consistently not use some dives.)

Every time your system fails (3), all of the hotels, all of the travel
agents, and some of the customers will sue you.


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.dcom.cell-relay,comp.protocols.misc
From: craig@sics.se (Craig Partridge)
Subject: CFP: End-System Support for High Speed Networks
Organization: Swedish Institute of Computer Science, Kista
Date: Mon, 14 Sep 1992 20:33:03 GMT


                          CALL FOR PAPERS
                End-System Support for High Speed Networks
                A Special Issue of the IEEE Network Magazine

We have seen significant increases in the bandwidth available for computer
communication networks in the recent past. We have commercially available Local
Area Networks operating at 100 Mbits/sec and research networks operating at
greater than 1 Gbit/sec. A variety of network architectures for the Local area,
Metropolitan area and Wide area networks have been proposed to take advantage ofthe high speed transmission capabilities. Processor speeds have also seen
dramatic increases at the same time. The perception is that end-user
applications which can use this high bandwidth will grow rapidly in the near
future. Network I/O at the end-system may be the next bottleneck. 

The purpose of this special issue of IEEE Network Magazine is to address the
issues in providing support in the end-system for computer networks. We would
like to see papers that are tutorial in nature addressing lessons learned
in host implementations for computer networks, as well as innovative
approaches to provide host support for emerging high speed networks. Topics
of interest include, but are not restricted to:

        - Implementation of Communication Protocols in End-Systems

        - Operating System Support for Communications
 
        - Host Architecture Issues (e.g., Workstation architecture) for
          enabling support of high bandwidth communications

        - Network Interface Design and Implementation

        - Novel ideas in protocol design to ease end-system support of
          high speed networks

        - Novel application design and implementation

Contributions: Please submit 4 copies of the complete manuscript to the guest
editor. Papers should not exceed 20 double spaced pages, and should
include an informative abstract. Please include the author's names, contact
address, phone number and if possible, e-mail address. Deadline for initial
paper submission is January 15, 1993. (Authors outside the US who need
a little extra time are encouraged to contact the guest editor).  The issue
is expected to come out in July 1993. 

Guest editor:
                Dr. K. K. Ramakrishnan
                Distributed Architecture and Performance
                Digital Equipment Corporation
                LKG1-2/A19, 550 King Street
                Littleton, MA 01460-1289.
                 
                Phone: +1(508)486-7267
                FAX:   +1(508)486-5279
                E-mail: Rama@erlang.enet.dec.com
Newsgroups: comp.dcom.cell-relay
From: miw@cc.uq.oz.au (Mark I. Williams)
Subject: Re: Legalities
Organization: Prentice Centre, University of Queensland
Date: Fri, 11 Sep 1992 00:38:48 GMT

bantha.decnet.lockheed.com!young writes:

>Legal question:

>Cell relay carries all forms of traffic, but the VAN does nothing
>special with regard to voice, the VAN simply allows  user applications
>to operate over his multi-service network.

>Is the VAN violating any law? 

Here in Botwana, that's quite ok. Dunno how you'd get on across the
border in Zimbabwe, though. 

cheers,

--
Mark Williams         The University of Queensland       miw@cc.uq.edu.au
+61 7 36 54012   (w)  Prentice Centre
+61 7 36 54477  (fax) Qld 4072  Australia
Nullum magnum ingenium sine mixtura dementiae fuit.  -- Seneca
Newsgroups: comp.dcom.cell-relay
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Re: Today's Problem
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Tue, 8 Sep 92 15:12:43 GMT

In article <187slsINNg8b@nigel.msen.com>, emv@msen.com (Edward Vielmetti) writes:
>bantha.decnet.lockheed.com!young writes:
>: 
>: Far into the future (mid 1993) server nomenclature is fading from
>: our language, being replaced by server "waves" which migrate about
>: the virtual path networks (enabled by wave interpreters at each node).
>
>Not.
>
>Mid 1993 is near future, just about "now", as far as building
>administrative tools goes.  Can you imagine trying to manage a network
>that was full of random processes that swoop down and wreak havoc on your
>disks?  And worse yet "interpreters" that could download and possibly
>execute unfriendly codes?  No way.
>
>--Ed
Any solution which solves an important set of customer problems will
be deployed.  If a major company, and can get a network 
technology which increases their ability to gather and use distributed 
information, then they're going to get that technology.

Multi-tasking operating systems, like OS/2, are now being deployed
across the desktops of a million users.  If the system manager can
deploy network wide processes to manage these things, distribute information,
perform automatic backups, execute distributed file searches, reduce
network management costs, then he will.  Whatever security problems he
sees he will get resolved with his software vendor.

The fact that these migratory processes "swoop down" and affect local 
desktops is what gives them their power. You cannot ignore power like that
for very long.
Newsgroups: comp.dcom.cell-relay
Subject: Re: ATM Ref.
From: denny@alisa.com (Bob Denny)
Date: Sat, 5 Sep 1992 03:33:59 GMT
Organization: Alisa Systems, Inc.

In <9209041009.AA03380@iti.gov.sg> bharath@iti.gov.sg 
   (Bharath Narayanan) writes:

> Since I heard that you guys at Adaptive are quite an authority in the ATM 
> area could you please post me some references to read to start with!
> Or is there any ftp site from where I can ger some material ?

I have been following this newsgroup trying to glean info as well. I am
pretty well lost. I too would like to locate some reading material.

_______________________________________________________________________________
Robert B. Denny                                           voice: (818) 792-9474
Alisa Systems, Inc.                                         fax: (818) 792-4068
Pasadena, CA                         (denny@alisa.com, ..uunet!alisa.com!denny)
Newsgroups: comp.dcom.cell-relay
From: brian@dxcern.cern.ch (Brian Carpenter   CERN-CN)
Subject: Re: Value Added Nets
Organization: CERN European Lab for Particle Physics
Date: Thu, 10 Sep 1992 14:32:26 GMT

In <1992Sep8.161334.13264@iscnvx.lmsc.lockheed.com> bantha.decnet.lockheed.com!young writes:

>... The small business needs
>the help of the value added networks to compete against the larger 
>corporations which can afford large private networks.  Does anyone know
>what value added networks are doing to provide some cell-relay integration?
>What is the Internet official position?

How can the Internet have an "official position"? There is no such thing
as the Internet in a legal sense. Maybe, when wide area ATM becomes
real, some of the service providers will implement whatever RFCs are
relevant by then. If they think they will make money that way.
But Capitalism won the Cold War so the free market will answer your
question.

  Brian
Newsgroups: comp.dcom.cell-relay
From: joydeep@iti.gov.sg (Joydeep Bose)
Subject: ATM Forum
Organization: Information Technology Institute, National Computer Board, Singapore.
Distribution: USA
Date: Tue, 8 Sep 1992 10:17:46 GMT



We are a R&D organization at Singapore involved in nonprofit technology 
research. ATM as a high speed networking with guranteed service of various
grades has interested us a lot and we have been following this news group very
eagerly.
Currently we are in the process of finalizing a gigabit testbed across the 
island for bandwidth hungry traffic including audio graphic multi-party
conferencing. (voice-video-screen sharing). As we are updating ourselves with 
ATM switches offered by different vendors, We are also interested in participat
ing in the ATM forum and gather more information/proceedings on the subject. I would appreciate any help from you on this . 
i.e 
How to become a member of the ATM forum.


warm regards

Joydeep Bose
Network Architect, 
Infrastructure Division
National Computer Board
Singapore 0511
Newsgroups: comp.dcom.sys.cisco
From: jpiquer@dcc.uchile.cl (Jo Piquer)
Subject: Re: bug in 9.0(1) ?
Originator: jpiquer@tortel.dcc.uchile.cl
Date: Thu, 10 Sep 1992 16:59:14 GMT
Organization: Universidad de Chile, Depto. de Ciencias de la Computacion


In article <Bu0urv.8xG@nntp-sc.Intel.COM>, skishen@xanadu.intel.com (Sunil Kishen) writes:
>
>In article <9208311703.AA02736@mrbean.scd.ucar.edu>,
>hyder@niwot.scd.ucar.EDU writes:
>|> >> Recently we discovered strange behaviour in 9.0(1).
>|> >> We route tcp/ip decnet and appletalk and bridge LAT in a 
>|> >> newly installed MGR. 
>|> >> ARP requests done on lan-s connected to this router are
>|> >> FORWARDED to all interfaces! Even worse, since they are
>|> >> forwarded to a AGS with 8.3(3), the AGS has no way of
>|> >> protecting himself, but instead the AGS will put the ARP-s
>|> >> to all of hi's interfaces. In one case he substituded the
>|> >> original ip-address with the AGS ip-address.
>|> >> ...
>|> 
>|> We have also seen some very troubling ARP related problems in
>|> 9.0(1).  At this time we are using an ftp'd copy of 9.0(1.10)
>|> that seems to solve the problems.  My advice would be if you use
>|> bridging don't use 9.0(1).
>|> 
>
>Way back in June 92, I had seen this Arp-reply problem occur in 8.3(1) 
>and 8.2(5) GS3-BF(bridging) and we had a Cisco engineer come on site and 

    We have a problem that is maybe related to this ARP bug. The
situation is a Cisco Router on a LAN connected by DEC bridges to
other LAN's. The Cisco ARP's packets are only heard on the local cable.
However, the other machine's ARPs do propagate correctly. What's
special about CISCO ARP's packets? Anyone have heard about this before?

    Thanks, 
	Jose' Piquer (jpiquer@dcc.uchile.cl)
From: pcorless@cisco.com (Peter Corless)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: SMDSs & cisco
Date: 27 Aug 92 04:42:34 GMT
Reply-To: pcorless@cisco.com (Peter Corless)
Organization: Computer Science Lab, SRI International
X-Disclaimer: The views expressed in this message are those of an
	      individual at SRI International, and do not necessarily
	      reflect those of the company.


In response to the following post:
From: battle@umbc4.umbc.edu (Rick)
Subject: SMDSs & cisco

> Are there any cisco models which will not support SMDS?
> I know the AGS+ is ok, what about the rest of the product line?

All current models of the AGS+, AGS, MGS, CGS, IGS, and Cisco 3000 support
SMDS, as long as they are using Software Release 8.3 or 9.0. They can
either use a CSC-MCI or CSC-SCI (with RS-449 applique), an HSSI interface
(in the AGS+ only), or an RS-449 transition cable (for an IGS or 3000 model).

At your service!

-Peter Corless.
 Cisco Customer Service
 US Federal Region Representative
 --------------------------------
 e-mail: pcorless@cisco.com
 phone:  (415) 903-8723
 fax:    (415) 903-8080
Newsgroups: comp.dcom.sys.cisco
From: rh0083b@medtronic.COM (Roger-Hunen)
Subject: Re: Subnetting and class B nets
Organization: Medtronic, Inc.
Date: Mon, 14 Sep 1992 07:31:59 GMT

In article <199208271311.AA25618@spot.Colorado.EDU> HANK@VM.BIU.AC.IL (Hank Nussbacher) writes:
>
>    I am sure someone has already solved this problem since it seems
>like a very  common problem.  Suppose  you have one  class B address
>(i.e.  132.64.x.x)  and  have   about  120  small  units   scattered
>throughout the USA with each around 20-30 systems connected.  Now in
>order to interconnect all these  subnets of 132.64.x.x we use  cisco
>routers with many lines.   We want to use  the same class B  net for
>the  lines  and  not  some  other  network,  since  that would break
>subnetting rules (you  are not allowed  to seperate two  segments of
>the same class B via a segment of some other class C or B network).
>
>    So we choose a subnet  mask of 255.255.255.0 for the  individual
>units  and  for  the  lines  we  would  like  to  use something like
>255.255.255.248.  This  way we  get greater  efficient use  from the
>address space, rather than wasting an entire 256 address range space
>for each leased line.  If we have 120 lines, we could end up wasting
>132.64.1.x-132.64.120.x leaving just about 50% of the address  space
>for real work.  Packing the addresses for the leased lines into  one
>segment of the class B network - such as 132.64.1.x makes sense  and
>should work.  But  for some reason  (perhaps some subnetting  rule),
>the cisco will  to not accept  two *different* subnet  masks for the
>same class B  network.  The cisco  automatically changes the  subnet
>mask for all interfaces with the same class B network address to the
>last subnet mask of the last interface set.
>
>I am sure there must be some config command to bypass this problem.
>Or is everyone wasting oodles of address space on their leased line
>subnets?

We use 'ip unnumbered' on the serial links, which prevents the serial
links from eating subnets.

>Thanks,
>Hank Nussbacher

You are welcome.

Regards,
-Roger
(I speak for myself)

Newsgroups: comp.dcom.sys.cisco
From: nthappe@netman.intel.com (Naren Thappeta st3-17 408-765-3488)
Subject: Re:  delete me from this address
Date: 10 Sep 92 16:39:43 PDT


Please delete me from the list also.

Naren
Newsgroups: comp.dcom.sys.cisco
From: simpsong@dns0.bham.ac.uk (Glyn Simpson)
Subject: Advertising Static routes 
Date: Mon, 07 Sep 1992 15:59:35 GMT
Reply-To: G.Simpson@bham.ac.uk
Organization: The University of Birmingham, England
X-Newsreader: Tin 1.1 PL5

Can anyone tell me out there whether it is possible to advertise static
routes which have:
	1. Been defined as secondary addresses on an interface
	2. Been defined using the 'IP ROUTE' command and a weight.

I've tried and tried this, and am coming to the conclusion that its not
possible.

We've got an AGS+ running software version 8.2 (7). The routes I am
trying to advertise are subnets of a network - i'd like to redistribute these
addresses to the other subnets.

Thanks in advnace.

--
Glyn Simpson, Systems Officer,  //  Voice: +44 (0) 21 414 6575
University of Birmingham        //  Fax:   +44 (0) 21 414 3952
Email: G.Simpson@bham.ac.uk     //  NIC Handle: GS56
Newsgroups: comp.dcom.sys.cisco
From: Jim O'Shea <jwo@hpuerca.atl.hp.com>
Subject: MGS "hangs" on reload
Mailer: Elm [revision: 64.9]
Date: 8 Sep 92 17:50:15 EDT


I have been working on a problem where a MGS appears to hang if a reload
command is issued. It is NOT NETBOOTING. A Power OFF/ON resolves this 
every time. From the data we have been able to gather is that the LED on
the front of the chassis is out (however, our source isn't 100% reliable).

There was not a modem or terminal connected to the console port to further
aid verification of the state or gather any messages that might have helped.
There will be for the next time, I was however, hoping for some thoughts 
as to what the problem might be. It operates just fine (once it is booted).

The boards in system are:

GS3-BF
8.2(5)

slot1 - empty
slot2 - CSC/3
slot3 - CSC-2E
slot4 - CSC-2E

Any ideas are welcome. Thanks       


--
Jim O'Shea
jwo@hpuerca.atl.hp.com
404 850-2675
Newsgroups: comp.dcom.sys.cisco
From: Dan Clohossey <dclohoss@cisco.com>
Subject: delete me from this address
Date: 10 Sep 92 12:56:06 MDT
X-Mailer: ELM [version 2.3 PL11]

can whoever maintains this remove me, please.  sorry for the junk mail, but 
I can't seem to get myself off this mailing list.
Newsgroups: comp.dcom.sys.cisco
From: Richard.Rosenlund@eua.ericsson.se (Richard Rosenlund)
Subject: Program/script wanted
Date: 9 Sep 92 09:34:59 +0200

Hi,

does anyone have a script/program that can be used to explore and write
a (postscript) file/map based upon routing tables?

The purpose is to run "it" and get a "snapshot" of what networks are
that are "visible".

Thank you

Richard
Newsgroups: comp.dcom.sys.cisco
From: corbato@cosmic.physics.utah.edu (Steve Corbato)
Subject: Re: bug in 9.0(1) ?
Summary: Should we wait for 9.0(2)? 
Organization: Cosmic Ray Physics Group, University of Utah
Date: Fri, 11 Sep 92 22:30:17 GMT

I've not really been following this thread over the last few weeks, but now
in order to acquire TCP/IP packet type prioritization, we would like to
upgrade our two Cisco boxes from 8.2(3) rather quickly.

We have a relatively simple configuration -- two remote boxes connecting
two Ethernet LAN's with 56 kbaud serial lines, supporting TCP/IP and
DECnet, and routing the former via IGRP.

Are the bugs found in 9.0(1) sufficient to delay upgrading until the next
release or even staying at 8.3 level for this purchase?  Is there any
consensus on this out there?

Thanks, 
-- 
Steve Corbato		          corbato@cosmic.physics.utah.edu (Internet)
Cosmic Ray Physics Group          utahco::corbato, 47623::corbato (HEPnet, NSI)
Physics Dept., Univ. of Utah      corbato@utahcca (BITnet)
Salt Lake City UT 84112 USA       (801) 581-5053 (office), -4801 (Fax)
From: bav@hobbes.ksu.ksu.edu (Brick Verser)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: AGS+ pauses for 800ms every 30 seconds
Date: 5 Sep 1992 21:39:56 GMT
Organization: Kansas State University
Distribution: world
NNTP-Posting-Host: hobbes.ksu.ksu.edu

In article <lafo7rINNqp1@skat.usc.edu> tli@skat.usc.edu (Tony Li) writes:
>In article <184ee4INNimp@moe.ksu.ksu.edu> bav@hobbes.ksu.ksu.edu (Brick Verser) writes:
>    We've got an AGS+ running Version 8.2(7) which seems to pause every 30 
>    seconds.  Seems likely this is RIP updates, but it seems unlikely that 
>    the router should do absolutely nothing else for that period.  Is there 
>    a simple configuration change that we've overlooked which will make this 
>    all better?
>    
>Responding to Ping packets is a relatively low priority process within
>the router and is not really a good measure of what the router is
>doing.  You should try pinging through the router to see what it is
>really doing.

That is, in fact, what I was doing.  NO packets go through the router, as 
best I can tell, when this is happening.

I've partially solved the problem by turning off the advertising of MIDnet
routes on campus, which reduces the number of nets being RIPped from 300
to about 30.  So now the router pauses only 80ms every 30 seconds.  Much
better, but still bothersome.  I would prefer to fix the Ciscos' scheduler.
Guess a phone call to them is in order.

--Brick
Newsgroups: comp.dcom.sys.cisco
Subject: Software versions
From: graeme@ccu1.aukuni.ac.nz ( Graeme Moffat)
Date: Thu, 10 Sep 1992 09:23:55 GMT
Organization: University of Auckland, New Zealand.

Hi, we just received a new AGS+ this afternoon. The software is GS3-BF
8.3(3). When I was discussing our order with the salesman, he mentioned that
s/w would be 9?  Our computer centre has a 2 month old AGS+ at 9.0(1)
(admittedly it's got csc/4, cbus & MEC cards). Am I misguided in expecting
the latest version, or doesn't it matter? I will ask our rep, of course, but
thought I'd solicit opinions here as well.
TIA

-- 
Graeme Moffat                g.moffat@aukuni.ac.nz \ Time wastes us all, 
Computer Aided Design Centre,  Fax: +64-9-366-0702 /  our bodies & our wits
School of Engineering,    Ph: +64-9-737-999 x8384 /  But we waste time,
University of Auckland, Private Bag, Auckland, NZ \   so time & we are quits
Newsgroups: comp.dcom.sys.cisco