Editor's Note: These minutes have not been edited. Internetworking Over NBMA (ION) WG The meeting minutes were taken by Karen O'Donoghue and edited by George Swallow. Andy Malis and George Swallow chaired the ION working group meeting, which met during two sessions on Tuesday April 8, at 0900-1130 and 1300-1500. Andy presented the agenda and the current status of WG documents not being presented during the working group session. The following document is awaiting RFC publication: draft-armitage-ion-cluster-size (rumored to be RFC 2121) The following drafts are in various stages of IESG review: draft-ietf-iplpdn-frmib-dte (at the RFC editor) draft-ietf-ion-bcast (completed IESG last call) draft-ietf-ion-fr-update (completed IESG last call) draft-ietf-rolc-nhrp (on hold by IESG awaiting SCSP) draft-ietf-ion-marsmcs (Forwarded to IESG on 3/28/97) Additional documents in progress: draft-ietf-ion-mib (in progress) draft-ietf-nhrp-mib (in progress) draft-ietf-ion-mars-mib (in progress) draft-ietf-ion-sig-uni4.0 (next revision, 03, will be released after Memphis) draft-ietf-ion-inarp-update (will start WG last call after Memphis) draft-ietf-r2r-nhrp (work should continue in earnest after Memphis meeting) draft-carlson-nhrp-client (in progress) The following internet drafts were presented and discussed. 1. RFC 1577 Update, Mark Laubach and Joel Halpern, draft-ietf-ion-classic2 Joel Halpern presented the current status of the draft. The latest revision will be published shortly after the Memphis meeting. All comments raised on the mailing list were incorporated with the exception of the comment regarding E.164 NSAP addresses. It was not clear how to satisfy the comment within the scope of the current effort. It was reiterated that the intention of this document is to begin the transition to NHRP. A WG last call will be issued once the draft appears. 2. Next Hop Resolution Protocol (NHRP), Jim Luciani, draft-ietf-rolc-nhrp Jim Luciani made an informative presentation on NHRP, draft-ietf-rolc-nhrp-11, which has already gone through WG last call and has been forwarded to the IESG. The substantial changes to NHRP in revision 11 include the following: - the addition of an NHRP Resolution Reply NAK - removal of direct replies, - addition of an S bit, - renaming of the B bit to the D bit. The document is very stable at this point, but is being held up awaiting the completion of SCSP. 3. Server Cache Synchronization Protocol (SCSP), Jim Luciani, draft-ietf-ion-scsp The document has been divided as decided at the last meeting in San Jose. The essential mechanisms have been pulled into a protocol independent draft, "draft-ietf-ion-scsp". The nhrp and atmarp protocol specific portions have been moved to their own respective documents. The protocol independent piece will be going to going to WG last call. Another draft will be produced for each of the others. The significant changes to draft-ietf-ion-scsp include: - removal of nhrp and atmarp protocol specific portions to respective documents - hello, cache alignment, and cache state update on a per SG basis only - a clearer demarcation between protocol dependent and protocol independent portions - use of a cache key to identify an atomic element of synchronization - CSAS record to encapsulate all information necessary to identify the newness of an advertisement - CSA record reformatted to include 2 pieces (newness information and protocol specific portions) - generic fragmentation engine removed - additional information on SCSP point-to-multipoint and broadcast mediums - protocol ID (PID) field reintroduced - family ID mechanism introduced (allowing for grouping of hello protocol instances) - CSU replies now contain only CSAS records - removed P bit from CSA record - reworded cache alignment text SCSP-NHRP (draft-ietf-ion-scsp-nhrp): Significant aspects of this document include: - LIS = SG - procedures for when an NHC wishes to leave a SG - values for SCSP mandatory common part - values for SCSP CSAS records It was clarified that the ID assumes IPv4 addresses. The question about applicability to IPv6 was raised. It was pointed out that IPv6 would not be using NHRP to move registration information. SCSP-ATMARP (draft-ietf-ion-scsp-atmarp): Jim presented the first cut at this document. A key issue is what to do when an ATMARP client wishes to rejoin a SG. ATMARP doesn't have a requestID or a purge, therefore you have to wait. The current text tells the client what to do. The document needs to tell the server what to do in order that the client will not be able to crash the server. Joel Halpern presented some of the alternatives that could be used to address this problem. To summarize the status of the SCSP documents, the NHRP draft is being held by the IESG pending completion of the SCSP work. The SCSP protocol independent document is ready for working group last call. The SCSP-NHRP document is quite close to being ready. It was decided to continue discussion for one month on the mailing list and then to issue the WG last call. The SCSP-ATMARP document needs additional work. Joel Halpern agreed to help on this particular document. 4. NHRP Protocol Applicability Statement, Derya Canserver, draft-ietf-ion-nhrp-appl Derya Canserver presented the latest revision of the nhrp applicability document. M. Ohta voiced some concern that scalability issues raised on the mailing list were missing from the document. Group consensus appeared to be that the scalability issue was a concern, and that it was adequately discussed in the document. George Swallow voiced some concern about the statement that the r2r case was not addressed. Analysis has shown that the r2r case works fine if you are not crossing metric boundaries. George agreed to provide text to clarify this in the document. The intention of the WG group is to turn this document around quickly and get it out for a last call. 5. Transient Neighbors for IPv6 over ATM, Grenville Armitage, draft-ietf-ion-tn Grenville Armitage presented the document as released in March 1997. Major changes to the document include: * input from the San Jose meeting * augmented MARS now mandatory * rules for host tokens added * rules for host side packet forwarding clarified No issues were raised, and it is expected to go to WG last call soon. 6. MARS and SCSP, Grenville Armitage The document draft-armitage-ion-mars-scsp has not been revised since November 1996. It provides a general overview. A new document, draft-armitage-ion-distmars-spec, is a first cut at specific details of MARS using SCSP. Grenville realizes this document is incomplete. He asked for volunteers to assist in the development of the specification. 7. VENUS, Grenville Armitage, draft-armitage-ion-venus The WG last call on this document has now closed. There were some changes to the abstract suggested on the mailing list to clarify the intentions of the document. These changes are going to be made, and the document will be forwarded to the IESG as soon as possible for publication as an informational RFC. 8. EARTH, Michael Smirnow, draft-smirnow-ion-earth This work incorporates two major concepts: multicast logical IP subnets (MLIS) and multiprotocol over MLIS (MOM). There were a number of concerns raised during discussion of the document. The limitation of MARS to a single LIS was made to avoid some of the issues being raised with this document. The existing routing protocols will not work with this document. If the routing protocols are fixed and the MARS limitation is removed, it is unclear what the difference between this approach and MARS would be. While the working group appreciated his efforts, there was no consensus to accept this as a work item. It was decided to continue discussion on the mailing list. It may lead to an experimental RFC. Working group session adjourned at 1100 am and reconvened at 1300. 9. Intra LIS Multicast Routers over ATM, David Meyer, draft-farinacci-intralis-multicast This draft offers a simple means of multicast support for a LIS which contains no host. This document is based on the assumption that every router in a LIS knows (can obtain extra to this protocol) the IP and ATM addresses of all the other routers in the LIS. Each router maintains at least one point-to-multipoint VC that includes all the other routers in the LIS. It currently address PIM sparse-mode only, but the authors claim that the technique is extensible to other multicast protocols. There was consensus in the working group to address the topic. The solution may require optimizations to specific multicast routing protocols. Issues that need to be addressed include applicability, encapsulation, complexity, and interoperability. The authors agreed to carry the work forward to the mailing list. 10. Receiver Initiated Shortcut Path (RISP), Yao-Min Chin, draft-ogawa-receiver-shortcut-path Yao-Min Chen presented RISP, draft-ogawa-receiver-shortcut-path.00. The discussion showed that this largely covered ideas that the WG had considered in developing NHRP, but were not incorporated. Since the functionality is close to NHRP, the draft was not accepted. The authors were encouraged to bring forward a draft for a receiver initiated call as an option to NHRP. 11. Intra-area IP unicast among routers over legacy ATM, Juha Heinanen Juha Heinanen made a presentation on using ATM addresses carried in opaque LSA in OSPF as a means for accomplishing IP unicast among routers within an OSPF area. It was noted that similar mechanisms could be incorporated into IS-IS and BGP. The primary motivation is to provide a simple solution in the near term. Juha felt that label switching would not address the problem because: it would take too long to develop; upgrading ATM networks is not easy or cheap; need a solution supported by the public ATM network. Some key assumptions of this proposal include: the set of routers is small enough to form a single area for the link state routing protocol; and the maximum number of routers is less than 100. The majority of the technical work is currently going on in the OSPF working group. Rob Coulton briefly discussed the technical work being pursued in OSPF. This working group will most likely result in an informational RFC to document how to take advantage of the OSPF work. End of minutes ====================================================================== George Swallow Cisco Systems (508) 244-8143 250 Apollo Drive Chelmsford, Ma 01824