CURRENT_MEETING_REPORT_ Reported by Andrew Malis/Ascom Timeplex Minutes of the Routing Over Large Clouds Working Group (ROLC) There were 108 attendees, many of whom were newcomers. The chair announced that in order to get work done, the group would focus its discussion on the current draft and not rehash earlier decisions (especially the requirements and goals). He then presented a set of overheads to start the meeting and provide some background to first-timers. During the presentation, Curtis Villamizar reminded the group that at the Seattle meeting, a goals and requirements document was discussed. While they have been documented in both the Seattle and Toronto minutes and proceedings, The chair invited him to write such a document. He may do so if he has the time. ATM Forum Update The working group received an ATM Forum update from Drew Perkins and Joel Halpern, direct from the previous week's ATM Forum meeting in Kyoto. The primary news was from the Multiprotocol over ATM group. Most of the discussion there was concerning requirements, along with some discussion of reference models. The main agreement from the meeting was there will be one host behavior, query-response (based upon Classical IP over ATM, NHRP, and ATM Forum LAN Emulation). Implementation Experience Reports The one detailed report was from Kanan Shah of NRL. She has been finishing her code and it is almost at the testing stage. Testing will take place on the ATDnet (a large-scale OC-48 ATM testbed that rings the Washington DC area). She plans on testing with Rob Coltun's PNNI routing code. Dave Katz said that cisco also has an implementation under way (being developed by Bruce Cole), but was not at liberty to further discuss its status. Current NHRP Draft Review Dave Katz, along with Dave Piscitello, the NHRP editors, led a detailed review of the current draft, draft-ietf-rolc-nhrp-03.txt, which had been distributed on the mailing list the previous week. Among the major issues discussed were: o There has been a change in the packet format. The MBMA family identifier is now a 16-bit number, and can be found in ``Assigned Numbers.'' o The Authentication option has also been changed. An option has been added for MD5. o Curtis Villamizar brought up a question as to the semantics of the S bit, which will be better clarified in the text. There will be further investigation of the usefulness of the ``S'' bit, which is used to identify whether a potential looping scenario exists. o The working group needs to further investigate the usefulness of a ``C'' bit to distinguish destinations attached directly to NBMA fabric from those that are not, and a ``J'' bit to say ``I assert that the destination I'm informing you of is directly reachable via me (no intervening routers).'' o Curtis was recognized for his contribution in Section 8.1. o The working group needs to improve the description of destination masks (guidelines for constructing the mask, means by which requester distinguishes the appropriate mask length). o There was discussion on ``hole punching'' in cached aggregated destinations. o A discussion on options took place referencing non-optional and optional options. For clarification, there is an option bit that tells the implementation what to do if it does not support particular options. The terminology has been changed to ``discretionary'' and ``non-discretionary'' options. Three of the options have been made discretionary: destination mask option (Section 5.6.1); QoS option (Section 5.6.6); vendor-private (Section 5.6.8). o The discussion on page 2 that suggests that NHRP obviates the need for LISs will be revised. o A discussion of routing loops was led by Curtis. The solution when a routing loop is detected is to break the VC. The group concluded that routing loops only occur in the router-to-router case, and then only if routers use NHRP information to take precedence over information learned by routing protocols. Curtis is going to send mail to the list on the subject. o The question of when you use Classical ARP and when you use NHRP was raised. The sequence of events will be: 1. Only ARP servers are used as per RFC 1577. 2. NHRP is phased in: - Hosts continue to register with the ARP server (until ARP servers go away, for the benefit of non-NHRP hosts). ARP servers will leak registrations to NHRP servers, so NHRP hosts do not have to register twice if they do not wish to (but then they must agree to certain defaults, such as the registration timeout period). [Note that this is one way; NHRP servers never leak information to ARP Servers.] If NHRP hosts wish to override these default values, then they must also register with the NHRP server. Explicit registrations always take precedence over leaked registrations. - NHRP source hosts send all address resolution requests to the NHRP server (without regard to the ``mask and match'' operation). - NHRP source hosts may send ARP requests to their ARP server if they get a NHRP NAK and the destination is in the same LIS. 3. NHRP servers completely replace ARP servers. All hosts are NHRP-capable. o Intermediate router operation: If the IR is willing to set up a direct VC to the destination, it must be willing to cache the fact it has generated and/or forwarded the NHRP request for that address (so that it will not generate another). If it is not willing to set up a VC, then it will not need to cache the fact that the request was forwarded. o On a related issue, the document should adequately cover how to restrict generation of NHRP requests (will every packet generate one if one is already in flight, will every NHS generate a request along the routed path, etc.). o Note that when a router returns an NHRP reply for its own IP address, it should mark the S bit as originating from a host. o A request to the group was made for someone to help with authentication, and Sandra Murphy of TIS volunteered to provide assistance. o It was agreed that more text should be added to the document discussing the aging of information. o The suggestion was made for a host implementation cookbook. o There was a request for volunteers who are willing to explore other protocols in the context of NHRP. Other protocols of interest are IPv6 and IPX. There were no volunteers in the room. Please send mail to the chair if you are interested. Dave and Dave will be producing a new revision reflecting the discussion. New Work Items The Routing Area Director told the working group that a protocol analysis document, while required for protocol standardization, was probably premature at this point. However, Kanan Shah has volunteered to begin its preparation. Two other documents were assigned to volunteers: o Protocol Applicability: Derya Cansever. o The NHRP MIB: Mike Patrick. Mike will begin by compiling an initial list of objects of ``interest'' for debugging, operational support, tuning knobs, and so on, and sending them to the list for review and suggestions. Anyone interested in helping out with these documents should contact either the authors or the chair. Work Plan Update o It was decided that the NHRP document should be submitted to the IESG as a proposed standard following at least one more revision. The working group has a goal of Feb. 95 submission. o The working group should submit the companion applicability document to the IESG in April 95. o The working group should have a draft of the MIB document by April 95. An updated charter will be forthcoming.