Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!ogicse!milton!ns.uoregon.edu!duff.uoregon.edu!jqj From: jqj@duff.uoregon.edu (JQ Johnson) Newsgroups: comp.protocols.appletalk Subject: Re: ATP2 bridging (was Phase 1 vs. Phase 2) Message-ID: <1991Jan25.173426.1169@ns.uoregon.edu> Date: 25 Jan 91 17:34:26 GMT References: Sender: news@ns.uoregon.edu Reply-To: jqj@duff.uoregon.edu (JQ Johnson) Organization: University of Oregon Network Services Lines: 49 Robert Elz writes: >It seems to me that the FDDI bridge vendors are taking obscene liberties >with ethernet packets - and won't only be breaking phase 2 appletalk, >but also anyone using RFC1042 format IP packets as well. As Bob Morgan notes, the bridge vendors' algorithm for "transparent" bridging of Ethernet frames onto 802.x media was designed PRECISELY to allow RFC1042 (and RFC1103) interoperation. That's about the only thing it's good for. Also as Bob notes, the expectation is that hosts will figure out a reasonable MTU. For Host->Ether<->FDDI<->Ether<-Host there is obviously no problem. For IP hosts directly connected to an FDDI network, the expectation is, I think, that they will use the Ethernet MTU rather than the larger FDDI MTU at least until bridges support the new MTU Discovery mechanisms (which opens up a whole 'nother) can of worms since it means that bridges have to be even more like IP routers (what's next? Decrementing TTL?). It should be noted that there is currently *no* standardization effort being devoted to such semi-routers. Note that this set of problems is present in any heterogenous transparent bridge, e.g. in Ethernet to token ring. What's really troubling is that they *almost* work, which makes it more likely that the gullible will buy them only to be disappointed later. Bob argues that the realities of the situation dictate that DEC and other mixed-media transparent bridge vendors should modify their "bridges" to support Appletalk II. He's right. But they may not; Bob and I have been unsuccessfully trying to convince the bridge vendors to make the change ever since he tried one of those bridges and found that in fact it didn't work with Phase II. Just as there is an installed Phase II base, there is now an investment in these bridges. At least in the DEC case, the proposed modification would probably have to change the implementation in 2901 bitslice. It's not as easy as just sending out a new software release! That's why I believe that we as users should be beating on both the bridge vendors AND Apple to make changes that will let things work a bit better. Bottom line: I think we all agree that heterogenous bridges are a real problem, particularly in complex environments, and most particularly in Appletalk Phase II environments. It's probably time to move this discussion off comp.protocols.appletalk. -- JQ Johnson Director of Network Services Internet: jqj@oregon.uoregon.edu University of Oregon voice: (503) 346-4394 250E Computing Center BITNET: jqj@oregon Eugene, OR 97403-1212 fax: (503) 346-4397