Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site decwrl.DEC.COM
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!dec-rhea!dec-oracle!waters
From: waters@oracle.DEC (Greg Waters, 225-4986, HLO2-1/J12)
Newsgroups: net.lan
Subject: LAN terminology poll
Message-ID: <1236@decwrl.DEC.COM>
Date: Wed, 19-Feb-86 12:48:14 EST
Article-I.D.: decwrl.1236
Posted: Wed Feb 19 12:48:14 1986
Date-Received: Fri, 21-Feb-86 04:28:29 EST
Sender: daemon@decwrl.DEC.COM
Organization: Digital Equipment Corporation
Lines: 26

I don't know why I'm contributing my 2 cents, because I'm an "expert" and
not an Expert.  Maybe some day when I grow up I can be just like....

Sounds to me like most people think of a bridge as protocol transparent at
the data link level.  NO messing with "immediate source addresses."  One
can indeed build a smart bridge that appears to route, but puts the routing
hooks in BELOW the data link information that is provided to higher layers.
On Ethernet, this out-of-band information would have to be implemented as
network management packets communicated between the Bridges.  As I understand
our Ethernet bridge product, it's normal mode of operation is that of a "dumb"
bridge, not a "routing" bridge, so it cannot tolerate cycles and hot standbys
without that net management stuff.

A "bridge" that messes with the data link information to effect routing is
operating at the transport layer, not the data link layer, if I understand
those layer terms.  Shouldn't such a device be called a "router", or perhaps
a "routing bridge"?

I totally agree with Skip's definitions of Repeater and Gateway.
I say again that I'm not an Expert, and further, that I don't recall the
details of optional configurations of our Ethernet bridge product.  Therefore,
I may have misrepresented it.

Greg Waters, DEC/Hudson,MA
...!decvax!decwrl!dec-rhea!dec-oracle!waters
"This message will self-destruct in five seconds..."