🚀 go-pugleaf

    > Exactly right.  "transit bridging" == "encapsulating bridging".
    > Nearly guaranteed not to interoperate with any other vendor.

    Are you saying that cisco can't ROUTE to/from a node on FDDI, or does
    it do that as well ?

Sigh.  Since you are the second person to mis-interpret my remarks,
perhaps a public statement is in order...

"encapsulation bridging" or "transit bridging" is a scheme whereby
you bridge together a bunch of ethernets, using an FDDI ring as the
backbone.  This is similar to bridging two ethernets across a T1 line,
only different.  Each ethernet packet is "encapsulated" entirely
(including ethernet headers) inside an FDDI packet.  The FDDI packet
will be given a type code like "cisco transit bridging", flooding might
be done by sending packets to the "cisco transit bridging multicast
address", and so on.  There are currently no standard values for
any of these typecodes or addresses, so each vendor has picked their
own, and it is doubtfull that they interoperate WHILE DOING TRANSIT
BRIDGING.  Eventually, there will probably be a standard, and everyone
will eventually support it.

"transparent bridging" is reaonsably standardized.  You take your
ethernet, token ring, or FDDI packets, fiddle their header bits,
change back and forth (maybe) between "ethernet" and "SNAP"
encapsulation, and send the new packet out on the new interface, where
it hopefully looks as though it was originated by a host on the same
local media.  Cisco currently doesn't support transparent bridging to
or from FDDI at all - while not conceptually difficult, transparent
bridging potentially requires filtering (discarding) FDDI packets
at media rate (400k pps or so).  This can be done with special hardware,
but it's a bit beyond the capability of even the RISCy VLIW buzzword
buzzword bitslice processor on cisco's current FDDI card.  In addition,
the FDDI chipset needs to be able to tell which frames to strip from
the ring, even though neither the source nor destination address matches
the local address.  This capability is not present in the current
implementation either (ah, the curse of being first).  So transparent
bridges ought to interoperate ok, but they aren't common yet.

Of course, WE all know that bridging is a terrible idea anyway, and
what one really wants to do is route...

The cisco should be compatible with all other FDDI routers for any
protocol whose format on FDDI has been defined.  I think this includes
IP, DECNet, Appletalk (phase 2) and CLNS.  In addition, there are a
set of protocols whose FDDI formats are "obvious" (eg, same as Token
Ring, or ethernet typecodes converted to SNAP), and there is a very
good chance we inter-operate with any vendor routing those protocols
(I think this includes XNS, Novell, Vines, and 3com).  There are some
whose encapsulation is somewhat strange (Apollo explicitly made their
FDDI encapsulation compatible with transparent bridging to ethernet,
rather than the more obvious token-ring like encapsulation).  Finally,
there are a couple protocols done in the obvious way (ether-->SNAP)
that you probably can't find another router to do anyway (PUP, Chaos).

Summary:  A cisco router/bridge should interoperate correctly with
any other vendors' devices on an FDDI ring runnin ANY protocol EXCEPT
"transit" or "encapsulation" bridging...

Bill Westfield
cisco Systems.
-------