home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rolc / rolc-minutes-95dec.txt < prev    next >
Text File  |  1996-06-03  |  12KB  |  259 lines
  1. CURRENT MEETING REPORT
  2.  
  3.  
  4. Reported by Howard Berkowitz, PSC International and Andrew Malis, 
  5. Ascom Nexion, Inc.
  6.  
  7. Minutes of the Routing Over Large Clouds Working Group (ROLC)
  8.  
  9.  
  10. The ROLC Working Group met in two sessions at this IETF.  There were
  11. approximately 145 attendees.
  12.  
  13. Agenda:
  14.  
  15. o  First Session
  16. o  Agenda bashing
  17. o  ATM Forum MPOA update
  18. o  Joint statement by the IPATM and ROLC chairs
  19. o  NHRP specification and open issues--draft-ietf-rolc-nhrp-06.txt
  20.  
  21. o  Second Session
  22. o  ATM Forum Liaison
  23. o  Local/Remote Forwarding Decision--draft-ietf-rolc-apr-03.txt
  24. o  Mobile NHRP Devices--draft-horikawa-mobile-nhrp-00.txt
  25. o  ATMARP/NHRP Translation
  26. o  Router-Router NHRP
  27. o  Status and Workplan
  28.  
  29.  
  30. SESSION ONE
  31.  
  32.  
  33. ATM Forum MPOA Update
  34.  
  35. George Swallow, the ATM Forum Multi-Protocol Over ATM (MPOA) 
  36. Sub-Working Group Chair, reported that the MPOA current approach 
  37. is  based upon NHRP and MARS.  No protocol design is being done; 
  38. NHRP  "out-of-the-box" is desired.  The MPOA SWG appreciates the 
  39. work  being done in the IETF to harmonize NHRP and MARS.  There is 
  40. very little interest in the ATM Forum in RFC 1577 (Classical IP over 
  41. ATM).  ATM Forum LAN Emulation (LANE) is used at layer 2.  Both 
  42. "edge devices" and routers are supported by MPOA.  Server redundancy  
  43. is a major concern.  MPOA has additional concerns, such as edge device-
  44. to-edge-device connectivity.  The external ATM Forum MPOA and 
  45. PNNI mailing lists, as reported at the Stockholm ATM Forum BOF, 
  46. still have not been set up by the ATM Forum.  It is premature for  the 
  47. IETF to be citing ATM Forum UNI 4.0; its public release date is unclear, 
  48. with a current February goal for straw vote.  Forum/ITU politics may 
  49. also delay its completion.  Joint statement by the IPATM and ROLC 
  50. chairs
  51.  
  52. Mark Laubach (the IPATM chair) and Andy Malis presented a chair's 
  53. statement regarding ROLC and IPATM coordination of the transition 
  54. from ATMARP to ATMARP + NHRP to NHRP.  A mention was made 
  55. that the IESG has stated that a well-defined step-wise transition plan 
  56. that  emphasizes interoperability with the installed base is required 
  57. for any evolution of a widely deployed proposed standard.  All clients  
  58. must be able to resolve the address of any other client by required  
  59. default behavior (for the given client type) regardless of 
  60. implementation or deployment.  In the following discussion, the ROLC  
  61. Working Group asked that references to NHRP be removed from Mark's 
  62. IP/ATM  Classic2 draft, to allow a separate transition plan to be 
  63. developed.
  64.  
  65.  
  66. NHRP Specification and Open Issues
  67.  
  68. The working group next discussed some NHRP open issues from version-
  69. 06 and the mailing list.
  70.  
  71. 1.  MARS harmonization-Hardware Type field vs. Address Family  
  72. field:  The motivation for each choice was continued from the  mailing 
  73. list discussion.  Good points were made on either side, after which the 
  74. clear working group consensus was to use Address Family to identify the 
  75. NBMA address type.  Grenville Armitage made the corresponding 
  76. change to the MARS specification to allow continued  NHRP and 
  77. MARS harmonization--see draft-ietf-ipatm-ipmc-10.txt.
  78.  
  79. 2.  MARS harmonization-address field coding and parsing:  NHRP was 
  80. zero-filling addresses to 32-bit boundaries, while MARS was not.  The 
  81. chair noted that it would be nice for them to be same, if only  for code 
  82. reuse in your implementations.  After discussing the relative merits, the 
  83. working group agreed to "align" with MARS and not zero-fill addresses 
  84. to 32-bit boundaries.
  85.  
  86. 3.  Destination prefix vs. mask:  The consensus was to go back to the 
  87. prefix rather than the mask.
  88.  
  89. 4.  Using prefixes with purge messages:  The consensus was to allow 
  90. prefixes with purges.
  91.  
  92. 5.  Purge acks:  The working group discussed whether or not purges 
  93. should be  acknowledged.  The consensus was yes.  It is up to each purge 
  94. sender  to decide whether to wait for the ack and whether or not to 
  95. resend  the purge if the ack doesn't come back, but purge receivers must  
  96. always send acks.  There was little consensus one way or the other  for 
  97. adding a bit to the purge specifying whether or not the receiver  should 
  98. send an ack; this should be further discussed on the list.
  99.  
  100. 6.  MTU:  The suggestion was made to use currently unused header space 
  101. for MTU discovery.  There was clear consensus to add this feature, as it 
  102. is consistent with RFC 1626 requirements.
  103.  
  104. 7.  Server redundancy:  This is not addressed in the current spec.  A strict 
  105. reading suggests that if there is more than one NHS in a LIS, then 
  106. NHRP clients must register with all of them.  The working group 
  107. agreed that addressing server redundancy is required before NHRP is 
  108. "ready for prime time".  The working group agreed that it would be a 
  109. reasonable goal  to leverage the IPATM Working Group's 
  110. synchronization method, if possible.  This discussion will be continued 
  111. on the mailing list.
  112.  
  113. 8.  Autoconfiguration:  The issue of how to configure clients and servers 
  114. came up during the redundancy discussion.  There was strong  consensus 
  115. for autoconfiguration capabilities, supported either from network 
  116. management via the NHRP MIB, or via a configuration server.  The 
  117. view was expressed that while ATM anycasts are useful to find  
  118. configuration servers, they should not be used to find NHRP servers,  but 
  119. the working group did not reach consensus on this point.  There was  
  120. discussion of whether to use NBMA-level configuration services when  
  121. available; this led to a liaison to the ATM Forum regarding ROLC's  
  122. interest in using the ATM Forum's LAN Emulation Configuration Server  
  123. (see below).  The point was also made that ATM Forum anycasts cannot 
  124. be used in an IETF document until UNI 4.0 is publicly available.  The 
  125. autoconfiguration discussion will be continued on the list.
  126.  
  127. 9.  [This was actually discussed in the second session, but logically  fits 
  128. in here.]  The question was asked why clients are configured with their 
  129. server's IP address.  The consensus was that this was  just a holdover 
  130. from server mode, and that it should be removed from  the spec.
  131.  
  132.  
  133. SESSION TWO
  134.  
  135.  
  136. Joint ROLC/IPATM Liaison to the ATM Forum
  137.  
  138. The ATM Forum liaison was discussed and amended.  The liaison  
  139. included two sections, one suggesting leveraging the LANE  
  140. configuration server for IETF uses, the second asking for LAN  Emulation 
  141. Configuration Server redundancy.  The liaison was later presented at 
  142. the IPATM Working Group meeting, where it was accepted and  
  143. forwarded to the ATM Forum liaison, Joel Halpern.
  144.  
  145.  
  146. Local/Remote Forwarding Decision
  147.  
  148. Yakov Rehkter presented draft-ietf-rolc-apr-03.txt.  His talk discussed 
  149. issues such as:  Why do we care how the local/remote decision made?  
  150. When can SVCs be used effectively?  When is the overhead of SVC 
  151. setup justified?  Other issues discussed included  connection 
  152. setup/teardown, Quality of Service, and SVC sharing.  He pointed out 
  153. that we should rethink the subnet model, and replace it  with a local 
  154. vs. remote model.  Numerous options then result, significantly larger 
  155. than with the classic LIS model.  If the model is relaxed, can link layer 
  156. connectivity always be reached?  Try to  establish connectivity--if not 
  157. reachable, then fall back to the  routed path.  How should we do 
  158. address assignment in the absence of  the subnet model?  Instead, use the 
  159. notion of "groups."  A group implies assignment of end host and router 
  160. addresses from a single prefix.  Routers in the group advertise routes to 
  161. the prefix.  In discussion, the working group agreed to the term "Local 
  162. Address Group" (LAG)  for this group.  The working group also agreed 
  163. that Yakov will update the draft  based upon the discussion, and there 
  164. will be a subsequent working group last call, followed by submitting the 
  165. draft to be published as an Informational RFC.
  166.  
  167.  
  168. Mobile NHRP Devices
  169.  
  170. Hiroshi Suzuki presented draft-horikawa-mobile-nhrp-00.txt.  He 
  171. began his talk by noting that it is more of a "NHRP Client  
  172. Autoconfiguration" than a "Mobile NHRP" talk, although mobility 
  173. issues were also included.  He stated that autoconfiguration is  required 
  174. to make supporting a large number of clients practical.  He presented 
  175. the client's use of anycast to a "well-known" address to  find any NHRP 
  176. server on the NBMA, not necessarily one in your LIS.  If a server 
  177. receives a registration for a client in a LIS other than  its own, then the 
  178. server forwards the registration to the client's home server along the 
  179. usual routed path (just like forwarding a NHRP  Request).  This 
  180. procedure only works when the client is in the same  NBMA cloud as its 
  181. home LIS.  The working group really liked this registration 
  182. optimization, and agreed to include it in the spec.  To allow secure 
  183. registration, NHRP also needs end-to-end authentication in addition to 
  184. the current hop-by-hop authentication.  The working group agreed that 
  185. in registration packets, encryption would be end-to-end, otherwise hop-
  186. by-hop as before.
  187.  
  188.  
  189. ATMARP/NHRP Translation
  190.  
  191. Rob Coltun presented one viewgraph on his approach to 
  192. ATMARP/NHRP  translation.  His ATMARP and NHRP servers are co-
  193. resident.  If an ATMARP pertaining to the local LIS arrives at the 
  194. server, the ARP code handles it.  If it is beyond the local LIS, the 
  195. ATMARP code translates it into a NHRP request, and forwards it to the 
  196. NHRP code.  The same model is also used for incoming NHRP requests.
  197.  
  198.  
  199. Router-Router NHRP
  200.  
  201. Yakov Rehkter presented his approach to router-router NHRP, based 
  202. upon two messages he sent to the mailing list.  Yakov discussed 
  203. tradeoffs required for cut-through paths, including increased state and 
  204. control traffic, how to determine whether a cut-through path is  still 
  205. valid, how to avoid black holes and routing loops, how to  determine 
  206. when to bring down SVCs, and interactions with BGP and  inter-domain 
  207. routing.  Yakov will be documenting this information in a forthcoming 
  208. draft, which the working group agreed will be the basis for further 
  209. work.
  210.  
  211.  
  212. Status and Work Plan
  213.  
  214. The working group agreed that the charter and work plan need to be 
  215. revised;  this will be done on the list.  The tentative work plan 
  216. discussed in the meeting is:
  217.  
  218. December 1995        Produce version 07 of the NHRPv1 spec, new 
  219. LAG (was APR) draft.
  220.  
  221. January 1996            Final calls on these documents, submit 
  222. to IESG
  223.  
  224. March 1996            Discuss companion documents-NHRPv1 
  225. Applicability Statement, MIB, Protocol Analysis, router-to-router 
  226. (NHRP v2), server-to-server synchronization,transition plan, using 
  227. shortcuts for IP multicasting
  228.  
  229. June 1996            Discuss 
  230. implementation/interoperability issues, finalize NHRPv1 companion 
  231. documents, further discuss NHRPv2.
  232.  
  233. December 1996        Complete NHRPv2.
  234.  
  235.  
  236. The meeting adjourned following this discussion.
  237.  
  238. Later in the week, the ROLC and IPATM chairs met with the Routing 
  239. Area Director (Joel Halpern) and the Internet Area Directors (Susan  
  240. Thomson and Frank Kastenholz) to discuss the transition plan and  
  241. direction of the working groups.  The recommendations to the working 
  242. groups from this meeting are that:
  243.  
  244. The IPATM Classic2 draft should proceed with ATMARP and without 
  245. reference to NHRP, and include ATMARP server synchronization.
  246.  
  247. The IPATM and ROLC working groups should coordinate MIB 
  248. development, explore leveraging the same server synchronization 
  249. methods, and keep in mind that future IAB/IETF directions may require 
  250. authenticated address registration (i.e., this is a heads up, and don't 
  251. preclude a straightforward evolution to this as part of the 
  252. synchronization
  253. work).
  254.  
  255. A future ROLC RFC will be used to specify how to substitute NHRP for 
  256. ATMARP; i.e., IPATM will continue to develop ATMARP in its work at 
  257. this time.
  258.  
  259.