[mod.protocols.tcp-ip] Response to anti-bridge comment

jon@CS.UCL.AC.UK.UUCP (03/31/87)

/* Written  8:22 am  Mar 31, 1987 by kincl%hplnmk@com.hp.hplabs in pyr1:tcp-ip */
/* ---------- "Re: Response to anti-bridge comment" ---------- */
Received: from ucl-cs-nss by pyr1.Cs.Ucl.AC.UK   with SMTP  id aa05565;
          31 Mar 87 8:21 WET
Received: from sri-nic.arpa by mv1.Cs.Ucl.AC.UK   via Satnet with SMTP
           id aa05190; 31 Mar 87 8:20 WET
Received: from hplabs.HP.COM by SRI-NIC.ARPA with TCP; Mon 30 Mar 87 10:27:05-PST
Received: from hplms1 by hplabs.HP.COM with TCP ; Mon, 30 Mar 87 10:25:06 pst
Received: from hplnmk (hplnmk) by hplms1; Mon, 30 Mar 87 10:24:38 pst
Return-Path: <kincl@hplnmk>
Received: from hplnmk.hpl.hp.com by hplnmk ; Mon, 30 Mar 87 10:29:16 pst
Message-Id: <8703301829.AA06404@hplnmk>
To: "Phil R. Karn" <karn@com.bellcore.flash>
Cc: tcp-ip@arpa.sri-nic
Subject: Re: Response to anti-bridge comments
In-Reply-To: Your message of Thu, 26 Mar 87 15:20:26 -0500.
             <8703262020.AA27749@flash.bellcore.com>
Date: Mon, 30 Mar 87 10:29:13 PST




Question:  How well would all this work if you decided that you need
redundant routes or if you decided that you do not want a start topology
but have an arbitrary topology?  Can you have a configuration like the
following:

        ---------------Ethernet-----------------
               |                       |
               |                       |
             Bridge                  Bridge
               |                       |
               |                       |
        ---------------Ethernet-----------------
               |                       |
               |                       |
             Bridge                  Bridge
               |                       |
               |                       |
        ---------------Ethernet-----------------

Yes, but.

At UCL we run a mini internet with 5 sites interconnected by
Megastream (thats 2.Mbps not T1) lines. We also run a lot of
LAN technology, mostly ethernet. We reckon that it's swings and
roundabouts whether we use MAC Bridges or Network Level relays
(to use ISO jargon). TYhere is an emerging (ISO!) standard for MAC
bridges, and the only thing it is waiting on is how to do loop
resolution and access control (ie the things most people think
are network level things, but ISO are beginning to concede are
different in a LAN/MAN context).

Anyway, its down to
1. performance
2. functionality
   a) traffic control
   b) Fault Isolation
   c) routing/loop resolution
   d) access control
   e) management of all this.

There's absolutely no reason to get layerist about this. if the
addressing and protocols can stand it, there's nothing to
choose between MAC bridges and network lewvel relays if they
happen to do the same job as well. broadcast/multicast limiting
can be done if you use distributed nameservers (and arp klugery
is not a hack, it can be managed properly as a ditributed
multicast system in MAC bridges if you implement it).

two asides:
1. MAC bridges also buy you more trustworthy access control, since
it's harder to spoof physical address without being spotted
than to spoof IP/network level address, specially if you dont
buy the wrong LAN.
2. MAC bridges usually perform, better - eg NFS works through
them - you have to kludge the silly numbers in the mount
table to get it to go even through a cisco box - one of the
better IP gateways around.

We use network level relays (IP gateways) between sites over
the megastream, and predominantly MAC bridges within sites. The
choice seems to have made sense in terms of managing the
system, but I suspect that we just got good hardware and
software, and that's what counts in the end.