home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ion / ion-minutes-97apr.txt < prev    next >
Text File  |  1997-05-29  |  11KB  |  234 lines
  1. Editor's Note:  These minutes have not been edited.
  2.  
  3.  
  4. Internetworking Over NBMA (ION) WG
  5.  
  6. The meeting minutes were taken by Karen O'Donoghue and edited by George Swallow.
  7.  
  8. Andy Malis and George Swallow chaired the ION working group meeting, which
  9. met during two sessions on Tuesday April 8, at 0900-1130 and 1300-1500.
  10.  
  11. Andy presented the agenda and the current status of WG documents not being
  12. presented during the working group session.
  13.  
  14. The following document is awaiting RFC publication:
  15.         draft-armitage-ion-cluster-size (rumored to be RFC 2121)
  16.  
  17. The following drafts are in various stages of IESG review:
  18.         draft-ietf-iplpdn-frmib-dte (at the RFC editor)
  19.         draft-ietf-ion-bcast (completed IESG last call)
  20.         draft-ietf-ion-fr-update (completed IESG last call)
  21.         draft-ietf-rolc-nhrp (on hold by IESG awaiting SCSP)
  22.         draft-ietf-ion-marsmcs (Forwarded to IESG on 3/28/97)
  23.  
  24. Additional documents in progress:
  25.         draft-ietf-ion-mib (in progress)
  26.         draft-ietf-nhrp-mib (in progress)
  27.         draft-ietf-ion-mars-mib (in progress)
  28.         draft-ietf-ion-sig-uni4.0 (next revision, 03, will be released after
  29.                                     Memphis)
  30.         draft-ietf-ion-inarp-update (will start WG last call after Memphis)
  31.         draft-ietf-r2r-nhrp (work should continue in earnest after Memphis
  32.                               meeting)
  33.         draft-carlson-nhrp-client (in progress)
  34.  
  35. The following internet drafts were presented and discussed.
  36.  
  37. 1.  RFC 1577 Update, Mark Laubach and Joel Halpern, draft-ietf-ion-classic2
  38.  
  39. Joel Halpern presented the current status of the draft.  The latest
  40. revision will be published shortly after the Memphis meeting. All comments
  41. raised on the mailing list were incorporated with the exception of the
  42. comment regarding E.164 NSAP addresses.  It was not clear how to satisfy
  43. the comment within the scope of the current effort. It was reiterated that
  44. the intention of this document is to begin the transition to NHRP.  A WG
  45. last call will be issued once the draft appears.
  46.  
  47. 2.  Next Hop Resolution Protocol (NHRP), Jim Luciani, draft-ietf-rolc-nhrp
  48.  
  49. Jim Luciani made an informative presentation on NHRP,
  50. draft-ietf-rolc-nhrp-11, which has already gone through WG last call and
  51. has been forwarded to the IESG. The substantial changes to NHRP in revision
  52. 11 include the following:
  53.     - the addition of an NHRP Resolution Reply NAK
  54.     - removal of direct replies,
  55.     - addition of an S bit,
  56.     - renaming of the B bit to the D bit.
  57.  
  58. The document is very stable at this point, but is being held up awaiting
  59. the completion of SCSP.
  60.  
  61. 3.  Server Cache Synchronization Protocol (SCSP), Jim Luciani,
  62. draft-ietf-ion-scsp
  63.  
  64. The document has been divided as decided at the last meeting in San Jose.
  65. The essential mechanisms have been pulled into a protocol independent
  66. draft, "draft-ietf-ion-scsp".  The nhrp and atmarp protocol specific
  67. portions have been moved to their own respective documents.  The protocol
  68. independent piece will be going to going to WG last call.  Another draft
  69. will be produced for each of the others.
  70.  
  71. The significant changes to draft-ietf-ion-scsp include:
  72.   -  removal of nhrp and atmarp protocol specific portions to respective
  73.       documents
  74.   -  hello, cache alignment, and cache state update on a per SG basis only
  75.   -  a clearer demarcation between protocol dependent and protocol independent
  76.       portions
  77.   -  use of a cache key to identify an atomic element of synchronization
  78.   -  CSAS record to encapsulate all information necessary to identify the
  79.       newness of an advertisement
  80.   -  CSA record reformatted to include 2 pieces (newness information and
  81.       protocol specific portions)
  82.   -  generic fragmentation engine removed
  83.   -  additional information on SCSP point-to-multipoint and broadcast mediums
  84.   -  protocol ID (PID) field reintroduced
  85.   -  family ID mechanism introduced (allowing for grouping of hello protocol
  86.       instances)
  87.   -  CSU replies now contain only CSAS records
  88.   -  removed P bit from CSA record
  89.   -  reworded cache alignment text
  90.  
  91. SCSP-NHRP (draft-ietf-ion-scsp-nhrp):  Significant aspects of this document
  92. include:
  93.   -  LIS = SG
  94.   -  procedures for when an NHC wishes to leave a SG
  95.   -  values for SCSP mandatory common part
  96.   -  values for SCSP CSAS records
  97. It was clarified that the ID assumes IPv4 addresses.  The question about
  98. applicability to IPv6 was raised. It was pointed out that IPv6 would not be
  99. using NHRP to move registration information.
  100.  
  101. SCSP-ATMARP (draft-ietf-ion-scsp-atmarp):  Jim presented the first cut at
  102. this document. A key issue is what to do when an ATMARP client wishes to
  103. rejoin a SG. ATMARP doesn't have a requestID or a purge, therefore you have
  104. to wait. The current text tells the client what to do. The document needs
  105. to tell the server what to do in order that the client will not be able to
  106. crash the server. Joel Halpern presented some of the alternatives that
  107. could be used to address this problem.
  108.  
  109. To summarize the status of the SCSP documents, the NHRP draft is being held
  110. by the IESG pending completion of the SCSP work. The SCSP protocol
  111. independent document is ready for working group last call. The SCSP-NHRP
  112. document is quite close to being ready. It was decided to continue
  113. discussion for one month on the mailing list and then to issue the WG last
  114. call. The SCSP-ATMARP document needs additional work. Joel Halpern agreed
  115. to help on this particular document.
  116.  
  117. 4.  NHRP Protocol Applicability Statement, Derya Canserver,
  118.       draft-ietf-ion-nhrp-appl
  119.  
  120. Derya Canserver presented the latest revision of the nhrp applicability
  121. document.  M. Ohta voiced some concern that scalability issues raised on
  122. the mailing list were missing from the document.  Group consensus appeared
  123. to be that the scalability issue was a concern, and that it was adequately
  124. discussed in the document.  George Swallow voiced some concern about the
  125. statement that the r2r case was not addressed.  Analysis has shown that the
  126. r2r case works fine if you are not crossing metric boundaries.  George
  127. agreed to provide text to clarify this in the document.  The intention of
  128. the WG group is to turn this document around quickly and get it out for a
  129. last call.
  130.  
  131. 5.  Transient Neighbors for IPv6 over ATM, Grenville Armitage,
  132.       draft-ietf-ion-tn
  133.  
  134. Grenville Armitage presented the document as released in March 1997.  Major
  135. changes to the document include:
  136. *  input from the San Jose meeting
  137. *  augmented MARS now mandatory
  138. *  rules for host tokens added
  139. *  rules for host side packet forwarding clarified
  140.  
  141. No issues were raised, and it is expected to go to WG last call soon.
  142.  
  143. 6.  MARS and SCSP, Grenville Armitage
  144.  
  145. The document draft-armitage-ion-mars-scsp has not been revised since
  146. November 1996.  It provides a general overview.  A new document,
  147. draft-armitage-ion-distmars-spec, is a first cut at specific details of
  148. MARS using SCSP.  Grenville realizes this document is incomplete.  He asked
  149. for volunteers to assist in the development of the specification.
  150.  
  151. 7.  VENUS, Grenville Armitage, draft-armitage-ion-venus
  152.  
  153. The WG last call on this document has now closed.  There were some changes
  154. to the abstract suggested on the mailing list to clarify the intentions of
  155. the document.  These changes are going to be made, and the  document will
  156. be forwarded to the IESG as soon as possible for publication as an
  157. informational RFC.
  158.  
  159. 8.  EARTH, Michael Smirnow, draft-smirnow-ion-earth
  160.  
  161. This work incorporates two major concepts: multicast logical IP subnets
  162. (MLIS) and multiprotocol over MLIS (MOM). There were a number of concerns
  163. raised during discussion of the document. The limitation of MARS to a
  164. single LIS was made to avoid some of the issues being raised with this
  165. document. The existing routing protocols will not work with this document.
  166. If the routing protocols are fixed and the MARS limitation is removed, it
  167. is unclear what the difference between this approach and MARS would be.
  168. While the working group appreciated his efforts, there was no consensus to
  169. accept this as a work item.  It was decided to continue discussion on the
  170. mailing list. It may lead to an experimental RFC.
  171.  
  172. Working group session adjourned at 1100 am and reconvened at 1300.
  173.  
  174. 9.  Intra LIS Multicast Routers over ATM, David Meyer,
  175.      draft-farinacci-intralis-multicast
  176.  
  177. This draft offers a simple means of multicast support for a LIS which
  178. contains no host. This document is based on the assumption that every
  179. router in a LIS knows (can obtain extra to this protocol) the IP and ATM
  180. addresses of all the other routers in the LIS. Each router maintains at
  181. least one point-to-multipoint VC that includes all the other routers in the
  182. LIS. It currently address PIM sparse-mode only, but the authors claim that
  183. the technique is extensible to other multicast protocols. There was
  184. consensus in the working group to address the topic.  The solution may
  185. require optimizations to specific multicast routing protocols. Issues that
  186. need to be addressed include applicability, encapsulation, complexity, and
  187. interoperability. The authors agreed to carry the work forward to the
  188. mailing list.
  189.  
  190. 10.  Receiver Initiated Shortcut Path (RISP), Yao-Min Chin,
  191.       draft-ogawa-receiver-shortcut-path
  192.  
  193. Yao-Min Chen presented RISP, draft-ogawa-receiver-shortcut-path.00.  The
  194. discussion showed that this largely covered ideas that the WG had
  195. considered in developing NHRP, but were not incorporated.  Since the
  196. functionality is close to NHRP, the draft was not accepted.  The authors
  197. were encouraged to bring forward a draft for a receiver initiated call as
  198. an option to NHRP.
  199.  
  200. 11.  Intra-area IP unicast among routers over legacy ATM, Juha Heinanen
  201.  
  202. Juha Heinanen made a presentation on using ATM addresses carried in opaque
  203. LSA in OSPF as a means for accomplishing IP unicast among routers within an
  204. OSPF area.  It was noted that similar mechanisms could be incorporated into
  205. IS-IS and BGP.
  206.  
  207. The primary motivation is to provide a simple solution in the near term.
  208. Juha felt that label switching would not address the problem because: it
  209. would take too long to develop; upgrading ATM networks is not easy or
  210. cheap; need a solution supported by the public ATM network.
  211.  
  212. Some key assumptions of this proposal include:  the set of routers is small
  213. enough to form a single area for the link state routing protocol; and the
  214. maximum number of routers is less than 100.
  215.  
  216. The majority of the technical work is currently going on in the OSPF
  217. working group. Rob Coulton briefly discussed the technical work being
  218. pursued in OSPF. This working group will most likely result in an
  219. informational RFC to document how to take advantage of the OSPF work.
  220.  
  221. End of minutes
  222.  
  223.  
  224.  
  225.  
  226.  
  227. ======================================================================
  228. George Swallow       Cisco Systems                   (508) 244-8143
  229.                      250 Apollo Drive
  230.                      Chelmsford, Ma 01824
  231.  
  232.  
  233.  
  234.