Editor's note: These minutes have not been edited. Minutes of the Internetworking over NBMA (ion) Working Group Montreal IETF, 24 June 1996 1300-1500 and 25 June 1996 1300-1500 and 1530-1730. Notes were taken by Karen O'Donoghue. (Many thanks from the Chairs). The ion group met in three sessions at this IETF with a total of 279 attendees. The sessions were co-chaired by Andrew Malis (malis@nexen.com) and George Swallow (swallow@cisco.com). The first session was primarily devoted to ongoing efforts (status, NHRP, RFC 1577 update, and RFC 1755 update). The second session dealt with IPv6, and the third session addressed multicast. First session, Monday 6/24, 1300-1500: - Agenda Bashing and Administrivia Andy Malis introduced the new working group, Internetworking over NBMA (ion), and the new co-chair, George Swallow. In addition, he thanked Mark Laubach for his efforts as chair of the IP Over ATM (ip- atm) working group. The proposed agenda for the three sessions was discussed and accepted. The first issue addressed was one that was inherited from the iplpdn working group, the Frame Relay DTE MIB. This document (draft-ietf- iplpdn-frmib-dte-07.txt) is currently in last call. A few minor issues have come up, and these will be worked on the mailing list. If these issues require extensive discussions, this ID may be moved to the new Frame Relay services MIB working group currently being chartered. The second issue addressed was the naming of internet drafts for this working group. An ID which has achieved some working group consensus, has an editor, and can be viewed as working group output should use "draft-ietf-ion" in the name. An ID which represents the views of the author and for which the working group chairs have been notified of the incoming draft, should use "draft-author-ion" in the name. A primary motivation for this approach is to give the co-chairs a "heads-up" on incoming documents. Unannounced drafts may be submitted as is the IETF custom; however, the name of the draft should include the author but not "ietf" or "ion". - ATM Forum Activities Joel Halpern gave a short update on ATM Forum activities. The ATM Forum has agreed in principle to make available all approved documents in a public ftp site (ftp.atmforum.com); however, complete implementation of this is still underway. In particular, the traffic management specification is available; however, the PNNI document is not yet on the site. George Swallow gave an update on the MPOA activities of the ATM Forum. The MPOA work is progressing. Since the last IETF meeting, the MPOA WG has defined mandatory behavior for edge devices and addressed NHRP extensions to support edge devices. In particular a 'trigger' message has been defined which allows a route server to request that an edge device initiate a NHRP query. Also, a cache imposition protocol has been defined. This allows the final router to install the proper exit encapsulation in the exit edge device. Tags are available to optimize exit processing. These will be carried in a TLV. - MARS Update Andy Malis provided an update of the MARS document. Version 12 of the MARS document was voted out by the ip-atm working group at the Los Angeles IETF. However, this document fell through the cracks during the IESG turnover. The IESG last call was issued in June and will close July 2. In the absence of any significant comments, this document should go to the RFC editor soon for publication as a proposed standard. - NHRP Jim Luciani provided a discussion on the changes that were incorporated in NHRP Rev 8 (draft-ietf-rolc-nhrp-08). A fairly detailed list of changes is provided in the slides for this discussion. A number of issues were identified and discussed: 1. NHRP Subnetwork ID - This was originally thought to be an interesting idea, but it is a pain to implement. When asked, no one indicated that they were currently or planning to use it; therefore, it was removed. 2. Reuse of CIE for extensions - The information in the CIE (Client Information Entry) is also present in several extentions, but formatted differently. The proposal was to use the same format to make parsing simpler. This seemed reasonable to the group. 3. MD5 authentication and sequencing of extensions - There was fairly lengthy discussion on this topic. The final outcome was that "Ordering of the extensions inserted by the sender must be preserved and must be inserted first in the list." Fields requiring MD5 authentication will come first. The MD5 authentication comes next, followed by fields not covered by the authentication. Thus the authentication TLV servers as the delimiter between the authenticated and unauthenticated portions of the message. 4. Routing of Registration Requests - Allow an NHC to include its protocol address as the destination protocol address and let the routed path get the packet to a correct NHS. This allows routing to deal with the issue. This also was accepted. Jim will generate revision 09. Since we appear to have reached consensus on all of the open issues, we anticipate going to working group last call shortly after the next draft is available. - Serve Cache Synchronization Protocol Jim Luciani next provided a discussion of the Server Cache Synchronization Protocol (SCSP) (draft-luciani-rolc-scsp-03.txt). This document is the combination of Joel Halpern's and Jim Luciani's input to the Los Angeles IETF. It has been chosen as the baseline for the SCSP effort. Changes since the last presentation include: the concept of a Server group ID (SGID) was added; SCSP was defined as a stand-alone protocol with a header; ATMARP and NHRP encodings in the current draft were put in appendices; and MARS encodings were broken out into a different specification. SCSP has been adopted by LANE and MPOA. Discussion followed on spanning tree versus designated servers. No major issues were identified in the discussions. However, given the recent availability of the draft, further discussion is encouraged on the list. - RFC 1577 Update Mark Laubach discussed the latest status of the RFC 1577 update (draft-ietf-ion-classic2-02). Since the last meeting, all references to server synchronization have been removed, appendices have been removed, and a table of contents has been added. The latest draft also includes a pointer to the Classical MIB ID and includes the MTU material from RFC 1626. There was some discussion on whether or not the MTU specification should be a separate document. It was decided to leave the MTU material in the RFC 1577 update. The authors requested the opportunity to make one final pass at the document. It is anticipated that this will go to wg final call shortly after its appearance. - ATM Signaling Support for IP Maryann Perez Maher provided a discussion of the RFC 1755 update (draft-ietf-ion-sig-uni4.0-00) to incorporate UNI 4.0. The focus of this effort is support for best-effort IP. The UBR service category is most natural, but the others are allowed as well. Traffic parameter negotiation is encouraged. Frame discard is a must. It was felt that ABR should be described further. The issll working group will discuss ABR. Given the recent availability of the draft, further discussion is encouraged on the list. Second session, Tuesday, 6/25 1300-1500: - IPv6 and Neighbor Discovery Grenville Armitage provided an overview of the working group concepts and issues for IPv6 over NBMA. The current document (draft- ietf-ion-ipv6nd-00.txt) reflects the general consensus of the working group up to this point, and lists issues remaining to be resolved. To support NBMA, IPv6 links become "logical links". Neighbors are nodes on the logical link or announced through the IPv6 ND Redirect. IPv6 neighbor discovery is one layer up from IPv4 "ARP" and is generic across link technologies. IP multicast is assumed meaning MARS will be a fundamental component. Some open issues include link local address generation and how to perform intra-LL ND while allowing the discovery of "shortcut" paths. - Transient Neighbors for IPv6 over ATM In this discussion, Grenville Armitage provided his opinion (as contained in draft-armitage-ion-tn-00) on some of the issues regarding neighbor discovery for IPv6. In particular, he felt that neighbor discovery was generally necessary and sufficient, containing most of what is needed. The work is a revision of a model presented at the LA IETF. This model tries to use conventional host-side operation of the ND protocol while still allowing the establishment of cut-through ATM routes. This is done using Redirects to create Transient Neighbors, IPv6 protocol operation, and partial NHRP for location of off-link destinations. The egress router identifies candidates for cut-through, uses NHRP to find a better first hop, then issues a redirect to the source. - A Framework for IPv6 over ATM Markus Jork presented the material contained in draft-ietf-ion- ipv6atm- framework-00. Goals of this work include: 1) define what an IPv6 "link" is on ATM networks; 2) provide full IPv6 ND over ATM networks; 3) require no new protocols to perform ND functions; 4) require no changes to the IPv6 network layer for ATM; 5) maintain IPv6 address configuration models; 6) maintain IPv6 security models and associations; 7) utilize existing technology; 8) maintain all ND, addrconf, and security semantics; 9) scalable; 10) provide fault tolerance, redundancy and failover; 11) minimize/eliminate ATM server state information; and 12) be simple and easy to implement. - IPv6 over NBMA Networks Ran Atkinson presented the work contained in draft-ietf-ion-ipv6- nbma-00. In this draft, NHRP is used to provide IPv6 Neighbor Discovery and Address Autoconfiguration support. Ran discussed IPv6 interface tokens, duplicate address detection, and address resolution. Interface tokens use IEEE 802 addresses where possible. Alternatively, E.164, X.121 or NSAP-like addresses can be utilized. Duplicate address detection would add a uniqueness bit and modest extensions to NHRP with NHRP providing duplicate address detection. At this point, the chairs opened the floor for discussion of the three proposals presented. There were a number of clarification questions on the three presentations. Referring to draft-ietf-ion-ipv6atm-framework-00, Joel Halpern asked whether or not we really wanted two multicast mechanisms. Markus responded that a second mechanism wasn't necessary and that MARS could be used instead. After some discussion, the chairs asked each of the presenters what they believed the differences in the proposals were and what the best way forward would be. The general consensus was that the major difference was where to run NHRP (on the host or on the router). It was also urged that the solution to neighbor discovery should attempt to minimize the use of multicast/broadcast as the number of possible recipients could be quite large. There was agreement that a merged draft will be produced from the three proposals with a goal to have one server (MARS) instead of two. This draft is expected in advance of the next IETF meeting. Third session, Tuesday, 6/25 1530-1730 - Multicast Server Architectures for MARS based ATM Multicasting - Multiple MCS support using an enhanced version of the MARS server Rajesh Talpade presented his two drafts (draft-talpade-ion-marsmcs- 00 and draft-talpade-ion-multiplemcs-00) in a combined presentation. The multiple MCS approach provides for fault tolerance, load sharing, and auto configuration with minimal changes needed to MARS. The definition of how to coordinate several Multicast Servers within MARS was accepted as a new work item, with draft-talpade-ion- marsmcs-00 forming the base of this work. The second draft describes the more general multiple MCS mechanism for fault-tolerance and load sharing using MARS, and is the subject of ongoing research. One discussion point was the mechanism used to coordinate multiple MCSs. Use of SCSP directly between MCSs was discussed as a mechanism for coordinating MCSs. The consensus of the group that a second layer of control was not advisable. MCSs get their information from MARS, so the information can be expected to be consistent. The consensus of the group was that the coordination function should be part of MARS. - On the use of MARS and SCSP together Grenville Armitage presented a draft on distributed MARS architectures and SCSP (draft-armitage-ion-mars-scsp-00). He presented a summary of MARS concepts, a discussion of fault tolerant and load sharing scenarios, and a discussion of open issues. Motivations for multiple MARS include fault tolerance and load sharing. For fault tolerance, there are multiple MARSs, but only one is serving the entire Cluster at any one time. For load sharing, there are multiple MARSs partitioning the Cluster between them. The multiple MARSs in the load sharing scenario doesn't necessarily provide fault tolerance. Various issues were raised: How is the information between the MARSs coordinated? Where are cache synchronization protocols appropriate? There was general consensus that load sharing and reduncancy should both be addresses by a single mechanisms. It was also generally agreed that SCSP should be part of the solution, though the extent of its use was not agreed. Grenville will produce a new draft with a more concrete proposal. - Using the MARS model in non-ATM NBMA networks Grenville Armitage presented a quick overview of his draft (draft- armitage- ion-mars-nbma-00) on the applicability of the MARS model to other NBMA networks. No specific actions were requested from the draft. It was provided as material for supporting the new ion charter. - MARS MIB Chris Chung presented the draft of the MARS MIB (draft-ietf-ion- mars-mib-00) authored by himself and Maria Greene. This draft is based on version 12 of the MARS specification. A survey was taken to see how many had implemented the IP- ATM MIB (8) and the NHRP MIB (5). - Multicast Inscalability Masataka Ohta presented his draft on multicast scaling issues (draft- ietf- ohta-mcast-large-cloud-01). The author pointed out that NHRP may not be usable in some scenarios. The group concluded that this was orthogonal to the overall utility of NHRP. The author was invited to address these issues in the NHRP applicability statement. In addition, a future work item for this group would be to address the scalability of multicast. End of Minutes