Path: utzoo!attcan!uunet!samsung!dali.cs.montana.edu!uakari.primate.wisc.edu!uflorida!gatech!rutgers!aramis.rutgers.edu!athos.rutgers.edu!hedrick From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.appletalk Subject: Re: Campus AppleTalk Internet Strategies Message-ID: Date: 25 Oct 90 22:51:43 GMT References: <722@casbah.acns.nwu.edu> <1990Oct23.015216.22601@cs.umn.edu> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 41 My preference is to move away from IPTalk to Ethertalk. My primary concerns are - that I want to put Ethernet cards in Macs, and that means they are going to run Ethertalk. Commercial Unix and VMS software also runs Ethertalk. IPTalk is fine if all you have is Localtalk, and need a way to connect Localtalk networks. But I don't think we're going to be able to deal with Localtalk bandwidth for long. As we move to Ethertalk, it makes more sense for our main routers to route Ethertalk as well as IP. - routing in mixed IPTalk/Ethertalk setups is obscure. You have Appletalk and IP routing protocols interacting in strange ways. Thus we are moving to use of Ethertalk for the main campus backbone. Fortunately all of our main routers are ciscos, which support Ethertalk. In some ways I prefer the IPtalk protocol, but since most products for Ethernet use Ethertalk, I don't see how we can stick with IPtalk forever. I haven't seen any problems with Ethertalk phase 1 in cisco's 8.1 release. 8.2 is still in beta, so I can't comment on it, but I certainly don't anticipate letting them take it out of beta without functional Ethertalk phase 1 and 2. The major Appletalk developer at cisco seems pretty good, and he seems to be in contact with the Appletalk developers at Apple to make sure everything is done in an approved manner. The IPtalk/Ethertalk transition is not without its problems. I think some of my colleagues are less than enthusiastic. I'm still doing a bit of tweaking of the CAP Ethertalk support. The big problem is that CAP Ethertalk has to use system-dependent facilities, so porting it to many kinds of Unix is going to be a lot harder than porting the original CAP. (It has to use system-dependent facilities because there is no standard way to ask a Unix system to give you all Appletalk packets addresses to a sort Appletalk port number. You end up either installing the packet filter software in the kernel or using some generic network hook, typically intended by the vendor for packet monitoring.)