Re: EARP proposal
Vernon Schryver <vjs%rhyolite.wpd.sgi.com@sgi.com> Fri, 30 November 1990 17:32 UTC
Received: from MERIT.EDU by NRI.NRI.Reston.VA.US id aa08918; 30 Nov 90 12:32 EST
Received: Fri, 30 Nov 90 12:30:56 EST from SGI.COM by merit.edu (5.59/1.6)
Received: from whizzer.wpd.sgi.com by SGI.COM via SMTP (5.64-bind 1.5+ida/900410.SGI) for fddi@merit.edu id AA00502; Fri, 30 Nov 90 09:30:52 -0800
Received: from gate-rhyolite.wpd.sgi.com by whizzer.wpd.sgi.com via SMTP (5.64-bind 1.5+ida/900721.SGI) for sgi.sgi.com!merit.edu!fddi id AA04150; Fri, 30 Nov 90 09:30:41 -0800
Received: by rhyolite.wpd.sgi.com (5.52/900721.SGI) for @whizzer.wpd.sgi.com:bagnall_d@apollo.com id AA04571; Fri, 30 Nov 90 09:30:38 PST
Date: Fri, 30 Nov 1990 09:30:38 -0800
From: Vernon Schryver <vjs%rhyolite.wpd.sgi.com@sgi.com>
Message-Id: <9011301730.AA04571@rhyolite.wpd.sgi.com>
To: bagnall_d@apollo.com
Subject: Re: EARP proposal
Cc: fddi@merit.edu, dhunt@enr.prime.com, strohl@apollo.hp.com, cbrown@enr.prime.com
Status: O
The proposal looks good to me. There are two improvements or simplifications to the algorithm that might be useful. What if an EARP host always sends an EARP request whenever it sends an ARP request? In other words, on the first attempt an EARP host would send only an EARP request. On subsequent attempts it would send both flavors. If both requests went out "on the same token" and the EARP were first, then most of the time it would get the most correct answer. I think you are too conservative in your analysis of the robustness of your algorithm when an EARP host incorrectly decides a target is an ARP host. That situation will heal itself almost always. You could improve the odds of healing by changing the algorithm slightly. Let the EARP host send an EARP request directed to an ARP responder when it resolves an ourstanding request with an ARP response. In other words, an EARP requester would ask for both EARP and ARP answers, receive an ARP answer, and then ask if ARP was correct. The requester would not take any other explicit action; if the ARP answer was wrong, then the requester would use the single MAC address until it received a seemingly spontaneous EARP correction. If the ARP answer was correct, nothing more would happen. Has anyone surveyed existing FDDI ARP implementations to see what they will do when presented with a hardware type code of 256? Perhaps they will either ignore the entire packet or follow a version of the INTEROP89 agreement and respond with an ordinary ARP packet with hardware type 1 or 6. I wish SGI would have been represented at IETF, but events intervened. I will be in San Jose. Vernon Schryver, vjs@sgi.com
- EARP proposal Vernon Schryver
- EARP proposal bagnall_d
- Re: EARP proposal Vernon Schryver