CURRENT_MEETING_REPORT_ Reported by Greg Ruth/GTE Laboratories and Andrew Malis/Ascom Nexion Minutes of the Routing Over Large Clouds Working Group (ROLC) These minutes were reported by Greg Ruth and Andrew Malis with assistance from David Horton. The ROLC Working Group met in one session at the 33rd IETF. There were 87 attendees. Agenda o Agenda bashing o Classical IP over ATM update o ATM Forum/MPOA update o NARP and NHRP implementation experience o NHRP specification and open issues (draft-ietf-rolc-nhrp-04.txt) o Applicability Statement (draft-ietf-rolc-nhrp-appl-II.txt) o Protocol Analysis Document o NHRP MIB (draft-ietf-rolc-nhrp-mib-00.txt) o Status and workplan Classical IP over ATM Update Mark Laubach is updating the ``Classical IP and ARP over ATM'' RFC, and plans to have a new draft out by 1 August. A change in that document is that NHRP will be used as a fallback if there is no answer to the ATMARP request. The implication of this is that he needs an NHRP RFC to refer to, and he challenged the group to produce an RFC in time. ATM Forum/MPOA Update Joel Halpern gave a brief update on recent progress at the ATM Forum's MPOA (MultiProtocol Over ATM) SWG, chaired by George Swallow. Joel described the MPOA effort as closely paralleling the NHRP effort, but intended to be protocol independent supporting IP, IPX, DECNET-IV, Appletalk, etc. At the June 1995 meeting a baseline document was adopted as the basis for further development. The ATM Forum invites IETFers (and the world at large) to review this document and comment. There is a mutual desire to bring ROLC and MPOA standards into closer alignment with one another, the major current difference being NHRP's encapsulation in IP headers. The ATM Forum has provided public access to a few ATMF documents by the following means: o Web site: http://atmforum.com o Anonymous FTP from ftp.atmforum.com pub/contributions/atm94-0471.ps (P-NNI) pub/contributions/atm95-0824.ps or .txt (MPOA) It was recommended that you read the postscript version of the MPOA document. Two mailing lists will be set up to discuss the above documents with the public: o x-pnni@atmforum.com o x-mpoa@atmforum.com To register with either list, send a traditional subscription request to the -request mailbox. (Note: as of 1 August, these lists were not yet operational.) NARP and NHRP Implementation Experience No NARP implementation experience was reported. The chair reported that Ascom Nexion has an implementation in progress. Bruce Cole (Cisco) reported that he has an NHRP implementation now shipping. Support for purge messages has been added, no support for router-to-router, no real customer use yet. The implementation will be updated to reflect changes in the specification. David Horton (Centre for Information Technology Research, University of Queensland) presented some overheads concerning his implementation. To summarize, it implements both the NHRP client (NHC) and server (NHS) in the same device, and currently uses different protocol numbers to identify each. The server handles multiple LISs, includes an SNMP agent for monitoring, does not include server-server forwarding (yet), does support purge, and is SunOS-based. His future plans include one protocol number with the NHC and NHS choosing which packets to ignore when both receive, forwarding between multiple NHSs, extensions, SNMP R/W for configuration, and an NHC SNMP agent. NHRP Specification and Open Issues The working group next discussed some NHRP open issues from the mailing list. 0. Remove router-to-router parts of the specification from the NHRP document. Consensus was to allow all ``safe'' router-to-router cases to remain and reserve treatment of the rest to another document. This way the NHRP document (now referred to as NHRP Version 1) can go forward. Internet-Drafts dealing with the full router-router case were solicited for the Dallas meeting. The safe cases are those described in the NHRP specification as having the ``stable'' (B) bit set. 1. How should a client and server behind the same ATM address be distinguished? Three possible solutions are: a) give them different IP addresses; b) assign each different protocol numbers; c) let them sort out incoming NHRP messages between themselves. The consensus was that this is an implementation issue (it does not affect interoperability), and should not be included in the protocol specification. 2. Include destination address in Purge requests. Agreed. 3. Code Responder Address Extension and Prefix Extension consistently. Agreed. The Prefix Extension is now coded as a mask rather than an integer prefix length. 4. Add an ``Invalid Extension'' error code (9). Agreed. 5. Allow clients to send Purge Requests to servers (e.g. if the client is about to go down). Agreed. 6. Order extensions to facilitate parsing. Rejected. 7. Add an ``Invalid Reply Received'' error code (10), e.g., when no request was sent but a reply was received. Agreed. 8. Should we define a format for multiple Vendor Private Extension (VPE) entries or just allow multiple instances of VPEs. Allow multiple instances. 9. Preventing the ``domino effect'' (if a datagram is forwarded along the routed path, all the routers on the path will send NHRP Requests for the destination address). Various solutions were suggested, including having intermediate routers maintain a temporary state or requiring them not to initiate their own requests depending on the port data comes in on, but none was a clear win. Since the coexistence of different solutions will not impair interoperability, it was decided to let each implementer do as he chooses. The consensus was to document the problem in the draft, list the possible solutions, and require implementors to choose one. 10. Request for Address Prefix. Deferred (since this is a router-router issue, it does not have to be resolved in this draft.) 11. Router-router improvements. Deferred, for the same reason. The working group was asked if there were any other issues to discuss. Rob Coltun would like an NHRP request that goes to end stations, rather than the end station's NHS, so that the end station can do load sharing. For example, a file server may have multiple ATM interfaces between which it would like to spread the incoming load. The end station would indicate whether or not it should receive requests when it registers with its NHS. Rob was asked to write this up to discuss further over the list and at the next meeting. Applicability Statement Derya Cansever (GTE Laboratories) presented his latest draft of the applicability statement (draft-ietf-rolc-nhrp-appl-II.txt). It was suggested that for now the discussion of routing looping mention that, because the NHRP Version 1 specification will only treat ``safe'' router-to-router interactions, looping is not a problem for Version 1 of the protocol. The document will continue to include the description of the problem, so that the knowledge is not lost. It was also suggested that there should be a statement to the effect that NHRP is not, at present, appropriate for IP multicasting. Protocol Analysis Document The protocol analysis document has not been released yet, and the author, Kanan Shah, was not able to attend the Stockholm meeting. A draft is expected before the next IETF meeting. Kanan will be attending that meeting. NHRP MIB The new MIB editor, Avri Doria, was introduced to the working group. Avri has received the MIB document, along with all comments submitted to date. He is planning to roll currently received comments into the MIB. All are encouraged to read the MIB and comments already posted to the list, and to submit comments of your own. Removing IP Encapsulation and Server Mode During open discussion, Rob Coltun requested that the working group simplify NHRP, and allow it to be directly adopted by the ATM Forum MPOA group, by removing server mode and its IP encapsulation. During the discussion, Joel Halpern described how NHRP can be transitioned into a network without server mode. As NHRP is deployed, requests will begin to be sent to directly attached neighbors, along the routed path. If the next hop is also NHRP-capable, the request will be properly handled; if not, it will be dropped on the floor because the receiver does not recognize the protocol type. In that case, datagrams will simply follow the routed path as before, so nothing breaks. Configuration is much easier than it had been for server mode. The chair listed the necessary changes to the specification: o All server mode references must be removed from the text. o The IP encapsulation must be removed from the packet formats. o An LLC/SNAP encapsulation is required. The chair will send a request to the IANA for a PID codepoint in the IANA's OUI space. Given the scope of these changes, the chair asked for clear consensus for this change, and it was provided by the working group. There were no objections, including those with existing or ``in progress'' implementations. There was no support for retaining server mode. Work Plan The NHRP Version 1 specification will be updated (in a timely manner) based upon the above changes, and published as -05. Following review on the list and electronic working group consensus, it will be submitted to the Routing Area Director for IESG consideration as a Proposed Standard RFC. Internet-Drafts on the full router-router case are solicited for discussion over the list and at the Dallas meeting. The applicability statement and protocol analysis, when complete, will become Informational RFCs. We plan to submit the MIB as a Proposed Standard RFC following the Dallas meeting. The work plan in the charter will now read: Jul 95 Discuss implementation experience, NHRP open issues, companion documents. Aug 95 Submit NHRP Version 1 specification to the IESG as a Proposed Standard following post-Stockholm revisions. Dec 95 Discuss router-router case. After the Dallas meeting, submit the MIB to the IESG as a Proposed Standard, and Applicability Statement and Protocol Analysis for Version 1 as Informational RFCs. Mar 96 Finalize router-router case as NHRP Version 2; submit NHRP Version 2 as an upgrade to NHRP Version 1.