home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rolc / rolc-minutes-96mar.txt < prev   
Text File  |  1996-05-25  |  11KB  |  263 lines
  1. Editor's note:  These minutes have not been edited.
  2.  
  3.  
  4.  
  5. Minutes of the Routing Over Large Clouds (rolc) Working Group
  6.  
  7. Los Angeles IETF, 4 March 1996 1300-1500 and 1530-1730. Reported by
  8. Howard Berkowitz, George Swallow, and Andrew Malis.
  9.  
  10. The rolc WG met in two sessions at this IETF.  There were 142
  11. attendees.
  12.  
  13. Agenda:
  14. * First Session
  15.    1. Agenda Bashing
  16.    2. ATM Forum report and liaison from LANE and MPOA
  17.       (Swallow & Halpern)
  18.    3. NHRP revision 08-beta (Luciani)
  19.       draft-ietf-rolc-nhrp-08-beta (distributed via email)
  20.    4. ATM Forum LAN Emulation Server Synchronization (McCloghrie)
  21.    5. NHRP/ATMARP/MARS Server Cache Synchronization Protocol
  22.       (SCSP) (Luciani)
  23.       draft-luciani-rolc-scsp-01
  24.  
  25. * Second Session
  26.    6. NHRP MIB Status (Luciani and Greene)
  27.    7. NHRP Protocol Applicability Statement (Cansever)
  28.       draft-ietf-rolc-nhrp-appl-02
  29.    8. NHRP for Destinations off the NBMA Subnetwork (Rekhter)
  30.       draft-ietf-rolc-r2r-nhrp-00
  31.    9. Support for Sparse Mode PIM over ATM (Rekhter, Farinacci)
  32.       draft-rekhter-pim-atm-00
  33.    10.Multicast Inscalability over Large Cloud (Ohta)
  34.       draft-ohta-mcast-large-cloud-00
  35.    11.OSPF Cut-through Advertisements (Coltun)
  36.  
  37. First Session:
  38.  
  39. ATM Forum MPOA Report
  40.  
  41. George Swallow, the ATM Forum Multi-Protocol Over ATM (MPOA)
  42. Sub-Working Group chair, reported that The Forum met twice since
  43. Dallas and has concentrated on integrating LAN Emulation (LANE)
  44. into the MPOA architecture.   The IETF's liaison on server
  45. synchronization was well received, and a liaison was sent back to
  46. the IETF.
  47.  
  48. LANE now supports multiple servers, and has a slightly different
  49. problem space than NHRP or ATMARP.  MPOA also is building on NHRP
  50. and MARS.
  51.  
  52. NHRP 08beta Specification
  53. draft-ietf-rolc-nhrp-08-beta
  54.  
  55. Jim Luciani spoke on the NHRP specification.  Version 08 beta
  56. collected several changes, but is not quite ready to be issued as an
  57. Internet Draft.  There are some open issues that Jim wanted to
  58. address.  The major changes from version 07 were wording changes, a
  59. Don't Reply bit was added to the NHRP Purge Request, correcting the
  60. LAG discussion, a NAK code was added to the Resolution Reply, and
  61. two error codes were re-instituted.
  62.  
  63. Open issues & discussion:
  64.  
  65. Should there be an error indication when the hop count is exceeded?
  66. It was agreed that there should be, subject to usual constraints on
  67. not sending an error in response to an error message.  It is
  68. reasonable to send back the error indication because a loop in the
  69. direction of the destination does not imply a loop exists back to
  70. the source.
  71.  
  72. Should NHRP registration replies be routed by NBMA or protocol
  73. address? In other words, in the case where a client is registering,
  74. but is not talking directly to the registration server, should a VC
  75. be opened from the server back to the requester?  The WG agreed that
  76. yes, the response will go at the ATM layer to the NBMA address of
  77. the requester.
  78.  
  79. Should a router client be allowed to allowed to register an
  80. arbitrary station? The current specification implies a client can
  81. register itself or a subnet of which it is a member.  The WG agreed
  82. that for a router to register a subnet behind it without it also
  83. having an address on that subnet, it must be an NHS and serve that
  84. subnet. The text needs to be clarified on this point.
  85.  
  86. The next step is to produce a real version 08 to become an Internet
  87. Draft as soon as possible.  Once there is a server synchronization
  88. draft to reference in the NHRP spec, it will be possible to have a
  89. WG last call in order to send the specification to the IESG.  At
  90. this point, no other changes (other than bug fixes and
  91. clarifications) are expected in the draft.
  92.  
  93. Server Synchronization
  94.  
  95. Both the ipatm and rolc WGs have been working on multiple server
  96. synchronization.  Both WGs realize that if a technology requires a
  97. server, one server alone is not enough for robustness, load
  98. leveling, etc.  ATMARP will eventually transition to NHRP, so the
  99. two groups are cooperating to ensure the same synchronization
  100. mechanism is used for NHRP, ATMARP, and MARS servers, and
  101. potentially other address resolution servers as well.  The
  102. synchronization mechanism must not be specific to NHRP.
  103.  
  104. The Classic2 ipatm specification includes a service synchronization
  105. protocol, which is similar to SCSP but has different implementation
  106. characteristics.  It has been agreed that the server synchronization
  107. part of Classic2 will become a separate document.  This allows
  108. reference by ipatm and rolc as needed to the new mechanism.  The
  109. SCSP and Classic2 authors are collaborating to produce a single
  110. specification.
  111.  
  112. Presentation on LANE Server Synchronization (Keith McCloghrie)
  113.  
  114. Keith McCloghrie presented this to inform the rolc WG on LAN
  115. Emulation's server synchronization protocol.
  116.  
  117. LANE 1.0 specifies the LAN Emulation Client (LEC) to Server (LES)
  118. interface.  LANE 2.0 involves server-to-server protocols as well.
  119.  
  120. Because of LAN Emulation's topology requirements -- full mesh is
  121. useful in small systems, but tree of point-to-point links scales
  122. better -- the LANE servers use a combination called a "peer-tree."
  123. In a peer tree, each node either is a complex node (of multiple LES)
  124. or is a single LES. A pure tree has no complex nodes and no
  125. redundant links; a pure mesh has a single complex node.  Spanning
  126. tree is used to produce a loop-free tree.  Each node in the tree has
  127. all information for itself and the nodes below it, therefore, the
  128. root and only the root has full information.
  129.  
  130. New registrations are sent toward the tree's root, with intermediate
  131. nodes rejecting if they find a conflict.  Only the root responds
  132. with success.  Tradeoffs are possible; an optimistic LES assumes
  133. registration will succeed, but will revoke registration of the LEC
  134. if an error is detected.
  135.  
  136. Resolution requests are sent toward the root.  If the answer is "not
  137. registered", then the root floods.  Pessimistic LES enhancement
  138. assumes failure and floods at each node.
  139.  
  140. Issues remain -- a caching mechanism is needed, with appropriate
  141. purging mechanisms that do not cause momentary losses of
  142. connectivity.  Another issue involves healing after partition
  143. repair.  Conflicts then need to be resolved.
  144.  
  145. The LANE scaling goal is 20+ servers, 2000+ clients.  The LANE group
  146. thinks it can scale beyond that.
  147.  
  148. Server Cache Synchronization Protocol (SCSP)
  149. draft-ietf-rolc-sscp-01
  150.  
  151. Jim Luciani presented his Server Cache Synchronization Protocol
  152. (SCSP)  draft.  It is largely based on OSPF, principally to avoid
  153. reinventing the wheel and use well-known reasonable-overhead
  154. mechanisms.
  155.  
  156. A Server Group (SG) is a set of synchronized servers bound to a SG
  157. through some commonality (e.g., membership in a LIS or LAG).
  158.  
  159. All statements about SCSP are made from the perspective of the
  160. protocol stack in the Local Server (LS).  Directly Connected Servers
  161. (DCSs) are one hop away (e.g., through a VC).  A Remote Server (RS)
  162. is neither a LS or DCS but is still part of the SG.
  163.  
  164. Three basic messages are defined, a Hello, a Client State Update and
  165. a Cache Alignment.
  166.  
  167. Each server has separate state machines for Hello and Cache
  168. Alignment.  The exact mechanism for the necessary preconfiguration
  169. of the LS (i.e., who are the DCSs) is implementation specific.
  170.  
  171. All servers within SG need to be synchronized, but these servers
  172. emphatically do not keep synchronized with other SGs.  Registration
  173. within a SG is replicated to all other servers in the SG.  Early
  174. simulation results suggests performance requirement is modest,
  175. considering there is no need for such resource intensive things as a
  176. Dijkstra calculation.
  177.  
  178. Open Issues:
  179. Should cache alignment messages contain data base or summary?
  180. Currently, they contain summaries.
  181. How should counters be wrapped?  The WG favored a normal round
  182. sequence space.
  183. Should a bit to be added to hello messages to allow point-to-
  184. multipoint?  The WG felt it was not warranted.
  185.  
  186. The concept of a designated server has been removed from the
  187. specification.
  188.  
  189. Second Session:
  190.  
  191. NHRP MIB
  192.  
  193. Maria Greene and Jim Luciani received from the MIB from Avri Doria,
  194. the previous editor.  It is based in part on the Classical IP MIB,
  195. which will aid the modeling of co-resident ATMARP and NHRP
  196. environments.  Input is welcome.  The current plan is to submit it
  197. to next IETF meeting in June.
  198.  
  199. NHRP Protocol Applicability Statement
  200.  
  201. Derya Cansever submitted the current draft several weeks ago and
  202. received some comments.  It will be updated as appropriate.  He asked
  203. for additional questions or comments - there were none.
  204.  
  205. NHRP for Destinations off the NBMA Network
  206.  
  207. Yakov Rekhter issued a new draft with some text to deal with not
  208. replying when routing is in a transient state.
  209.  
  210. Support for Sparse Mode PIM over ATM
  211.  
  212. Yakov presented a mechanism to eliminate extra layer three hops
  213. across an ATM network for multicast traffic.  This technique is
  214. applicable to both Sparse Mode Protocol Independent Multicasting
  215. (PIM) and Core Based Trees (CBT).
  216.  
  217. The primary focus is on supporting sparsely populated multicast
  218. groups, especially for flows that have sufficiently high volume or
  219. QoS requirements.
  220.  
  221. Yakov also discussed the relationship between multicast shortcuts
  222. and RSVP, and concluded that they are orthogonal issues, and a
  223. shortcut mechanism should not be a part of RSVP.
  224.  
  225. Multicast Inscalability over Large Clouds
  226.  
  227. Masataka Ohta discussed the inscalability of multicast over large
  228. clouds.
  229.  
  230. His assumption is that a "large cloud" is too large for centralized
  231. servers to handle all hosts.  He discussed how message rates and
  232. number of peer relationships are both issues.
  233.  
  234. His proposal is to make the link layer entities able to recognize IP
  235. protocols, so that servers are not necessary.
  236.  
  237. OSPF Cut-Through
  238.  
  239. Rob Coltun presented work in progress, with an Internet Draft
  240. forthcoming.
  241.  
  242. He discussed a mechanism for using information in OSPF to eliminate
  243. some hops for  NHRP requests.  It is not intended to replace NHRP,
  244. but is rather an optimization.
  245.  
  246. His goals are to decrease set-up (address resolution) time,
  247. facilitate router-to-router NHRP, and increase IP routing's
  248. visibility of the NBMA overlay
  249.  
  250. Rob's proposal is to add the ability for routers (Next Hop Servers)
  251. to advertise, in OSPF, their NBMA subnet layer address.  This
  252. advertisement associates, with the NBMA address, the LIS, the area
  253. border, and the AS boundary router.  This information is used to
  254. establish direct VCs to NHSes to short cut the NHRP query, rather
  255. than requiring the query to follow the routed path.
  256.  
  257. Following Rob's talk, the WG adjourned.
  258.  
  259. End of Minutes
  260. __________________________________________________________________________
  261. Andrew G. Malis   Ascom Nexion                      voice: +1 508 266-4522
  262. malis@nexen.com   289 Great Rd., Acton MA 01720 USA   FAX: +1 508 266-2300
  263.