Minutes of the IETF IP Over FDDI Working Group

[Dave Katz <[e-mail]>]

here's my draft minutes of the meeting last week.  If anyone who was
at the meeting spots any misrepresentations or baldfaced lies,
let me know.  These minutes will published in the proceedings.

Also, if anyone who was at the meeting is not listed in the attendee
list at the end, please let me know.
_________________________

 Current Meeting Report

 IP Over FDDI Working Group

 Reported by Dave Katz/Merit


 MINUTES

 The group met on the afternoon of Wednesday, February 7.


 1.  Document Overview

    Dave Katz gave an overview of the current draft IP Over FDDI
    document, which had been distributed to the [e-mail] mailing
    list, for the benefit of those new to the working group.  Highlighted
    were differences between the current draft and RFC 1103.


 2.  Outstanding Technical Issues

    A and C Indicators

       A discussion ensued on the issue of the A (Address Recognized) and
       C (Frame Copied) indicators.  The current draft states that "the A
       and C indicators shall be ignored for IP and ARP packets."
       Objections were raised that this would appear to preclude ANY use
       of these indicators, such as the management of ARP cache entries.
       The document editor gave his view that a standard can only specify
       externally-visible behavior, and that implementation decisions
       such as ARP cache management could not be precluded.

       The intent of the language regarding A and C was to preclude the
       use of link-level retransmission in the face of apparent transient
       congestion in the receiver.  The pros and cons of retransmission
       were debated.  After some discussion, the group decided that the
       usage of the A and C bits would be specified as an implementation
       decision, with an explicit note that link level retransmission may
       in fact occur.


    Dual-MAC Issues

       Dave Katz provided an overview of the issues regarding the use of
       dual-MAC stations.  Two basic approaches are possible:

       1.  Separate IP subnetworks on each ring

       2.  A single IP subnetwork spanning both rings, with both MACs
           using the same IP address (for load splitting)

       With separate IP subnetworks, the major technical requirement
       seems to be that all stations properly support subnetting (only
       sending ARPs for stations on the proper subnet, for example) so
       that the ring may wrap and unwrap without stations on the two
       rings learning each others' MAC addresses.  A further issue is
       that if a dual-MAC station wraps the ring, the SMT Configuration
       Management state machine implies that one of the MACs may be
       disconnected for the duration of the wrap.

       When a single IP subnetwork is used, the current ARP protocol is
       insufficient to maintain knowledge of the binding between MACs and
       rings.  In particular, if the ring is wrapped and an ARP is sent
       for an IP address, two responses may be received at each source
       MAC, and it becomes ambiguous when the ring unwraps as to which
       ring each MAC is connected.  This problem is made more difficult
       in the face of the lack of a reliable event-driven indication of
       the wrap state of the ring (especially if two MAC-less
       concentrators are performing the wrap).  Further complicating this
       problem are "translucent" bridges between Ethernets and FDDI
       rings.

       It was generally agreed that both the single-subnetwork and dual-
       subnetwork configurations are desirable, and that they should both
       be defined, and configurable on a per-LAN basis.

       Doug Hunt of Prime presented a straw-man proposal of how to deal
       with the single IP subnetwork case.  It suggests the use of an
       extension to the ARP protocol that allows the unambiguous
       determination of the ring on which a MAC is present, even in the
       face of the ring wrapping and unwrapping.

       It was recognized that the development of the single-subnetwork
       solution, which is generally viewed as being desirable, is going
       to be a comparatively long process.


 3.  Document Progression and Future Work

    The question of the progression of one or more documents into the
    IETF standards track was discussed.  The choices of action balance a
    need to produce a standard very quickly versus producing a complete
    standard.

    The choices are:

       a) Progress the current document immediately as a single-MAC
          standard and begin work on a separate dual-MAC standard.

       b) Quickly write a dual-subnetwork, dual-MAC solution, add it to
          the current document, progress it as a standard, and begin work
          on a separate single-subnet, dual-MAC standard.

       c) Add single- and dual-subnetwork, dual-MAC solutions to the
          current document and progress it as a standard.

    Choice a) has the advantage of starting the base document through the
    standards process most quickly, significantly moving up the date at
    which a standard could be published and conformant products could be
    produced by vendors.  It has the disadvantage of being only a partial
    solution, and may give the impression of favoring single-MAC
    stations.

    Choice b) includes support for dual-MAC stations, but delays the
    progression of the base document and gives the impression that the
    dual-subnetwork solution is the "right" solution for dual-MAC
    stations.

    Choice c) provides the most even-handed document in terms of the
    various solutions, but seriously delays the publication of any sort
    of standard.

    The group decided to pursue the following course:

       Make minor additions and corrections to the current draft,
       including a statement to the effect that a dual-MAC solution is to
       follow.  Forward this draft into the February X3T9.5 meeting.
       Incorporate any additional comments from X3T9.5 into the draft and
       publish it immediately thereafter as an Internet Proposed
       Standard.

       Create a new working group to address "multi-rail" LANs, of which
       FDDI is a specific case, with the intent of producing an Internet
       Standard on the subject.


 Attendee List (incomplete)

    Steve Senum
    Ken Hays
    Dave Piscitello
    B.V. Jagadeesh
    Dino Farinacci
    Steve Shibuyama
    Binh Hua
    Doug Bagnall
    Mary Jane Strohl
    Ronald Jacoby
    Samir K. Chatterjee
    Doug Hunt
    Dean Throop
    Dave Katz
    Noel Chiappa