Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!sri-spam!ames!ucbcad!ucbvax!MONK.PROTEON.COM!jas
From: jas@MONK.PROTEON.COM.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Response to anti-bridge comments
Message-ID: <8703312033.AA26906@monk.proteon.com>
Date: Tue, 31-Mar-87 15:33:29 EST
Article-I.D.: monk.8703312033.AA26906
Posted: Tue Mar 31 15:33:29 1987
Date-Received: Thu, 2-Apr-87 01:45:24 EST
References: <8703301843.AA24737@flash.bellcore.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 13
Approved: tcp-ip@sri-nic.arpa

Phil, your message does not exactly answer Norman's question.  Most
(not all) bridge vendors have loop detection algorithms that allow you
to have hot-standby bridges.  However, they are only hot-standby
bridges.  The very nature of bridges prevents you from doing load
sharing (unless you manually program the filtering/forwarding
databases, giving up the advantages of adaptive bridges).  Gateways
with multipath internal routing algorithms can do load sharing, look
at BBN's PSN software using SPF on the ARPANET and MILNET.  Sooner or
later, a network gets big enough and complicated enough that one
migrates from bridges to routers.

What the advocates are arguing about is where the line between bridges
and routers is.