Re: EARP proposal

[Vernon Schryver <[e-mail]>]

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,    [e-mail]