The Routing Over Large Clouds Mailing List Archive by date

[Dave Katz <dkatz@cisco.com>]

   >>The mistake of putting hardware type instead of address type into ARP
   >>resulted in no end of ugliness when multimedia bridges came along (which
   >>is why FDDI uses the "Ethernet" hardware type).

   Can you be clearer on what precipitated the ugliness?

The ugliness comes in when different media use the *same* address space,
and people want to build interworking between them.  In this case it
was Ethernet, FDDI, and IEEE 802.x;  when I first did the FDDI spec I
copped the "802" hardware type for ARP, and was quickly browbeaten into
using the "Ethernet" hardware type instead, "so as to not preclude
interoperability with Ethernets in a bridged environment..."

The result of getting this wrong is the existence of bridges that reach
down into the guts of ARP packets and tinker with the fields.  (This is
independent of the token ring bit ordering nightmare, which fortunately
broke things so badly that nobody minded having to tinker with the type
field.)

   If you're doing cross-media bridging then it hardly matters if you're
   using a number space in the nhrp packet that is supposedly media-independent.
   If each media use dissimilar address spaces you're stuffed either way,
   and need to do address translation (or dont bridge/dont do nhrp across
   the boundary).

But there is likely going to be cross-media bridging with the same
address space.  ATM to SVC frame relay seems likely; I'm sure people
will come up with all kinds of queer adaptation gizmos.

   (Am I'm missing something fundamental here? Are we NHRPing across
   NBMA network boundaries where the networks use dissimilar address
   types? How exactly is the AFN space going to help here? If anything
   I'd have thought in such scenarios the edge NHS might find it
   advantageous to have the media type carried within the NHRP messages
   it is 'bridging' between NBMA networks.)

This doesn't help for dissimilar address types, but it does not preclude
interworking dissimilar media with the same address space.  And at the
risk of sounding excessively purist, putting the hardware type in here
cuts across too many layers.  The intent is to map addresses; who cares
what the media is?  If you put the media type in, and somebody builds a
new medium that can interwork with ATM in a way that preserves address
semantics, putting the media type in will make it impossible to interwork
transparently with the deployed base.

   >>Pardon my ignorance, but it would be helpful for me if you would explain
   >>why the media type is useful information in this case.

   I would like to know the converse. Why should media information
   be lacking? I dont see the supposed 'ARP mistake' as being
   sufficient motive for shying away from this.

See above.