Re: EARP

Vernon Schryver <vjs%rhyolite.wpd.sgi.com@sgi.com> Fri, 07 September 1990 21:20 UTC

Received: from merit.edu by NRI.NRI.Reston.VA.US id aa13021; 7 Sep 90 17:20 EDT
Received: Fri, 7 Sep 90 16:20:43 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 AA22882; Fri, 7 Sep 90 14:20:40 -0700
Received: from 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 AA14075; Fri, 7 Sep 90 14:20:38 -0700
Received: by rhyolite.wpd.sgi.com (5.52/900721.SGI) for @whizzer.wpd.sgi.com:fddi@merit.edu id AA19505; Fri, 7 Sep 90 14:20:36 PDT
Date: Fri, 7 Sep 90 14:20:36 PDT
From: Vernon Schryver <vjs%rhyolite.wpd.sgi.com@sgi.com>
Message-Id: <9009072120.AA19505@rhyolite.wpd.sgi.com>
To: fddi@merit.edu
Subject: Re: EARP
Status: O

> From: "NI1D @FN42eq" <koning@koning.enet.dec.com>
> 
> The reason for not using the ARP Hardware Type field (by itself) to
> identify EARP is that some implementations ignore that field.

Good point.

> By "Protocol_ID" I meant the 5-byte field that follows the AA-AA-03 --
> for example, in ARP that is 00-00-00-08-06.  One alternative is to
> use 00-00-00 for the first 3 bytes, in which case the task amounts to
> getting another EtherType.  Xerox (I assume still) hands those out.
> If you don't insist on an EtherType (i.e., you're willing to accept
> values other than 00-00-00 in the first 3 bytes of the Protocol_ID) then
> there are lots of others that could provide the value, probably sooner.

It is possible that some vendor might have a spare Xerox EtherType to
contribute to the cause.  For example, last year Silicon Graphics gave an
EtherType that had long ago been assigned to a protocol that faded to a
company that is now working on a new protocol.  I fear we don't have any
more spares; does anyone else?

> As for the question of what the Hardware Type field in the EARP message
> should be: I would propose that there should be no such field!  The reason
> is that it's presence in the ARP message has been a source of hassle and
> does not in fact serve any purpose.

>  ...

seems reasonable.



vjs