🚀 go-pugleaf

In article <mbt.717984230@Able.MKT.3Com.Com>, mbt@ESD.3Com.COM (Brad Turner) writes:
> ...
> If after telling somebody they might shoot themselves in the foot I
> firmly believe they still have the right to. The whole issue boils
> down to customer choice and education.


I can imagine situations where an FDDI-ether bridge that doesn't handle
4K UDP/IP packets is the best choice.  Maybe the customer does not and
never will care about NFS servers on the fiber.  If the customer gives
informed consent, so be it.

How you find salescreatures that both can "make plan" and won't shave
that informed consent until it is tenuous, I don't know.  Finding
customers who will admit they don't know everything and so can be
informed enough to give meaningful consent to an unusual solution is
another difficulty.

What went wrong with the customer who started this thread?


> IP aside how does SGI deal with ether to FDDI translation bridging
> of protocols that don't use byte level acks? Just courious...

I don't know what is meant by "byte level acks".  Protocols such as TP4
or XNS with records?  What problems special do they have?

We tend to encapsulate protocols like SNA in TCP/IP.

Silicon Graphics makes UNIX boxes.  None of our standard products
bridge.  We are perforce of the routing faith.

If you mean, how do we as users handle FDDI-ether bridging problems,
answer is that all of the production FDDI rings I know about inside the
company are run by and for the developers, who do not use MACs, PCs,
VAXEN, etc, and so have only IP FDDI frames (and, of course, ARP and
lots of SMT), and we use our own boxes to route, not bridge, IP to and
from FDDI.


Vernon Schryver,  vjs@sgi.com