home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ipv6mib / ipv6mib-minutes-95apr.txt < prev   
Text File  |  1995-05-26  |  11KB  |  314 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by David Arneson/Cabletron and Manu Kaycee/Ascom Nexion
  5.  
  6. Minutes of the IPv6 MIB Working Group (IPV6MIB)
  7.  
  8.  
  9. Overview
  10.  
  11. The IPv6MIB Working Group met in two sessions on Monday, 3 April, and
  12. Thursday, 6 April.
  13.  
  14. After the customary agenda bashing and introductions, proceeds from the
  15. IP6MIB BOF were reviewed, which was then followed by a review of the
  16. working group charter.  A general overview of the required effort,
  17. technical highlights, and proposed work items was presented and
  18. discussed.  To which end, it was deemed that no changes would be
  19. required to the standards-track SNMPv2 documents, and additional Textual
  20. Convention(s) and Transport Mappings would be specified in other RFCs.
  21. Textual Conventions, Transport Mappings, and organization of existing
  22. MIBs were discussed, with no definitive result or outcome.  The working
  23. group agreed to conduct follow on discussion on the mailing list.  The
  24. incoming Area Directors for the Internet and Network Management Areas
  25. and the working group agreed to (re)explore appropriate areas where
  26. IPv6-related management oriented work may be conducted.
  27.  
  28.  
  29. Agenda
  30.  
  31.    o Agenda Bashing
  32.    o Introductions
  33.    o San Jose BOF Review
  34.    o Working Group Charter Review
  35.    o General Overview and Technical Highlights
  36.    o Work Done to Date
  37.    o Open Discussion
  38.    o Administravia
  39.    o Framework Overview
  40.    o SNMPv1/SNMPv2:  Impact and Issues
  41.    o Existing MIBs:  Impact and Issues
  42.    o IPv6 MIBs:  Proposed Organization
  43.    o Open Discussion
  44.    o Next Steps
  45.  
  46.  
  47. Introductions
  48.  
  49. Fred Baker has been assigned as the Network Management Area Directorate
  50. Consultant.  In this capacity, Fred will provide expert consultation in
  51. the development of relative MIBs and their respective organizations.
  52. David Arneson has agreed to serve as editor of documents that will be
  53. developed as part of the current working group charter.
  54.  
  55.  
  56. San Jose BOF Review -- Manu Kaycee
  57.  
  58.  
  59. A BOF was held at the previous IETF meeting in San Jose.  In order to
  60. understand how to best proceed with the development of IPv6-related
  61. MIBs, a number of items were discussed and explored, including:
  62.  
  63.  
  64.    o IPv6 Managed Subsystems:  various parts of IPv6 Protocol Suite
  65.    o Management Support Entities:  management protocol extensions
  66.    o Various relationships between IPv4, IPv6, and Applications
  67.    o Affected MIBs
  68.    o Proposed organization of MIBs and next steps
  69.  
  70.  
  71. The general result and opinion of the BOF was to request the formation
  72. of a working group to conduct the additional work.
  73.  
  74.  
  75. Working Group Charter Review -- Manu Kaycee
  76.  
  77.  
  78. In order to solicit comments and ensure general agreement, the charter
  79. was briefly reviewed.  The three broad categories, Management Protocol
  80. Support, Existing MIBs, and IPv6 MIBs, were discussed.  There was
  81. general agreement on the scope of work, which includes:
  82.  
  83.  
  84.    o Identify changes and extensions, if applicable, to existing
  85.      standards-track SNMPv2 RFCs.
  86.  
  87.    o Identify existing MIBs that will be affected, identify new MIBs
  88.      required, and develop a proposed organization.
  89.  
  90.    o liaison with working groups such as IPNGWG and NGTRANS.
  91.  
  92.  
  93. The current charter calls for this working group to identify existing
  94. MIBs that will be affected, and promote additional work on such MIBs to
  95. be conducted in the working groups that originally developed them.
  96. Deirdre Kostick, the incoming Network Management Area Director,
  97. indicated that most of these working groups were planning to shut down.
  98. To which end, she suggested that she, as Network Management Area
  99. Director, the Internet Area Directors, and the chair of this working
  100. group decide on how best to proceed.
  101.  
  102.  
  103. General Overview and Technical Highlights -- Dave Arneson
  104.  
  105.  
  106. This presentation includes specifics on:
  107.  
  108.    o SNMP Impact
  109.    o SNMPv2 Status
  110.    o Technical Direction
  111.    o Changes to Existing MIBs
  112.    o New MIBs
  113.    o Current Work
  114.  
  115. SNMP impact is dictated by performing all work in SNMPv2 SMI. This will
  116. allow for better MIB structures to better exploit IPv4 versus IPv6
  117. issues, and a conversion to SNMPv1 is provided.  Furthermore, a new RFC
  118. will be developed in order to specify an IPv6 Transport Domain.
  119.  
  120. Fred Baker asked whether we should investigate using a new Port number
  121. for SNMP running over UDP/IPv6 networks.  This was in relation to being
  122. able to simplify the Transport Mapping.  Marshall Rose indicated that
  123. there was a `parallel' to using the same Port number, with the existing
  124. mapping for CLNS and CONS. The group agreed to further discuss, if
  125. necessary, on the mailing list.
  126.  
  127. In terms of current SNMPv2 status, a Textual Convention for the IPv6
  128. address, and the corresponding Transport Address and Domain have been
  129. defined.  But, we are waiting on references to IPv6 Protocol and
  130. Addressing RFCs.
  131.  
  132. Fred Baker indicated that the current Textual Convention does not
  133. satisfactorily address unnumbered interfaces, and suggested that the
  134. working group look at including unnumbered interfaces within the Textual
  135. Convention for the IPv6 address.  This would ease traversal of MIBs,
  136. especially tables.  Fred indicated that he would present a Textual
  137. Convention format during the second session.
  138.  
  139. Dave's proposed technical direction is to develop and Informational RFC
  140. specifying:
  141.  
  142.    o Network Address (ifIndex for unnumbered interfaces) Textual
  143.      Convention
  144.    o Suggested methods for individual handling of IPv4 and IPv6 objects
  145.    o Suggested methods for joint handling of IPv4/IPv6 objects
  146.    o Convert relevant groups (MIB modules) of MIB-II
  147.  
  148.  
  149. The MIBs that need change, as presented in a fairly concise list, are:
  150.  
  151.    o DNS MIB
  152.    o FIB
  153.    o OSPF, RIP, and BGP/IDRP MIBs
  154.  
  155.  
  156. The areas that need to be addressed, at least for IPv6, are:
  157.  
  158.    o Address Resolution
  159.    o Neighbor Discovery
  160.    o Tunneling
  161.    o Mobility
  162.    o Qualily of Service
  163.    o Security
  164.  
  165.  
  166. It was indicated, and noted, that commonality exists between quality of
  167. service, as indicated here, and work occurring in the Integrated
  168. Services Working Group (INTSERV). The chair agreed to pursue this.
  169.  
  170.  
  171. Work Done to Date
  172.  
  173. Since IPv6 implementations are underway, the chair queried the working
  174. group to see whether any such implementations had corresponding
  175. management instrumentation.  There were no affirmative answers.
  176.  
  177.  
  178. Open Discussion
  179.  
  180. Three issues were raised as follows:
  181.  
  182.  
  183.    o MIB-II Evolution
  184.    o Split Objects (e.g.  UDP over IPv4 and/or UDP over IPv6)
  185.    o Changes to SMI for IPv6 Address
  186.  
  187.  
  188. The MIB-II evolution and Split Objects' issues centered around the
  189. `what' and `where.'  The what centers around the organization of
  190. objects.  For example, one school of thought suggests that separate
  191. parallel objects be devised for IPv6.  Another school of thought
  192. suggested that existing IPv4-specific objects (e.g.  counters) be
  193. semantically modified to count IPv4 and IPv6 packets/octets, and have a
  194. separate counter for corresponding IPv6 packets/octets.  The latter, of
  195. course, would force us to deprecate existing objects.  No clear
  196. consensus was reached during this session, with the thought that we
  197. would further address this issue during the second working group
  198. session.
  199.  
  200. The chair indicated that he was approached by an individual who wanted
  201. to re-discuss extending the SNMPv2 SMI to support the IPv6 address, and
  202. make a presentation to that end during the second session.  Jeff Case
  203. asked for clarification on the extent of said changes/extensions.  The
  204. extent of such changes/extensions were to the extent discussed during
  205. the San Jose BOF.
  206.  
  207.  
  208. Administravia and Framework Overview
  209.  
  210. At the start of the second session, the chair provided the following as
  211. updates:
  212.  
  213.  
  214.    o Bob Hinden provided two IPng references required by us:  IPng
  215.      Protocol and Addressing Architecture Specifications.
  216.  
  217.    o Based on an off-line discussion with the chair, where pros and cons
  218.      of SNMPv2 SMI extensions were discussed, the individual intent on
  219.      proposing such changes agreed to withdraw said suggestions.  To
  220.      which end, we have complete consensus on the use of a Textual
  221.      Convention for IPv6 address representation.
  222.  
  223.  
  224. The following were presented as points for discussion:
  225.  
  226.  
  227.    o Management Environment consists of:
  228.  
  229.       -  IPv4 Manager/Agent and IPv4/IPv6 Managed Device(s)
  230.       -  IPv6 Manager/Agent and IPv4/IPv6 Managed Device(s)
  231.       -  IPv6 Manager/Agent and IPv6 Managed Device(s)
  232.  
  233.  
  234.    o No proposed changes to SNMPv2 SMI -- use Textual Conventions for
  235.      IPv6 Addresses.
  236.  
  237.    o No additional SNMP Protocol support (`extensions') are needed to
  238.      manage IPv6 via IPv4 Managers.
  239.  
  240.    o Since no changes to the SNMPv2 base documents have been noted, this
  241.      working group let those documents evolve along the standards track,
  242.      as proposed by the SNMPv2 Working Group.
  243.  
  244.    o Decouple IPv6 Address and Transport Mappings specification by
  245.      developing a separate RFC.
  246.  
  247.  
  248. All of the points were accepted.
  249.  
  250.  
  251. SNMPv1/SNMPv2:  Impact and Issues
  252.  
  253. Fred Baker presented a modified Textual Convention as follows:
  254.  
  255.  
  256.      Octet 1 is Type:
  257.  
  258.          1 - IPv6 Address
  259.          2 - interface number in network order
  260.  
  261.      With the remaining octets being the actual value of the Address of
  262.      Interface number.
  263.  
  264.  
  265. David Arneson suggest that this be modified to include explicit support
  266. for other Network Type Addresses (e.g., IPX, NSAPs) as follows:
  267.  
  268.          1 - IPv6 Address
  269.          2 - interface number in network order
  270.          3 - future use
  271.  
  272.      With the remaining octets being the actual value of the Address of
  273.      Interface number.  This can be extended to include other Network
  274.      Addresses and Host Addresses.
  275.  
  276.  
  277. Fred Baker indicated the problem we might have with variable sized
  278. addresses in this encoding scheme.  He took an action item to contact
  279. the appropriate individuals to discuss the same, with additional
  280. discussion being conducted on the mailing list.
  281.  
  282.  
  283.  
  284. IPv6 MIBs:  Proposed Organization
  285.  
  286. Discussion continued on object usage and the definition of new objects.
  287. Should existing objects continue to reflect IPv4 only or should they be
  288. an aggregate?  After some discussion it was decided that both IPv4 and
  289. IPv6 counters are needed.  It was also suggested that we review
  290. enterprise specific work done for ST-II, and use it as a precedent.  The
  291. working group decided to follow though with ST-II and conduct additional
  292. discussions on the mailing list.
  293.  
  294. Two other presentations were not made due to scheduling and availability
  295. conflicts.  The chair has requested said individuals to discuss their
  296. proposal on the mailing list.
  297.  
  298.  
  299.  
  300. Next Steps
  301.  
  302. Since discussions on Textual Conventions, Transport Mappings, and
  303. organization of existing MIBs did not yield definitive results or
  304. outcome, the working group agreed to conduct follow-on discussion on the
  305. mailing list.
  306.  
  307. Since many working groups, that might normally have worked on updates to
  308. existing MIBs, have either wrapped up or intend to wind down shortly,
  309. administrative issues need to be reviewed.  The incoming Area Directors
  310. for the Internet and Network Management Areas and the working group
  311. agreed to (re)explore appropriate areas where IPv6-related management
  312. oriented work may be conducted.
  313.  
  314.