CURRENT_MEETING_REPORT_ 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 FDDI@MERIT.EDU 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) 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. (b) Dual-MAC Issues: Dave Katz provided an overview of the issues regarding the use of dual-MAC stations. Two basic approaches are possible: o Separate IP subnetworks on each ring o 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 1 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. This proposal and other potential solutions were discussed by the group. It was recognized that the development of the single-subnetwork solution, which is generally viewed as being desirable, is going to take a significant amount of work. No decision was made regarding the mechanism to be used. 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: o 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 o publish it immediately thereafter as an Internet Proposed Standard. o Create a new working group to address "multi-rail" LANs, of which FDDI is a specific case, with the intent of producing an Internet 2 Standard on the subject. Hope was expressed that generalizing this problem would not significantly delay the development of a solution for FDDI. ATTENDEES Doug Bagnall bagnall_d@apollo.hp.com Samir K. Chatterjee samir@nynexst.com Noel Chiappa jnc@lcs.mit.edu Dino Farinacci dino@bridge2.3com.com Ken Hays hays@scri1.scri.fsu.edu Binh Hua no email Doug Hunt dhunt@enr.prime.com Ronald Jacoby rj@sgi.com B.V. Jagadeesh bvj@chamundi.esd.3com.com Dave Katz dkatz@merit.edu Dave Piscitello dave@sabre.bellcore.com Michael Reilly reilly@nsl.dec.com Steve Senum sjs@network.com Steve Shibuyama no email Mary Jane Strohl strohl@apollo.hp.com Dean Throop throop@dg-rtp.dg.com 3