IP/dual-MAC FDDI proposal

[Vernon Schryver <[e-mail]>]

These are some superficial comments about the Extended ARP proposal.
I am sorry I did not respond sooner.


In general, the proposal seems to me to be the right thing to do in
order to support things like "automatic load balancing."  I do
have some minor and I think easily addressed comments.


I.  The proposal seems to imply that only a single ARP or EARP request is
    sent.  I assume this is a simplification to help the presentation or my
    misreading.  All current ARP implementations continually transmit
    periodic requests until the higher protocol layer requests go away or
    until a response is received.  For example, in 4.3BSD implementations,
    a new ARP request is transmitted every time a new request is received
    from the higher layers.  If the higher layer is a datagram gadget
    sending many packets without waiting for responses, the 4.3BSD code
    will generate a large number of ARP requests.  For example, the command
    `ping -f host` can generate 100 ARP requests/second.

II. If the FDDI standard succedes, there will be many implementations in
    customer sites this year.  If there are few customers, FDDI will be
    dead.  This means that EARP must interoperate with old ARP
    implementations for many years, or we do not need to worry about it.
    A switch that allows an entire ring to use EARP seems good, but its
    default value will have to be in the compatibility mode for the rest of
    the century.

III.The proposal seems to assume that frames are never lost.  It is not
    clear whether this assumption is based on proprietary hardware that
    does link layer recovery, or an idea that frames simply do not get
    lost.  (Since ARP requests are sent to the broadcast address, they will
    have both A and C bits set reguardless of whether the intended
    receipent saw them, so it seems unlikely that link layer recovery was
    intended.)  In any case, the assumption is wrong.  This assumption
    obviously affects the second the two of the "Backward Compatibility
    Proposals."  If either the initial EARP request or its response is
    lost, then the second proposal permanently falls back to "standard
    ARP."  This bad effect also occurs when the responding station is not
    in the ring when the initial request is sent, perhaps because it has
    not yet been initialized.  One way to fix this problem is to do both of
    the following:

	(1) always transmit both the EARP and ARP requests, with EARP
	    request first.  Perhaps transmit alternate forms on alternate
	    retransmissions.  No matter what you do in this style,
	    there is still a chance of getting the wrong answer.

	(2) age values in the local ARP cache that came in ARP responses
	    even when they are currently working, and age them faster than
	    values that came in EARP responses.  This is intended to force
	    a regular re-EARP, to patch failures in the first rule.

    I do not think either of the rules above are sufficent by themselves to
    prevent wrong answers from persisting for arbitrarily long periods.
    Together they are not entirely complete.


IV. There should be a way to distinquish ARP and EARP requests.  However,
    choosing a new SNAP value seems like a lot of bureaucratic work.  It
    seems just as effective and far easier to use the familiar RFC-1103
    SNAP encapsulation, including the "ethernet" protocol number in the LLC
    header, but choose a new ARP hardware type.  It seems unaesthetic to
    use a new SNAP value for what is really the same old RFC-826 thing.


V.  It is inappropriate to include information about whether the station
    is "WRAPPED" in an ARP packet.  That information is available in the
    myriad of SMT frames.  I understand that the reason for including the
    WRAPPED/THRU state is to indicate to EARP requestors which MAC
    addresses are available and on which ring, both at a particular instant
    and in general.  It may be true that some proprietary hardware cannot
    put "MAC's in series" or otherwise readily recognize all of their MAC
    addresses while in WRAP.  Such a station needs to convey that it is in
    a state where some of its MAC addresses are temporarily not functional.
    Exactly that information should be encoded.  That the cause has
    something to do with a PCM state is irrelevant to [E]ARP.

    This would be an unimportant nit, except that as the proposals are
    written, they would impose unnecessary restrictions and load on the
    majority of dual-MAC stations, which are capable of putting their
    "MAC's in series."  Such dual-MAC stations need never tell EARP
    requestors let alone waste bandwidth with a broadcast that they are in
    WRAP.  Whether such stations are in WRAP has no effect upon their
    function for ARP, IP, TCP, and so on.


VI. The third paragraph of section 5.4 seems to imply that EARP response
    might arrive on either interface of a dual-MAC station.  I do not
    understand this, since:
	(1) if only one interface (for example, the interface on the
	    primary ring) is used to transmit requests, then responses
	    should always be received on that interface.

	(2) if both interfaces are used, then responses will arrive
	    on both interfaces.

	(3) while the ring is wrapped, including by non-IP stations,
	    individual broadcast requests will arrive on both interfaces,
	    and because of timing considerations, are likely to be answered
	    twice.

    This nit matters because the same paragraph suggests associating
    the interface on which a response arrived with the values in the
    cache.  I am confused by the implications of this suggestion.


VII.To which MAC address should EARP responses be directed?  That is,
    which of the two or more MAC address should the answering station
    put in the MAC header of its response?  In other words, which
    ring should be used?  In all combinations of local and remote station
    WRAPPED?


VIII.The "settle" time in the first paragraph of section 5.4 must be made
    an explicit number.  The right value is far from clear to me, given
    wide range of time require to change between WRAPPED and THRU (around
    50 milliseconds to 5 seconds), and given the unhappy effects long delays
    have on many things, including TCP/IP, NFS/UDP/IP, other applications,
    and paying customers.



The need for continual double-requests (see III above) makes me prefer the
"5.3.1 EARP Proposal One."


I think that some RFC should finally say that all single-MAC stations
must be on the primary ring, or describe an alternative that works.
(I continue to claim that putting a bridge between the rings will not work
for the vast majority of bridges.)  This issue is only partly related to
[E]ARP.



Vernon Schryver
Silicon Graphics
[e-mail]