Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!CERNVAX.BITNET!kik From: kik@CERNVAX.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Response to anti-bridge comments Message-ID: <460@cernvax.UUCP> Date: Mon, 6-Apr-87 02:26:02 EST Article-I.D.: cernvax.460 Posted: Mon Apr 6 02:26:02 1987 Date-Received: Wed, 8-Apr-87 00:20:19 EST References: <8704022034.AA09965@ucbvax.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: cernvax!kik () Distribution: world Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Sw Lines: 29 Keywords: Bridge, network, load sharing Approved: tcp-ip@sri-nic.arpa I get the impression that, in the discussion on Bridge functionality, people are not taking enough trouble to distinguish between the *service* and the *communications*. The service is to filter and forward, based on destination address. There is no reason for the filtering not to be shared, in a disjoint way, by any number of devices. In fact, we intend to do this. The load-sharing and backup algorithms are designed and we plan to implement them on our own equipment once we get the time. The communications can be based on point-to-point links, satellites, etc. In fact, the choice of communications is limited only by your networking ability. For example, DEC and Vitalink have "invented" a spanning-tree approach to provide redundant communcation. This is really primitive. We, at CERN, use a genuine communications subnet with all of the build-in advantages (originally designed for inter-computer traffic, and all the better for that!). The ideal backbone for such purposes would be a high-speed bus-type network (we're hoping for FDDI). I am trying to rewrite the IEEE 802.1 document on MAC-level bridges to reflect the clear separation between a) address resolution and b) routing so that the current confusion can be avoided. Cheers Crispin PINEY