EARP

"NI1D @FN42eq" <koning@koning.enet.dec.com> Thu, 13 September 1990 03:41 UTC

Received: from merit.edu by NRI.NRI.Reston.VA.US id aa13941; 12 Sep 90 23:41 EDT
Received: Wed, 12 Sep 90 22:40:15 EST from decpa.pa.dec.com by merit.edu (5.59/1.6)
Received: by decpa.pa.dec.com; id AA09190; Wed, 12 Sep 90 13:25:54 -0700
Message-Id: <9009122025.AA09190@decpa.pa.dec.com>
Received: from koning.enet; by decwrl.enet; Wed, 12 Sep 90 13:26:32 PDT
Date: Wed, 12 Sep 1990 13:26:32 -0700
From: "NI1D @FN42eq" <koning@koning.enet.dec.com>
To: fddi@merit.edu
Subject: EARP
Status: O

As Vern Schryver said, there doesn't seem to be a "lock out" issue
around the Protocol ID choice for EARP.  Either alternative works.
 
So far EARP seems to be described as an FDDI thing.  I know that FDDI
has generated the requirement to do something, but as I've argued before,
the need to deal with "multi rail" LANs is not FDDI specific.  So while
it might not happen immediately, it is very definitely possible for
Ethernet nodes to want to speak EARP.
 
If an Ethernet node wants to do that, the anwer depends on the Protocol_ID
selected:
 
1. If the Protocol_ID (on the FDDI) has an OUI of 00-00-00, then the
   corresponding frame on the orange/yellow hose is an Ethernet frame.
   (It would be legal for the Ethernet node to send SNAP frames with the
   assigned Protocol ID, so long as RFC 1122 is adhered to -- but this
   would be extra work that serves no purpose.)
 
2. If the Protocol_ID has an OUI other than 00-00-00, then the corresponding
   frame on the orange hose is an 802.3 frame with that same Protocol ID.
   Nodes over there that want to participate would have to be able to
   speak 802.3 frame format.  However, since the OUI isn't 00-00-00, the
   ONLY form in which the EARP frames would show up is in 802.3 form;
   the RFC 1122 requirement I mentioned doesn't apply to this case.
 
So either way things are simple.  I have no objection to approach #1.
Everyone can clearly support that.  I would think that these days many
Ethernet nodes are capable of 802.3 frame format support, but perhaps not
all -- which argues in favor of #1 over #2.  Fine...
 
	paul