Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!NRL-LCP.ARPA!bill From: bill@NRL-LCP.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Response to anti-bridge comments Message-ID: <8704022034.AA09965@ucbvax.Berkeley.EDU> Date: Thu, 2-Apr-87 15:19:00 EST Article-I.D.: ucbvax.8704022034.AA09965 Posted: Thu Apr 2 15:19:00 1987 Date-Received: Sat, 4-Apr-87 16:01:30 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Distribution: world Organization: The ARPA Internet Lines: 59 Approved: tcp-ip@sri-nic.arpa > Date: Tue, 31 Mar 87 15:33:29 EST > From: jas@monk.proteon.com (John A. Shriver) > Subject: Response to anti-bridge comments > 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). I don't think it's anything intrinsic about a Bridge that would prevent you from doing load sharing. It's only a function of the current Bridge software that this isn't currently possible. One simple scheme that I just happened to think of off the top of my head would involve having 2**N Bridges numbered from 0 to 2**N-1, and each Bridge would handle those Ethernet addresses which modulo 2**N matched its own assigned Bridge number. A hot spare could detect the failure of any particular live Bridge, and take over for it. One Bridge could be designated to handle broadcast packets. Does anyone know if such a scheme or anything similar has been considered for doing load sharing across Bridges? It doesn't seem that it would be that difficult to implement. By the way, in practice, at least at our site, the level of traffic through our Ethernet Bridges is nowhere near significant enough to even start to worry about load sharing, and we have a fairly extensive Ethernet based network in active use here at NRL. > 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. Although Gateways/Routers COULD also do load sharing with appropriate routing algorithms, it is my understanding that all of the current Gateways, even those with SPF routing, DO NOT currently do any kind of load sharing, and only understand and compute a single path to any given destination. I specifically asked this question at the TCP/IP Interoperability Conference held just recently in Monterey, and that was the answer I was given by someone involved with the SPF routing Gateways. > What the advocates are arguing about is where the line between bridges > and routers is. I think there are appropriate circumstances to use both Bridges and Gateways/Routers. The primary benefits that I see for using Bridges, given the state of current technology, is ease of installation, monitoring, and management, and the fact that they are protocol transparent to the higher layer protocols. In the future, they will probably even be used to connect dissimilar technologies, such as Ethernet and FDDI Fiber Optic networks. But Gateways certainly have their appropriate niche also, such as providing a higher degree of isolation between the connected networks when this is desirable. -My first plunge -Bill Fink bill@NRL-LCP ------