home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ifmib / ifmib-minutes-94jul.txt < prev    next >
Text File  |  1994-11-01  |  12KB  |  274 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Theodore Brunner/Tektronix
  5.  
  6. Minutes of the Interfaces MIB Working Group (IFMIB)
  7.  
  8.  
  9.  
  10. IEEE 100 Mbps LAN Standards and MIBs for Same
  11.  
  12. The two IEEE groups (802.12/100VG and 802.3UF/100baseX) are currently
  13. each developing their own MIB within the IEEE. By the San Jose IETF they
  14. will be ready for a BOF, and by spring the IEEE MIBs will be stable.
  15. The group consensus is that the two technologies are different and the
  16. two groups should be in separate working groups.
  17.  
  18.  
  19. RFC 1231 - Token Ring MIB
  20.  
  21. The chair enjoined the working group to read and review the MIB, ``IEEE
  22. 802.5 MIB'' (draft-ietf-ifmib-tokenringmib-00.txt), (posted in the
  23. Internet-Drafts directory since mid July) and post messages to the list,
  24. prior to it being promoted out of the working group.
  25.  
  26.  
  27. Token Ring Source Route MIB
  28.  
  29. This draft document was circulated on the mailing list immediately
  30. before the IETF. (Ed:  The document has since been posted to the
  31. Internet-Draft directories as ``IEEE 802.5 Station Source Routing MIB''
  32. (draft-ietf-ifmib-ssr-mib)).  It is directly derived from a proprietary
  33. MIB posted to the list.
  34.  
  35. The following editorial comments were made:  add a reference clause,
  36. explain what the bits mean in route control, explain the syntax in route
  37. descriptor, and add display hints if possible.
  38.  
  39. A new draft will be posted soon.
  40.  
  41.  
  42. Generic Connection MIB
  43.  
  44. The document, ``Management Information Base for Management of Network
  45. Connections'' (draft-ietf-ifmib-conntable-02.txt), has been posted in
  46. the Internet-Drafts directories since mid-July.  The author discussed
  47. various issues regarding its design.
  48.  
  49. A discussion evolved around the ``recursive model,'' e.g., as applied to
  50. the ATM and Frame Relay (FR) MIB for CNM purposes, which could also be
  51. used by the connection MIB. In it, a MIB may be used to represent a
  52. cloud/service or a switch/constituent element.  The same objects (e.g.,
  53. interfaces) are reinterpreted in the two representations.  For
  54. implementation purposes an explicit model should be used for a
  55. correlation between an object in one representation with an object in
  56. another.  This model is not explicitly specified.  This may need to be
  57. fixed, but not in the context of the connection MIB.
  58.  
  59. It was decided to drop the notion of a non-coordinated MIB. Both FR and
  60. ATM can be coordinated with the addition of a pointer through the
  61. AUGMENTS mechanism.  The X.25 MIB uses a very different model (i.e., not
  62. Henrietta double prime) than do FR, ATM and interworking; it cannot be
  63. coordinated.  Future MIBs can be coordinated when developed.
  64.  
  65. A clearer definition of coordinated must be introduced into the text.
  66.  
  67. It was pointed out that the MIB must spell out very clearly what an NMS
  68. must do to manage connections, and what an NMS may do additionally to
  69. manage connections, for both pure and interworked connections.  There is
  70. not yet agreement within the working group on this issue.
  71.  
  72. It was decided that the connection ID space will be coalesced into a
  73. single pool for FR, ATM and interworking.  The MIB must state this
  74. clearly.  Similarly, the text should explicitly outlaw the (clearly
  75. improper) duplication of ifIndex for the FR, ATM and interworked
  76. interface space.
  77.  
  78. It was decided that the mirroring principal was a good thing for the
  79. case of interworked connections.  With it, several rows exist to
  80. represent the connection in the media specific MIBs, and additionally,
  81. several rows exist to represent the connection in the interworking MIB.
  82. The interworking MIB has a complete picture of the connection, (e.g.,
  83. all endpoints and all connections) while the media-specific MIBs have a
  84. picture of their media-specific portion (e.g., the endpoints).  No
  85. decision was taken on pure connections.
  86.  
  87. There was discussion on simplifications to the connection MIB. Why is
  88. there an endpoint table at all?  Couldn't the connection table include
  89. pointers to the media-specific endpoint table rows?
  90.  
  91. Why does the connection table have five index variables?  It uses two
  92. variables (e.g., LowIfIndex and LowCnID) to identify a single endpoint
  93. table row.  It only really needs one variable.
  94.  
  95. The notion of replacing, in the connection table, integer index
  96. variables with OID pointers was rejected (the concept was likened to a
  97. ``sucking chest wound'').  It was decided that the text should capture
  98. the reasons behind this design choice.
  99.  
  100. The Network Management Area Director offered a suggestion to the working
  101. group.  Since it appeared that there were some design decisions left to
  102. make, and since in his estimation the working group had been going
  103. around on this MIB for quite some time, he proposed the creation of a
  104. design team to report back to the working group.  The suggestion was
  105. accepted and volunteers experienced with the issues were called for.
  106. Andy Malis, Ken Rodemann, and James Watt volunteered.
  107.  
  108.  
  109. Connection MIB Design Team Meeting
  110.  
  111. The IFMIB Working Group's connection MIB design team met on Thursday.
  112.  
  113. The following people attend:
  114.  
  115.  
  116.    o Ted Brunner
  117.    o Ken Rodemann
  118.    o Andy Malis
  119.    o James Watt
  120.    o Manu Kaycee
  121.    o Ron Presti
  122.    o Steve Buchko
  123.  
  124.  
  125. This message was delivered from the Network Management Area Director to
  126. the design team, by the working group chair:
  127.  
  128.  
  129.    o The connection MIB was started in Spring '93, and has had
  130.      significant meeting time in Spring '94 and Summer '94.
  131.  
  132.    o The working group is not yet unified on its model.  E.g., will
  133.      there be an endpoint table?  What are the indexes of the connection
  134.      table?  This creates the perception of more design work left to do.
  135.  
  136.    o The working group is not yet agreed on conformance.  E.g., which
  137.      portions of the connection and the media-specific MIB are relevant
  138.      under what circumstances?  Which does an application use?  This
  139.      creates the perception that the working group has more consensus
  140.      left to achieve.
  141.  
  142.    o The notion of ``recursive use'' expressed in this MIB, (although
  143.      borrowed from the ATM MIB) is not yet fully understood nor modeled.
  144.      In particular the inter-relationship between views of the same
  145.      systems, with different ``granularities,'' is unknown.
  146.  
  147.    o The director and directorate can see only one clearly expressed use
  148.      for this MIB: ATM to Frame Relay interworking.
  149.  
  150.  
  151. Therefore the Network Management Area Director suggests that:
  152.  
  153.  
  154.    o The target status for this MIB should be experimental.
  155.  
  156.    o The RFC title and text should explicitly target the ATM to Frame
  157.      Relay case; the object names and the model should not.
  158.  
  159.    o If and when another clear use of the MIB can be expressed, it
  160.      should be folded in.
  161.  
  162.  
  163. From the design team came several comments:
  164.  
  165.  
  166.    o The experimental status was ok, as long as the work didn't stay
  167.      experimental forever.
  168.  
  169.    o The focus on ATM and Frame Relay was ok, as long as other cases
  170.      could be done in the future.
  171.  
  172.    o Experience implementing the ATM MIB is just coming out now; there
  173.      is no experience managing systems with it.  It may be best to learn
  174.      more about using the media specific MIBs before designing a
  175.      standard interworking MIB.
  176.  
  177.    o We cannot drop this work, because ATM to Frame Relay interworking
  178.      is a requirement.
  179.  
  180.  
  181. After this, the discussion turned toward design issues.  Several points
  182. were agreed upon.
  183.  
  184. A management application that sets up connections in either the pure ATM
  185. case, or the pure Frame Relay case, must work with no modifications on
  186. an agent that supports Frame Relay to ATM interworking.  This is a firm
  187. requirement.  One issue to consider is how to evolve a pure connection
  188. into an interworked connection.  Where is the locus of control over the
  189. connection as it evolves:  media-specific MIB or interworking MIB?
  190.  
  191. The unification of the connection MIB's number space (cnConnectcnIndex
  192. and cnEndptCnIndexValue) with both the ATM space (atmVcCrossConnectIndex
  193. and atmVclCrossConnectIdentifier) and with the Frame Relay space
  194. (frPVCConnectIndex and frPVCEndptConnectIdentifier) is very important.
  195. Implementing three separate connection numbering spaces is too messy.
  196. To support ATM/FR interworking the ATM and FR agents have to be brought
  197. together anyway, so this has minor impact.
  198.  
  199. The indexing of the cnConnectTable should be as the current draft 
  200. f cnIndex, LowIfIndex, LowEndptID, HighIfIndex, HighEndptID g where the
  201. pair f ifIndex EndptID g identify an endptTable row.  There are three
  202. reasons:
  203.  
  204.  
  205.    o The LowEndptID and HighEndptID are merely unique per interface, so
  206.      there is no need for centralized administration of them (across all
  207.      interfaces and across ATM, FR, and interworking)
  208.  
  209.    o One could use the DLCI or the combined VPI and VCI as the ID. They
  210.      are unique per port.  This is a natural choice.
  211.  
  212.    o It matches the model used in the Frame Relay and ATM MIB.
  213.  
  214.  
  215. The only role of cnEndPtTable is to identify the media-specific endpoint
  216. table row (atmVclTable and frPVCEndptTable).  It does so through an OID
  217. pointer.  The cnConnectTable identifies cnEndPtTable rows, through a set
  218. of integer indexes shared between cnConnectTable and cnEndPtTable f
  219. ifIndex cnID g.  The option of removing the cnEndPtTable exists.  Then
  220. the two OID pointers would exist in the cnConnectTable, in addition to
  221. the five index variables.  However the thought of replacing the last
  222. four of the five index variables with two OID pointers is too horrible
  223. to contemplate.
  224.  
  225. The case of circuit-emulation over ATM interworking and Frame Relay over
  226. ISDN interworking were discussed.  In both cases, what is carried as
  227. service on one endpoint (DS3 circuit-emulation, or FR frames) is
  228. interworked with what is fabric (DS3, or Frame Relay) on the other
  229. endpoint.  This involves a layer mismatch, but at least the interfaces
  230. evolution MIB allows naming of all relevant layers.  Such an
  231. interworking is more complex than ATM/FR interworking, where both
  232. endpoints are fabric.
  233.  
  234. The draft's introduction provides the normative text of how to use the
  235. MIB. However a cookbook of the preferred method of using the connection
  236. MIB in common cases should be included in the MIB itself.  The ATM and
  237. FR MIBs can be used (partially cloned) for this.
  238.  
  239. The meeting ended and the following is an outline of the connection MIB,
  240. as the design team left it.  (I have re-named some of the objects,
  241. hopefully an improvement in clarity.)
  242.  
  243.  
  244. cnIndexValue                    Integer32
  245.  
  246. cnEndptTable INDEX {    ifIndex
  247.                        cnEndptID }
  248.  
  249.      cnEndptID               Integer32       -DLCI / VPI<<16 + VCI
  250.      cnEndptIndexValue       Integer32       -link to cnConnectTable
  251.      cnEndptMediaSpecificEndptPtr   InstancePointer
  252.      cnEndptName             DisplayString   - not required. perhaps useful.
  253.      cnEndptRowStatus        RowStatus
  254.  
  255. cnConnectTable INDEX {  cnConnectIndex
  256.                        cnConnectLowIfIndex
  257.                        cnConnectLowEndptID
  258.                        cnConnectHighIfIndex
  259.                        cnConnectHighEndptID }
  260.  
  261.      cnConnectIndex                  Integer32
  262.      cnConnectLowIfIndex             InterfaceIndex
  263.      cnConnectLowEndptID             Integer32       -DLCI / VPI<<16 + VCI
  264.      cnConnectHighIfIndex            InterfaceIndex
  265.      cnConnectHighEndptID            Integer32       -DLCI / VPI<<16 + VCI
  266.      cnConnectAdminStatus            INTEGER
  267.      cnConnectL2HOperStatus          INTEGER
  268.      cnConnectH2LOperStatus          INTEGER
  269.      cnConnectL2HLastChange          TimeStamp
  270.      cnConnectH2LLastChange          TimeStamp
  271.      cnConnectDirectionFlow                         -not required? use?
  272.      cnConnectRowStatus              RowStatus
  273.  
  274.