CURRENT MEETING REPORT Reported by Howard Berkowitz, PSC International and Andrew Malis, Ascom Nexion, Inc. Minutes of the Routing Over Large Clouds Working Group (ROLC) The ROLC Working Group met in two sessions at this IETF. There were approximately 145 attendees. Agenda: o First Session o Agenda bashing o ATM Forum MPOA update o Joint statement by the IPATM and ROLC chairs o NHRP specification and open issues--draft-ietf-rolc-nhrp-06.txt o Second Session o ATM Forum Liaison o Local/Remote Forwarding Decision--draft-ietf-rolc-apr-03.txt o Mobile NHRP Devices--draft-horikawa-mobile-nhrp-00.txt o ATMARP/NHRP Translation o Router-Router NHRP o Status and Workplan SESSION ONE ATM Forum MPOA Update George Swallow, the ATM Forum Multi-Protocol Over ATM (MPOA) Sub-Working Group Chair, reported that the MPOA current approach is based upon NHRP and MARS. No protocol design is being done; NHRP "out-of-the-box" is desired. The MPOA SWG appreciates the work being done in the IETF to harmonize NHRP and MARS. There is very little interest in the ATM Forum in RFC 1577 (Classical IP over ATM). ATM Forum LAN Emulation (LANE) is used at layer 2. Both "edge devices" and routers are supported by MPOA. Server redundancy is a major concern. MPOA has additional concerns, such as edge device- to-edge-device connectivity. The external ATM Forum MPOA and PNNI mailing lists, as reported at the Stockholm ATM Forum BOF, still have not been set up by the ATM Forum. It is premature for the IETF to be citing ATM Forum UNI 4.0; its public release date is unclear, with a current February goal for straw vote. Forum/ITU politics may also delay its completion. Joint statement by the IPATM and ROLC chairs Mark Laubach (the IPATM chair) and Andy Malis presented a chair's statement regarding ROLC and IPATM coordination of the transition from ATMARP to ATMARP + NHRP to NHRP. A mention was made that the IESG has stated that a well-defined step-wise transition plan that emphasizes interoperability with the installed base is required for any evolution of a widely deployed proposed standard. All clients must be able to resolve the address of any other client by required default behavior (for the given client type) regardless of implementation or deployment. In the following discussion, the ROLC Working Group asked that references to NHRP be removed from Mark's IP/ATM Classic2 draft, to allow a separate transition plan to be developed. NHRP Specification and Open Issues The working group next discussed some NHRP open issues from version- 06 and the mailing list. 1. MARS harmonization-Hardware Type field vs. Address Family field: The motivation for each choice was continued from the mailing list discussion. Good points were made on either side, after which the clear working group consensus was to use Address Family to identify the NBMA address type. Grenville Armitage made the corresponding change to the MARS specification to allow continued NHRP and MARS harmonization--see draft-ietf-ipatm-ipmc-10.txt. 2. MARS harmonization-address field coding and parsing: NHRP was zero-filling addresses to 32-bit boundaries, while MARS was not. The chair noted that it would be nice for them to be same, if only for code reuse in your implementations. After discussing the relative merits, the working group agreed to "align" with MARS and not zero-fill addresses to 32-bit boundaries. 3. Destination prefix vs. mask: The consensus was to go back to the prefix rather than the mask. 4. Using prefixes with purge messages: The consensus was to allow prefixes with purges. 5. Purge acks: The working group discussed whether or not purges should be acknowledged. The consensus was yes. It is up to each purge sender to decide whether to wait for the ack and whether or not to resend the purge if the ack doesn't come back, but purge receivers must always send acks. There was little consensus one way or the other for adding a bit to the purge specifying whether or not the receiver should send an ack; this should be further discussed on the list. 6. MTU: The suggestion was made to use currently unused header space for MTU discovery. There was clear consensus to add this feature, as it is consistent with RFC 1626 requirements. 7. Server redundancy: This is not addressed in the current spec. A strict reading suggests that if there is more than one NHS in a LIS, then NHRP clients must register with all of them. The working group agreed that addressing server redundancy is required before NHRP is "ready for prime time". The working group agreed that it would be a reasonable goal to leverage the IPATM Working Group's synchronization method, if possible. This discussion will be continued on the mailing list. 8. Autoconfiguration: The issue of how to configure clients and servers came up during the redundancy discussion. There was strong consensus for autoconfiguration capabilities, supported either from network management via the NHRP MIB, or via a configuration server. The view was expressed that while ATM anycasts are useful to find configuration servers, they should not be used to find NHRP servers, but the working group did not reach consensus on this point. There was discussion of whether to use NBMA-level configuration services when available; this led to a liaison to the ATM Forum regarding ROLC's interest in using the ATM Forum's LAN Emulation Configuration Server (see below). The point was also made that ATM Forum anycasts cannot be used in an IETF document until UNI 4.0 is publicly available. The autoconfiguration discussion will be continued on the list. 9. [This was actually discussed in the second session, but logically fits in here.] The question was asked why clients are configured with their server's IP address. The consensus was that this was just a holdover from server mode, and that it should be removed from the spec. SESSION TWO Joint ROLC/IPATM Liaison to the ATM Forum The ATM Forum liaison was discussed and amended. The liaison included two sections, one suggesting leveraging the LANE configuration server for IETF uses, the second asking for LAN Emulation Configuration Server redundancy. The liaison was later presented at the IPATM Working Group meeting, where it was accepted and forwarded to the ATM Forum liaison, Joel Halpern. Local/Remote Forwarding Decision Yakov Rehkter presented draft-ietf-rolc-apr-03.txt. His talk discussed issues such as: Why do we care how the local/remote decision made? When can SVCs be used effectively? When is the overhead of SVC setup justified? Other issues discussed included connection setup/teardown, Quality of Service, and SVC sharing. He pointed out that we should rethink the subnet model, and replace it with a local vs. remote model. Numerous options then result, significantly larger than with the classic LIS model. If the model is relaxed, can link layer connectivity always be reached? Try to establish connectivity--if not reachable, then fall back to the routed path. How should we do address assignment in the absence of the subnet model? Instead, use the notion of "groups." A group implies assignment of end host and router addresses from a single prefix. Routers in the group advertise routes to the prefix. In discussion, the working group agreed to the term "Local Address Group" (LAG) for this group. The working group also agreed that Yakov will update the draft based upon the discussion, and there will be a subsequent working group last call, followed by submitting the draft to be published as an Informational RFC. Mobile NHRP Devices Hiroshi Suzuki presented draft-horikawa-mobile-nhrp-00.txt. He began his talk by noting that it is more of a "NHRP Client Autoconfiguration" than a "Mobile NHRP" talk, although mobility issues were also included. He stated that autoconfiguration is required to make supporting a large number of clients practical. He presented the client's use of anycast to a "well-known" address to find any NHRP server on the NBMA, not necessarily one in your LIS. If a server receives a registration for a client in a LIS other than its own, then the server forwards the registration to the client's home server along the usual routed path (just like forwarding a NHRP Request). This procedure only works when the client is in the same NBMA cloud as its home LIS. The working group really liked this registration optimization, and agreed to include it in the spec. To allow secure registration, NHRP also needs end-to-end authentication in addition to the current hop-by-hop authentication. The working group agreed that in registration packets, encryption would be end-to-end, otherwise hop- by-hop as before. ATMARP/NHRP Translation Rob Coltun presented one viewgraph on his approach to ATMARP/NHRP translation. His ATMARP and NHRP servers are co- resident. If an ATMARP pertaining to the local LIS arrives at the server, the ARP code handles it. If it is beyond the local LIS, the ATMARP code translates it into a NHRP request, and forwards it to the NHRP code. The same model is also used for incoming NHRP requests. Router-Router NHRP Yakov Rehkter presented his approach to router-router NHRP, based upon two messages he sent to the mailing list. Yakov discussed tradeoffs required for cut-through paths, including increased state and control traffic, how to determine whether a cut-through path is still valid, how to avoid black holes and routing loops, how to determine when to bring down SVCs, and interactions with BGP and inter-domain routing. Yakov will be documenting this information in a forthcoming draft, which the working group agreed will be the basis for further work. Status and Work Plan The working group agreed that the charter and work plan need to be revised; this will be done on the list. The tentative work plan discussed in the meeting is: December 1995 Produce version 07 of the NHRPv1 spec, new LAG (was APR) draft. January 1996 Final calls on these documents, submit to IESG March 1996 Discuss companion documents-NHRPv1 Applicability Statement, MIB, Protocol Analysis, router-to-router (NHRP v2), server-to-server synchronization,transition plan, using shortcuts for IP multicasting June 1996 Discuss implementation/interoperability issues, finalize NHRPv1 companion documents, further discuss NHRPv2. December 1996 Complete NHRPv2. The meeting adjourned following this discussion. Later in the week, the ROLC and IPATM chairs met with the Routing Area Director (Joel Halpern) and the Internet Area Directors (Susan Thomson and Frank Kastenholz) to discuss the transition plan and direction of the working groups. The recommendations to the working groups from this meeting are that: The IPATM Classic2 draft should proceed with ATMARP and without reference to NHRP, and include ATMARP server synchronization. The IPATM and ROLC working groups should coordinate MIB development, explore leveraging the same server synchronization methods, and keep in mind that future IAB/IETF directions may require authenticated address registration (i.e., this is a heads up, and don't preclude a straightforward evolution to this as part of the synchronization work). A future ROLC RFC will be used to specify how to substitute NHRP for ATMARP; i.e., IPATM will continue to develop ATMARP in its work at this time.