home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ptopomib / ptopomib-minutes-97apr.txt < prev    next >
Text File  |  1997-05-29  |  9KB  |  237 lines
  1. Editor's Note:  These minutes have not been edited.
  2.  
  3.  
  4. Meeting Minutes -- 38th IETF; Memphis, TN
  5. Reported by Ken Jones
  6. Area:  Operational and Management Requirements
  7. Working Group:  ptopomib
  8. Date:  April 9, 1997
  9.  
  10. WG Chair:
  11.     Ken Jones          <kjones@baynetworks.com>
  12. Area Advisor:
  13.     Andy Bierman       <abierman@cisco.com>
  14. -------------------------
  15.  
  16. Summary
  17. =======
  18.  
  19. The Ptopo WG met on Wednesday, april 9th from 1:00 to 3:15.
  20. 55 people attended the session.
  21.  
  22.  
  23.  
  24. Reading Material
  25. ================
  26.  
  27. ID-1: Network Element Object MIB (Neo-MIB)
  28. draft-tackabury-neo-mib-00.txt
  29.  
  30. ID-2: Physical Topology Framework
  31. draft-kjones-ptopo-framework-00.txt
  32.  
  33. ID-3: Physical Topology MIB and Discovery Protocol
  34. draft-bierman-ptopo-MIB-proto-00.txt
  35.  
  36. ID-4: Physical Topology Terminology
  37. draft-malachi-topology-terms-00.txt
  38.  
  39.  
  40. Agenda Review - Jones
  41. =====================
  42.  
  43. Ken Jones presented the agenda, which was accepted with
  44. some changes in the order of presentatons. The proposed agenda
  45. called for reviewing the 4 IDs, and then to spend
  46. the rest of the time discussing key issues, with a goal of
  47. reaching consensus within the group if possible, and deferring
  48. contentious issues to the mailing list.
  49.  
  50. The following was the final agenda:
  51.  
  52. o Agenda Review
  53. o Review IDs
  54.     o Framework - Ken Jones
  55.     o Neo-MIB - Wayne Tackabury
  56.     o MIB and Discovery Protocol - Andy Bierman
  57.     o Terminology - (not reviewed due to author not present)
  58. o Issues Review (list of issues provided below)
  59. o Discussion on need for Interim meeting
  60.  
  61.  
  62. Physical Topology Framework (ID-2) - Jones
  63. ==========================================
  64.  
  65. Ken Jones reviewed the framework document.  A copy of the
  66. ID and the presentation can be found in the ptopo
  67. archives (ftp.3com.com). Key points and issues raised include 
  68. the following:
  69.  
  70.     o the definition of physical topology is the external 
  71. interconnection of physical ports.  Can be 1:1 or 1:n.  It
  72. is a linear relationship - there is no concept of hierarchy
  73. required.
  74.  
  75.     o the common MIB should be independent of the topology
  76. mechanism(s) used and should represent the agent's local view
  77. of the physical topology.  That view may be incomplete and/or
  78. redundant.  The MIB should also contain information about
  79. other agents that have been discovered by this agent.  These
  80. other agents may contain physical topology data.
  81.  
  82.     o Security - there is an issue that agent discovery and
  83. physical topology information may be a security concern in some
  84. environments.
  85.  
  86.     o Use of datalink information to determine physical topology.
  87. The framework document describes a method of determining physical
  88. topology based on detecting which MAC addresses have been seen on
  89. which ports.  There was a question about whether this datalink 
  90. information should be used to understand physical topology.  It was
  91. pointed out that datalink info is a good way to identify leaf devices
  92. without requiring them to implement an active topology mechanism or
  93. the PTOPO MIB.
  94.  
  95.  
  96. Network Element Object MIB (ID-1) - Tackabury
  97. =============================================
  98.  
  99. Wayne Tackabury reviewed the Neo-MIB document.  A copy of his
  100. presentation and the ID can be found in the PTOPO
  101. archive (ftp.3com.com).  Key points and issues raised include the
  102. following:
  103.  
  104.     o this MIB supports both the local topology agent and the
  105. topology server agent.  It is also extensible to layers above
  106. physical topology.  Wayne presented an example of how vlan
  107. topology would be represented in the MIB
  108.  
  109.     o it was suggested that the identifier used to indicate
  110. the topology mechanism used to collect the data be included in
  111. the index.  This would allow a management application to readily 
  112. retrieve all topology information obtained through a particular
  113. mechanism.
  114.  
  115.  
  116. Physical Topology MIB and Discovery Protocol (ID-3) - Bierman
  117. =============================================================
  118.  
  119. Andy Bierman reviewed the MIB and discovery protocol document.  A copy
  120. of his presentation and the ID can be found in the PTOPO archive
  121. (ftp.3com.com). Key points and issues raised include the following:
  122.  
  123.     o the entity MIB would be extended to support a read-only chassis
  124. ID and port IDs.  These IDs would be persistent across power cycles.
  125.  
  126.     o the MIB contains both physical connectivity information and
  127. agent identification information, as described in the framework
  128. document.  the MIB provides local topology - it is not a topology
  129. server.
  130.  
  131.     o The MIB does not allow for representation of partial topology
  132. information (e.g. if remote port is not known), or for ambiguous
  133. information (e.g. several devices are known to exist downstream
  134. from a port, but the actual physical connections are not known (also
  135. known as a cloud).
  136.  
  137.     o There was a question as to whether the device ID would be 
  138. universally required to be supplied by all topology mechanisms.
  139.  
  140.     o there is a 128-byte limit on the size of an index, so we need
  141. to be careful how many strings we use as indices.
  142.  
  143.     o the PTOPO Discovery Protocol is proposed as an example
  144. mechanism that could be used to populate the PTOPO MIB.  The
  145. mechanism proposed would be for store and forward devices since
  146. the discovery packets should not be forwarded by a device and
  147. must be sent on all ports, including spanning-tree-blocked ports.
  148.  
  149.     o it was pointed out that the PTOPO agent is different than
  150. the topology mechanism "application" and we should be careful
  151. not to confuse the two.
  152.  
  153.  
  154. Issues Discussion - Jones
  155. =========================
  156.  
  157. Ken Jones led a discussion on a number of issues.  Two major
  158. issues were discussed and consensus was reached.  The other
  159. issues will be discussed on the mailing list.  The list of issues
  160. can be found in the presentations directory in the PTOPO archives.
  161.  
  162. Local Topology vs Topology Server
  163.  
  164. The issue is whether the WG should focus just on local topology
  165. for now or whether it should include a topology server.  The MIB
  166. requirements for both could be very similar, although the topology
  167. server could have additional requirements.  A proposal was made
  168. to focus on local topology for now and either work on the topology
  169. server as a future WG effort or possibly move it to DISMAN or some
  170. other WG.  Topology issues such as connections to local printers
  171. through a printer port would also not be part of local topology
  172. MIB.  A straw vote was taken on this issue and the group
  173. felt strongly that it should focus on local topology for now.
  174.  
  175.  
  176. Do we need to specify topology mechanisms
  177.  
  178. The group felt very strongly that we need to specify one or more
  179. mechanisms in order to provide enough information to allow
  180. interoperable implementations.  It was agreed that we can't limit
  181. the MIB or the implementations to a single mechanism - we must allow
  182. use of existing mechanisms, both standard and proprietary.  We
  183. must allow the overlapping use of different mechanisms.  Data in the
  184. MIB should be identified with the topology mechanism used to discover
  185. that data.
  186.  
  187.  
  188. There were several other issues that we did not have time to cover.
  189. The following is a brief summary of these issues:
  190.  
  191.     o entity MIB extensions - are these satisfactory and are there
  192. issues with requiring implementation of portions of the entity MIB.
  193.  
  194.     o agent identification - is this through a t-address?
  195.  
  196.     o device identification - should this be more flexible.for example
  197. should it be read/write.
  198.  
  199.     o should the MIB include end-station (leaf) topology information.
  200. The response from San Jose was a strong yes.
  201.  
  202.     o how does the MIB accomodate redundant or ambiguous information -
  203. e.g. multiple agents detected on a port, and multiple device IDs
  204. detected on a port.
  205.  
  206.     o Should there be a separate table for connection info and agent id?
  207.  
  208.     o how useful are time filters for topology.  The RMON group has
  209. positive feedback on their usefulness.
  210.  
  211.     o topology corner cases - non-PTOPO devices, multiple agents in 
  212. a chassis, multiple links between devices, rings, busses (see
  213. framework document).
  214.  
  215.     o can the instance of the topology mechanism be used to bound
  216. the topology gathering process (see framework document)
  217.  
  218.    o what's the right way to detect and process topology changes.
  219.  
  220. Interim Meeting Discussion
  221. ==========================
  222.  
  223. We discussed the need to get active discourse occuring on the mail
  224. list.  It seems that most of the work prior to the Memphis meeting
  225. happened during the 3 weeks prior to the cutoff date (Wayne was
  226. the exception).  An interim meeting would have the benefit of
  227. getting work done 3 weeks ahead of time, but we really need
  228. a more focused effort from the group.
  229.  
  230. It was agreed that the chairman would determine whether sufficient
  231. progress was being made on the mail list, and if not would call for
  232. an interim meeting to be held sometime in June.  We will also try
  233. to coordinate with other Operations and Management WGs that may be
  234. planning interim meetings as well.
  235.  
  236.  
  237.