bschmidt@bnr.ca (Ben Schmidt) (01/23/91)
In article <48379@apple.Apple.COM> hayes@Apple.COM (Jim Hayes) writes: >You cannot easily BRIDGE Phase II over FDDI... That's our fault not the >bridge vendor's. > >[SHORT and LONG STORIES omitted...] > >CONCLUSION: > >Bridge manufacturers should agree on a way to correctly recognize this >packet and reconstitute it on the other end. You can tell a Phase I >AARP from a Phase II AARP by looking inside the packet. The network >number will always be zero in Phase I, and always non-zero in phase >II. BEEEEEEP!!! Wrong answer! Next contestant, please! :^) (Let me get this straight. Apple broke it. But everyone else (the bridge guys) should have to fix it!? Has Jim Hayes, a refreshing breath of reality from Apple on the net, been kidnapped by Apple Marketroids and beaten into submission on the company line!? Don't touch that News Reader dial! Enquiring minds need to know!) >I don't think there is an easy way to "fix" the Phase II spec. in this >regard. True enough. It's always better to do it right the first time. :^) But I'd rather Apple fix this AARP kludge. Even if it means swallowing another set of router upgrades! That's better IMHO than going through special-casing every out-of-spec anomaly on every protocol we have to "support" on every piece of network hardware, especially on bridges which are supposed to be "transport independent". I thought that's why we (the vendors & the customers) subscribe to standards anyhow? :^) :^) Ben Schmidt Bell-Northern Research, Ltd. Ph: (613) 763-3906 Information P.O. Box 3511, Station C FAX:(613) 763-3283 Technology Ottawa Canada K1Y 4H7 bschmidt@bnr.ca /* The nice thing about standards is that there are so many to choose from */
jqj@duff.uoregon.edu (JQ Johnson) (01/24/91)
Jim Hayes writes: >Bridge manufacturers should agree on a way to correctly recognize this >packet and reconstitute it on the other end. Ben Schmidt writes: >BEEEEEEP!!! Wrong answer! Next contestant, please! :^) >I'd rather Apple fix this AARP kludge. Even if it means swallowing >another set of router upgrades! I agree with Ben, of course. After all, I think I was the first poster to say on the net that we'd actually tried it and that Phase II Appletalk was *broken* through FDDI bridges :-). But it isn't as easy as just changing routers. All EtherTalk macs need to be upgraded since existing Phase II Macs won't recognize AARP packets that have been munged by bridges. Luckily, there IS a reasonable upgrade path. Apple should release a new version of the Phase II EtherTalk drivers that recognize all of the following as Phase II AARP: a. 802.3/SNAP/AARP with SNAP vendor ID=0 *and* network != 0 b. Ethernet (i.e. non 802.3) AARPs with network != 0 c. 802.3/SNAP/AARP with SNAP vendor ID=0x080007 This interim release would continue to generate old-format Phase II AARPs. FDDItalk drivers would only need to recognize a and c, of course. Any Phase I FDDItalk driver (I don't think such things exist) would have to be modified to recognize only 802.2/SNAP/AARP with vendor ID=0 *and* network == 0. Macs with this driver would then be able to see the other side of a bridged network, even if their correspondent generated old-format Phase II AARPs and the bridge translated them into Ethernet packets of type b. After a sufficient period, another release of the Phase II EtherTalk drivers would change the format of the *generated* AARPs to use format c above. The result: FROM\TO current driver interim driver final driver current driver no bridge works works interim driver no bridge works works final driver does not work works works I.e. "interim drivers" would interoperate with the current driver, but two interim drivers could see each other across an FDDI bridge. Having drivers in the field that worked with the proper format would then allow generation of the proper format at a later date. 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
hayes@Apple.COM (Jim Hayes) (01/24/91)
JQ Johnson and Ben Schmidt (along with others) say the Apple should fix the Phase II AARP problem, not bridge manufacturers. Ben Schmidt writes: >BEEEEEEP!!! Wrong answer! Next contestant, please! :^) >I'd rather Apple fix this AARP kludge. Even if it means swallowing >another set of router upgrades! JQ writes: >I agree with Ben, of course. After all, I think I was the first poster to >say on the net that we'd actually tried it and that Phase II Appletalk was >*broken* through FDDI bridges :-). But it isn't as easy as just changing >routers. JQ Then goes on to explain how Apple could upgrade the EtherTalk drivers to do AARP properly, etc. And in fact it is a reasonable solution to the problem as it applies to Apple equipment. But what about Shiva? Cisco? NRC? The MultiGate folks? NetWay? Wellfleet? AT&T? Northern Telecom? Cayman? IPT? Sony? Sequent? GO? etc.? If Apple updates its AARP code, the above folks (plus many many more) must also update their code. At this point your might as well call it Phase II++ or Phase II.1. Since this whole issue really started with the advent of FDDI bridges (relatively new) and the problem can be corrected in the bridges by testing two bytes for zero, why don't FDDI bridge vendors implement the correction? To me this is a selling point. As a network manager, I perform a few FCO's to my bridges in the form of a ROM change or some new PALs or microcode and I'm done. I'm not trying to defend Apple (sometimes an uphill battle) and my views really don't reflect Apple's (because they have not taken a stand on this issue), but this solution is a win for people wanting to bridge Phase II over FDDI: * Little down time fully under the control of network mangement. * No user software changes. * $$$ Savings in terms of all the user upgrades that didn't have to be done and the down time that didn't occur because of it. I dunno, maybe I have been kidnapped by Marketing-- but don't let that stop the discussion. I am feeding the *problem* back into product developement/marketing and not my personal views regarding the solution. -- Jim Hayes, Network Manager (I manage the hardware, not the network group) Engineering Network Services, Apple Computer Inc. Inet: hayes@apple.com UUCP: {amdcad|decwrl|ames}!apple!hayes
morgan@JESSICA.STANFORD.EDU (RL "Bob" Morgan) (01/25/91)
Regarding the suddenly revived bridging-AT2-over-FDDI controversy, I offer two comments: 1. Anyone considering the relative difficulty of implementing JQ Johnson's solution (two revs of drivers on zillions of machines whose users can't possibly understand the problem) versus Jim Hayes's solution (a rather modest hack on a small number of bridges) would have to agree that this is one case where justice (ie, Apple should fix it, because they broke it) just isn't practical. 2. As I noted when this first came up last June, fixing AT2 AARPs is only one more small hack in a vast swamp of obscure, nasty kludges that designers of FDDI-Ethernet bridges (or any other heterogeneous-LAN bridges) will have to do to make this fundamentally wrong idea saleable. My expectation is that eventually they (or their customers) will give up and use routers for this purpose instead. - RL "Bob" Morgan Networking Systems Stanford -------
morgan@JESSICA.STANFORD.EDU (RL "Bob" Morgan) (01/25/91)
Robert Elz writes: > my original 1042 packets are going to appear > on that far ethernet in rfc984 format (ie: standard IP over ethernet), > which doesn't sound much like as if the packets are being "bridged", > I'd describe it as "mangled". Well, the justification from the IP world's point of view is in Host Requirements (RFC-1122), which says that IP hosts MAY choose to send and receive RFC-1042 frames on Ethernet, but MUST receive RFC-984 properly. Which is to say, RFC-1042 is doomed to not be used, on Ethernets. > the MTU of FDDI is much larger than ethernet > ... > or these "bridges" start fragmenting packets as they're sent onto > ethernet. I dimly recall hearing that some bridge vendor was proposing to do IP fragmentation in the bridge, which truly boggles the mind. Otherwise, I think the only answer is "the host has to figure out how to do the right thing," ie use the right frame length for the right destination. > lets condemn these bridges to a long and lingering death Or maybe even short and painless, like some wars are supposed to be . . . - RL "Bob" Morgan Networking Systems Stanford -------
jqj@duff.uoregon.edu (JQ Johnson) (01/26/91)
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