Re: IP over FDDI comments

[Steve Deering <[e-mail]>]

Maybe I should make clear that I don't think the bridge-between-the-rings
scheme is a *good* idea.  It is just the only way I can think to satisfy
those who want to:

	(1) allow single-MAC stations on either ring, AND

	(2) assign a single IP subnet number to the pair of rings.

Without the bridge, you end up with a (usually) partitioned IP subnet,
which violates a basic architectural requirement of IP routing.  (One
might call it a shortcoming of IP routing.  The IS-IS routing scheme
proposed for CLNP does not have the same problem, though its extra
flexibility comes at a price.  But that's another story.)

Satisfying either (1) or (2) -- but not both -- seems straightforward,
and I'd be happy with Vernon's scheme (give each ring its own IP subnet
number and satisfy (1)) or with my scheme (keep all single-MAC stations
on the primary ring and satisfy (2)).

Perhaps you can come up with a way of doing reasonable load-sharing
between dual-MAC hosts under Vernon's scheme.  If so, the same method
ought to apply between any pair of IP hosts that are direct neighbors
over more than one IP subnet -- not just FDDI rings.

To answer some of Vernon's points:

>	What happens when the ring wraps?  What would a bridge between
>	the rings do then?  Please recall that an individual station
>	including any bridge or concentrator cannot know when the ring
>	has wrapped within any usefully small time.

How small a time do you need?  Current bridges (e.g., DEC LANbridge)
multicast their routing packets once a second, which means that a
bridge can detect a wrap (by hearing its own multicast from interface A
arrive on interface B) and stop forwarding within 500 ms on average.
I don't know enough about FDDI to know if a bridge could detect changes
between wrap and thru states and use that to trigger immediate routing
updates for quicker reconfiguration.  Anyway, as I said above, I don't
really want to defend the bridge-between-the-rings approach -- I see it
more as a last resort.

>	The main advantages of this [new] ARP encapsulation is that
>
>	 1) standard BSD if_ether.c can be fat, dumb, happy, and ignorant 
>
>	 2) there are no funny cases to worry about in dual-MAC stations.
>	    You do not have to worry about sending 2 ARP packets, and
>	    cover the cases when one or the other should have been sent
>	    and understood by the receiver, but is lost on the fiber.
>
>	The 2nd problem has caused me to worry about all multi-packet ARP
>	schemes.  There seem to me to be a lot of cases to cover, and some
>	cases where a sub-optimimal answer is inevitible  (e.g. when the
>	new-fangled ARP packet between dual-MAC stations is lost in the
>	fiber).

I don't believe this is any problem at all, at least under my basic
proposal, but I probably can't convince you of that without discussing
it in person, or typing a lot more than I have time for.  Oh well.

On to a couple of points raised by Dave Katz:

>	I'm also not convinced that I've seen any proposal that doesn't
>	impact existing Ethernet implementations in a bridged environment.

Oh, that can of worms.  Well, much as I hate to admit it, I think my scheme
would work OK, assuming the Ethernet bridges attach to the primary ring.
(Recall, my proposal was to use old Ethernet-style ARP on the primary
ring, and to require all single-MAC stations to attach to the primary ring.
The secondary ring serves only as a "back-channel" between dual-MAC
hosts.  An ARP variant is used on the secondary ring that is sufficiently
different that, when the ring is wrapped, it will be ignored by existing
Ethernet ARP implementations on the primary ring and on any LANS bridged to
the primary ring.)

Under Vernon's scheme, you could end up with an Ethernet plus one ring
forming a single IP subnet, and the other ring forming a second IP
subnet.  Yuck.

Anyway, Ethernet-FDDI bridges are an invention of the devil, and don't
deserve the amount of time and effort that has been spent worrying
about them.  Maybe the same is true of FDDI itself?

>	I took a look at the 4.3 ARP code lately, and noticed that it
>	basically ignores the ARP op code when processing received packets
>	until the very end when it decides whether to send a response or
>	not.  As such, I think that the proposal to use a new opcode has
>	problems.

So we can't use the hardware type field and we can't use the opcodes to
discriminate between ARP flavors.  Guess that leaves the ethertype field,
or whatever you call it in the FDDI world.
 
>	Something that might work to disambiguate ARPs destined for the 
>	secondary ring could be to transmit them to a well-known multicast
>	address instead of the broadcast address;  this would both
>	disambiguate them and cause Ethernet hosts to ignore them.

You can't count on the Ethernet hosts ignoring them.  They might slip
by the multicast filters, due to the hashing approach used by current
Ethernet chips.  Better to use different ethertypes, as was done with
Reverse ARP.

Steve