[mod.telecom] ARPANET Routing Non-Redundant

wmartin@ALMSA-1.ARPA (Will Martin -- AMXAL-RI) (12/17/86)

The following item just appeared on the RISKS Digest. I thought it
was worthy of forwarding to Telecom, since it brings up trunk-routing
issues:

> Date: Mon, 15 Dec 86 10:46:48 EST
> From: Andrew Malis <malis@ccs.bbn.com>
> Subject: Arpanet outage
> To: hedrick@topaz.rutgers.edu
> Cc: tcp-ip@sri-nic.arpa, malis@ccs.bbn.com
> 
> [An earlier message asked, "Why did the Northeast corridor disappear from
> the Arpanet last weekend? The Network Operations Center said one trunk had
> been broken, and they were cut off from most everyone, too. I thought there
> was enough redundancy in the Arpanet to prevent a single trunk from causing
> such extensive outage...":]
> 
> At 1:11 AM EST on Friday, AT&T suffered a fiber optics cable break between
> Newark NJ and White Plains NY.  They happen to have routed seven [different]
> ARPANET trunks [all] through that one fiber optics cable.  When the cable
> was cut, all seven trunks were lost, and the PSNs in the northeast were cut
> off from the rest of the network.  Service was restored by AT&T at 12:12.
> 
> The MILNET also suffered some trunk outages, but has more redundancy, so it
> was not partitioned.
>                                            Andy Malis
> 
>    [Robert W. Baldwin <BALDWIN@XX.LCS.MIT.EDU> noted:  This is a classic
>    example of redundancy at one level of abstraction that turns out to be
>    non-redundant at a lower level of abstraction.]
>       [Redundancy works sometimes: I received several copies of Andy's
>       note.  Yes, this is a lovely example.  By the way, AT&T is laying a
>       fiber-optic cable under the Atlantic.  That will provide LOTS of
>       opportunities for virtually distinct paths to co-occupy the same
>       physical channels.  PGN]

It appears from the above that the MILNET desiners/maintainers took
more care, or spent more money, related to the physical routing and
actual physical redundancy -- this is logical for a military operational
or production network, of course, and probably the extra costs could not
be justified for a research net like the ARPANET. However, as I
understand the tarriffs and how the long-line vendors sell their
circuits to users, there is little, if anything, that a buyer could do
to prevent the vendor from changing the physical circuits "behind" the
logical or virtual circuit you are buying and eliminating physical
redundancy that the customer thought he had. That is, you could design a
network, and buy circuits, with actual physical redundancy for your own
protection, but the telco could at some future date "streamline" its
facilities and put your two originally-separate circuits on the same new
physical link, without your ever even knowing about it or having any
recourse or means to protest this action. Anyone have any comments about this? 

Will Martin

pozar@lll-lcc.ARPA@well.UUCP (12/22/86)

   This brings up a problem that I had with pa bell (Pacific) at the station
that I work with.  I had ordered a main and a back-up data (2003) line between
our studios and our transmitter site.  I installed a automatic switch that 
would flip between the lines in case of failure.  Little did I know that for
the most part of those lines they were routed through different C.O.s but for 
a kilometer section by Golden Gate Park.  Amazing what a back hoe can do...
   I had pa bell reroute one of the lines, and installed a remote control that
I can bring up through a dial-up circut.

	   Tim Pozar
UUCP       pozar@well.UUCP
FIDO       125/406
USNail     KLOK-FM
	   77 Maiden Lane
	   San Francisco CA 94108