Ethernet-FDDI woes

[Craig Partridge <[e-mail]>]

> I'm confused.  Please describe in more detail what these problems are,
> and why they require the use of an option (as opposed to, say, using
> the "report any fragmentation" method, which might not actually work but is
> at least conceptually possible).

Jeff:

    Here's the problem.

    Folks are building Ethernet-FDDI bridges (1576 MTU to 4096 MTU and
vice-versa).  This is all supposed to be "transparent"  (in fact, it
cannot possibly be -- the bridge has to do some data conversion -- so
we've taken to calling them "translucent").

    The problem comes when a host on the FDDI side decides to send to
an apparently "local" address using the full MTU, and that "local"
address is, in fact, bridged through an Ethernet.  The bridge will
drop the packet on the floor as untransferable.

    There's a way, using the MAC header to detect that you're
on a mixed network, and decide to use the Ethernet for all transfers.
But that makes some of the heavy data transfer folks unhappy.  They want their
Suns on Ethernets to be bridged to their Crays on the FDDI network, which
implies an Ethernet MTU everywhere, but also want the Crays to use the full
FDDI mtu.  One possibility that has been discussed is to allow use of the full
FDDI mtu IFF 

    - the MAC header indicates no Ethernets have been traversed

    - an MTU option is passed indicating the remote host is willing
	to talk in FDDI MTUs  (i.e. it hasn't been wired down to
	the Ethernet MTU for all transfers).

Now, I'm not arguing this is a good idea -- just that it has been
discussed.  And the fragmentation bit doesn't give you the MTU information
you need in this case.

Craig