home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 93mar / frnetmib-minutes-93mar.txt < prev    next >
Text File  |  1993-05-10  |  8KB  |  199 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5.  
  6. Reported by Deirdre Kostick/Bellcore
  7.  
  8. Minutes of the Frame Relay Service MIB BOF (FRNETMIB)
  9.  
  10. The purpose of the Frame Relay Service MIB BOF was to determine if there
  11. was interest in writing a standard Frame Relay Network MIB and to
  12. determine if the MIB should be developed in the IETF.
  13.  
  14. Tracy Cox presented the purpose of the BOF, the proposed scope of the
  15. MIB, and discussed the relation to the Frame Relay Forum Technical
  16. Committee activities.  The proposed MIB has the following
  17. scope/features:
  18.  
  19.  
  20.    o The MIB will be an SNMPv1 MIB.
  21.  
  22.    o It will contain read-only objects.
  23.  
  24.    o It is intended for use by end-customers (versus service providers)
  25.      to manage their portion of a Frame Relay network.
  26.  
  27.    o It is intended to support fault detection, performance monitoring,
  28.      and configuration for Frame Relay interfaces.
  29.  
  30.    o It is NOT intended to be a switch MIB, and will NOT include managed
  31.      objects for switching elements and related internal aspects of the
  32.      network supporting Frame Relay.
  33.  
  34.  
  35. Tracy discussed the relation with the existing Frame Relay DTE MIB
  36. (RFC1315).  Based on discussion with RFC1315 authors and others, Tracy
  37. determined that the Frame Relay DTE MIB was not sufficient to manage the
  38. Frame Relay interface from the network perspective.  For example, a
  39. Frame Relay Network MIB would need bi-directional information on Frame
  40. Relay parameters (CIR, Be, Bc), and an end-to-end view of the network,
  41. neither of which are supported in RFC1315.
  42.  
  43. The Frame Relay Network MIB would not include managed objects for the
  44. physical layer.  Existing physical layer MIBs (e.g., DS1 and DS3) would
  45. be used.
  46.  
  47. There was agreement with the scope of the MIB. The BOF attendees also
  48. agreed that:  a) there was interest in writing a standard MIB, and b)
  49. that the IETF was the appropriate body for the development of standard
  50. MIBs.
  51.  
  52. There was discussion on the relationship of the efforts in the Frame
  53. Relay Forum and the proposed ATMMIB Working Group.  These issues were
  54. discussed at length during George Mouradian's presentation.
  55.  
  56.                                    1
  57.  
  58.  
  59.  
  60.  
  61.  
  62. George presented ideas on service management -- Architecture Principles
  63. for Service MIBs.  George indicated that standards for service
  64. management are necessary, and that Frame Relay and ATM services are good
  65. candidates for standardized MIBs.  Both the user and the vendor
  66. communities benefit.  George raised questions and issues related to the
  67. proliferation of MIBs and of different groups working on the same
  68. management issues.
  69.  
  70. George indicated that he felt it was premature to start a separate
  71. effort in the IETF and that it was necessary to give the Frame Relay
  72. Forum more time to complete their efforts.  There was lively discussion
  73. on this topic.  Caralyn Brown indicated that the intent was not to
  74. discontinue the work in the Frame Relay Forum, rather it was to follow
  75. the process used for development of RFC1294.  Andy Malis indicated that
  76. for RFC1294 the work in the IETF was brought into the Frame Relay Forum,
  77. and that there were ongoing efforts to keep the Frame Relay Forum
  78. informed of the IETF work and to gain their input and consensus.  Both
  79. Caralyn Brown and Andy Malis were involved in this coordination effort.
  80.  
  81. Ken Rodemann indicated that he agreed that it was unwise to assume that
  82. the IETF would ``rubber-stamp'' a MIB brought in from an outside group.
  83. However, he felt that it would be wiser to let the work continue in the
  84. Frame Relay Forum before bringing it into the IETF.
  85.  
  86. Doug Kay supported continuing the work in the Frame Relay Forum since
  87. there was expertise on Frame Relay; however, Doug also indicated that he
  88. felt that the IETF offered the network management and SNMP-related
  89. expertise that would be necessary to develop a quality MIB. Doug
  90. indicated that he would feel comfortable if it was clear that the Frame
  91. Relay Forum was responsible for defining the Managed Objects and that
  92. the IETF Group would be responsible for ``mibification''.
  93.  
  94. There was discussion on the timing of the establishment of the proposed
  95. Working Group and the process for coordination with the Frame Relay
  96. Forum work.  Deirdre Kostick suggested that the Forum continue to work
  97. on the proposed list of managed objects via email and at their June
  98. meeting, develop a consensus on the set of objects.  This set of objects
  99. would be used by the proposed IETF Working Group to begin MIB definition
  100. at the July IETF meeting.  James Watt suggested that an interim meeting
  101. should be held in conjunction with the June Frame Relay Forum meeting.
  102.  
  103. Results of the BOF
  104.  
  105.  
  106.    o There is interest in writing a Frame Relay Network Service MIB. The
  107.      scope of the MIB is consistent with the scope identified during
  108.      Tracy Cox's presentation.  That is, the MIB will be an SNMPv1 MIB
  109.      intended to support end-customer network management for their Frame
  110.      Relay interfaces.  It is not intended to be a switching system MIB.
  111.  
  112.    o There is agreement that a working group should be created to
  113.      develop the Frame Relay Network Service MIB.
  114.  
  115.  
  116.                                    2
  117.  
  118.  
  119.  
  120.  
  121.  
  122.    o The first meeting (assuming approval of the Working Group by the
  123.      yet-to-be-named Network Management Area Director) will be June
  124.      28-30 with the Frame Relay Forum Technical Committee in Chicago.
  125.      Meeting logistics will be posted on the mailing list.
  126.  
  127.    o The Frame Relay Network Service MIB will be based on the managed
  128.      objects identified by the Frame Relay Forum Technical Committee.
  129.      There will be ongoing coordination efforts between the two groups.
  130.  
  131.    o The proposed schedule for deliverables from the Working Group are
  132.      indicated below in the proposed Charter.
  133.  
  134.    o There will be coordination with the proposed ATMMIB Working Group
  135.      to insure that common elements are consistently modeled.
  136.  
  137.  
  138. Proposed Charter of Working Group
  139.  
  140.  
  141.    o Tracy Cox will Chair the Group.
  142.  
  143.    o Messages for Group discussion can be sent to
  144.      frftc@nsco.network.com.  Subscription requests for the discussion
  145.      list should be sent to frftc-request@nsco.network.com.
  146.  
  147.    o To write a standard Frame Relay Network Service MIB based on the
  148.      set of managed objects identified by the Frame Relay Forum
  149.      Technical Committee.  Close coordination with the Frame Relay Forum
  150.      is essential.  Once chartered, this Working Group will also
  151.      coordinate their efforts with the proposed ATMMIB Working Group.
  152.  
  153.    o The goals of the Group are to complete the first draft of an
  154.      Internet-Draft by July of 1993 and to submit the final draft of the
  155.      document for approval as an RFC by November of 1993.
  156.  
  157.  
  158. Attendees
  159.  
  160. Masuma Ahmed             mxa@sabre.bellcore.com
  161. Rich Bowen               rkb@ralvm11.vnet.ibm.com
  162. Caralyn Brown            cbrown@wellfleet.com
  163. Theodore Brunner         tob@thumper.bellcore.com
  164. John Chang               changj@ralvm6.vnet.ibm.com
  165. Anthony Chow             chow_a@wwtc.timeplex.com
  166. Tracy Cox                tacox@sabre.bellcore.com
  167. Manuel Diaz              diaz@davidsys.com
  168. Ken Hayward              Ken.Hayward@bnr.ca
  169. Don Hofacker             hofacker@dtedi.hq.aelc.af.mil
  170. Doug Kay                 doub.kay@sprintintl.sprint.com
  171. Kenneth Key              key@cs.utk.edu
  172. Zbigniew Kielczewski     zbig@eicon.qc.ca
  173.  
  174.                                    3
  175.  
  176.  
  177.  
  178.  
  179.  
  180. Moshe Kochinski          moshek@FibHaifa.com
  181. Deirdre Kostick          dck2@sabre.bellcore.com
  182. Patrick Leung            patrickl@eicon.qc.ca
  183. Andrew Malis             malis_a@timeplex.com
  184. Matthew Morrisey         morrisey@wpsp01.hq.aflc.af.mil
  185. George Mouradian         gvm@arch3.att.com
  186. Rina Nathaniel           rina!rnd!rndi@uunet.uu.net
  187. Louise Reingold          l.reingold@sprint.sprint.com
  188. Bradley Rhoades          bdrhoades@mail.mmmg.com
  189. Kenneth Rodemann         krr@qsun.att.com
  190. Dan Romascanu            dan@lannet.com
  191. Marshall Rose            mrose@dbc.mtview.ca.us
  192. Kaj Tesink               kaj@cc.bellcore.com
  193. James Watt               james@newbridge.com
  194. Kiho Yum                 kxy@nsd.3com.com
  195.  
  196.  
  197.  
  198.                                    4
  199.