Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!mintaka!ogicse!cs.uoregon.edu!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: <1991Jan23.192010.12634@ns.uoregon.edu>
Date: 23 Jan 91 19:20:10 GMT
References: <1991Jan17.205340.11378@pbs.org> <48241@apple.Apple.COM> <29515@usc> <48379@apple.Apple.COM> <1991Jan23.142109.21188@bwdls61.bnr.ca>
Sender: news@ns.uoregon.edu
Reply-To: jqj@duff.uoregon.edu (JQ Johnson)
Organization: University of Oregon Network Services
Lines: 53

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