home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ion / ion-minutes-96dec.txt < prev    next >
Text File  |  1997-01-30  |  8KB  |  178 lines

  1. Editor's note:  These minutes have not been edited.
  2.  
  3. Internetworking Over NBMA (ION) WG
  4.  
  5. The meeting minutes were taken by Karen O'Donoghue and Mike Davison,
  6. and edited by Andy Malis.
  7.  
  8. Andy Malis and George Swallow chaired the working group meeting, which
  9. met over two sessions, Monday 12/9/96 1530-1730, and Tuesday 12/10/96
  10. 1530-1730.  There were 276 attendees.
  11.  
  12. Andy presented the agenda and the current status of those WG documents
  13. not being presented.  There was one new RFC since the Montreal
  14. meeting: RFC 2022, Support for Multicast over UNI 3.0/3.1 based ATM
  15. Networks, by Grenville Armitage. Congratulations and appreciation were
  16. extended to Grenville.
  17.  
  18. The following drafts have completed WG last call:
  19. draft-ietf-iplpdn-frmib-dte (in IESG review)
  20. draft-ietf-rolc-nhrp (Submitted to IESG on 10/22)
  21. draft-armitage-ion-cluster-size (Completed on 11/22)
  22. draft-ietf-ion-bcast (11/22)
  23. draft-ietf-ion-fr-update (12/6)
  24. The last three will be submitted to the IESG in short order.
  25.  
  26. The following other drafts are in progress on the list:
  27. draft-ietf-ion-mib, draft-ietf-ion-nhrp-mib, draft-ietf-ion-mars-mib,
  28. draft-ietf-ion-sig-uni4.0, and draft-ietf-ion-inarp-update.
  29.  
  30. George gave a brief ATM Forum MPOA update. A major change was made to
  31. the MPOA architecture that significantly reduced the complexity of the
  32. effort.  A simpler client/server model has been developed, and SCSP
  33. will be used to synchronize MPOA servers.  The MPOA effort is now
  34. about 99% complete.
  35.  
  36. The following internet drafts were presented and discussed:
  37.  
  38. 1. Transient Neighbors for IPv6 over ATM, Grenville Armitage et al,
  39.    draft-armitage-ion-tn
  40.  
  41. This was the first of two proposals for IPv6 neighbor discovery over
  42. ATM.  The goal was to have a single approach identified with which to
  43. proceed.  This draft is a revised draft based on collaborative efforts
  44. after the Montreal IETF, to combine two of the three drafts presented
  45. there. The proposal calls for the MARS Cluster Control VC to be used
  46. to multicast IPv6 Neighbor Discovery packets within a LIS, and NHRP is
  47. used between LISes in conjunction with Neighbor Discovery redirects.
  48. There were varied opinions expressed on the use of ND redirect,
  49. several suggested improvements: the addition on the capability to
  50. specify "this is the address I want to create a short cut to", and
  51. clarifications on some of the diagrams.  Grenville is going to update
  52. the draft to reflect his talk and the discussion.  This draft is now
  53. the current working group consensus for IPv6 neighbor discovery over
  54. ATM.
  55.  
  56. 2. IPv6 over NBMA Networks, Ran Atkinson, draft-ietf-ion-ipv6-nbma
  57.  
  58. This draft was not presented.
  59.  
  60. 3. RFC 1577 Update, Mark Laubach and Joel Halpern,
  61.    draft-ietf-ion-classic2
  62.  
  63. Joel Halpern presented the current status of the draft.  It correct
  64. all known problems with RFC 1577 behaviors, provides hooks for
  65. migration to NHRP, and folds in the MTU material.  There will shortly
  66. be a working group last call on the draft.
  67.  
  68. 4. Classical IP to NHRP Transition Plan, Jim Luciani,
  69.    draft-ietf-ion-transition
  70.  
  71. Jim discussed how Classical IP over ATM networks can be gracefully
  72. transitioned to using NHRP. The key points are:
  73.  
  74. * The problem was simplified by not requiring ATMARP and NHRP servers
  75.   to co-exist in the same LIS; instead, NHRP servers implement an
  76.   ATMARP interface, and a single shared translation database will be
  77.   used.
  78.  
  79. * ATMARP clients will not require any changes.
  80.  
  81. * ATMARP queries will generate responses derived from ATMARP only,
  82.   while NHRP responses may be generated based on data learned via
  83.   either ATMARP or NHRP.
  84.  
  85. Jim will update the draft.
  86.  
  87. 5. NHRP Applicability Statement, Derya Cansever,
  88.    draft-ietf-ion-nhrp-app
  89.  
  90. Derya presented the current version of the applicability statement.  A
  91. questioner asked for an example of when NHRP should be used (answer:
  92. when a particular link-layer QoS would be preferable to best-effort
  93. router-to-router service), and there were several suggestions for
  94. improving the document: adding a discussion of the looping problems
  95. described in the router-router NHRP document, and adding a discussion
  96. of NHRP's scaling problems for IP multicast.  Derya will update the
  97. draft.  Masataka Ohta also volunteered to begin work on a separate
  98. informational document on NHRP scalability.
  99.  
  100. 6. Server Cache Synchronization Protocol (SCSP), Jim Luciani,
  101.    draft-luciani-rolc-scsp
  102.  
  103. Comments from the mailing list and the previous ion meeting have been
  104. added to the specification.  The portions of the document that
  105. discussed MARS/MCS have been removed; MARS and MCSes will be discussed
  106. in a separate document.  A last call will be issued on the draft.
  107.  
  108. 7. Multicast Synchronization Protocol (MSP), Eric Mannie,
  109.    draft-mannie-stc-ion-msp
  110.  
  111. Eric presented MSP, which is an alternative server synchronization
  112. protocol.  During the Q&A period it was observed that this proposal
  113. did not provide new functionality over SCSP or a compelling reason for
  114. the WG to switch to its use.
  115.  
  116. 8. Redundant MARS architectures and SCSP, Grenville Armitage,
  117.    draft-armitage-ion-mars-scsp
  118.  
  119. Grenville presented an overview of the issues surrounding
  120. synchronization of multiple MARS servers. A few significant points
  121. were:
  122.  
  123. * Clients should not require modification and should "see" a single
  124.   server at any given time.
  125.  
  126. * Fault tolerance. The current MARS specification provides an
  127.   architecture for basic fault tolerance, although there may be race
  128.   conditions.
  129.  
  130. * Load Sharing. In large clouds it would be useful to distribute the
  131.   MARS server functionality.
  132.  
  133. 9. VENUS - Very Extensive Non-Unicast Service, Grenville Armitage,
  134.    draft-armitage-ion-venus
  135.  
  136. Grenville Armitage presented his VENUS document. He discussed "from
  137. MARS to VENUS, and points in between." His major point is that
  138. multicast shortcuts are a significant problem, and should not be used
  139. until better understood.  A working group last call will be issued on
  140. progressing this document as an informational RFC.
  141.  
  142. 10. Multicast Server Architectures for MARS-based ATM Multicasting,
  143.     Rajesh Talpade, draft-ietf-ion-marsmcs
  144.  
  145. Rajesh presented his draft; there was very little discussion following
  146. his presentation. The intention is to issue a working group last call
  147. on progressing this document as an information RFC.
  148.  
  149. 11. EARTH - EAsy IP multicast Routing THrough ATM clouds, Michael
  150.     Smirnov, draft-smirnov-ion-earth
  151.  
  152. Michael presented EARTH, which "is positioned between MARS and VENUS".
  153. During the discussion, the point was made that Michael seemed to have
  154. duplicated some of MARS' functionality, and the differences between
  155. his draft and MARS were clarified.  He will update the document based
  156. upon the discussion.
  157.  
  158. 12. Another ATM Signaling Protocol for IP (IP-SVC), Kenji Fujikawa,
  159.     draft-fujikawa-ipsvc
  160.  
  161. Kenji presented his draft, which outlines the results of his research
  162. into an alternative ATM signaling protocol.  The protocol was designed
  163. to be simple, useful in small LANs, and support auto-configuration.
  164. Although this was thought to be an interesting idea, there were
  165. concerns about the limited scalability of the approach.  In addition,
  166. it is explicit in the ION working group charter that the group may not
  167. work on ATM-layer signaling.  It was decided to continue discussion on
  168. the future of this document on the mailing list, since it would
  169. require WG consensus (and the agreement of the area directors) to
  170. change the WG's charter to include this work.
  171.  
  172. End of minutes
  173. ________________________________________________________________________
  174. Andrew G. Malis   malis@casc.com   phone:508 952-7414   fax:508 392-9250
  175. Cascade Communications Corp.      5 Carlisle Road     Westford, MA 01886
  176.  
  177.  
  178.