CURRENT_MEETING_REPORT_ Reported by Theodore Brunner/Tektronix Minutes of the Interfaces MIB Working Group (IFMIB) IEEE 100 Mbps LAN Standards and MIBs for Same The two IEEE groups (802.12/100VG and 802.3UF/100baseX) are currently each developing their own MIB within the IEEE. By the San Jose IETF they will be ready for a BOF, and by spring the IEEE MIBs will be stable. The group consensus is that the two technologies are different and the two groups should be in separate working groups. RFC 1231 - Token Ring MIB The chair enjoined the working group to read and review the MIB, ``IEEE 802.5 MIB'' (draft-ietf-ifmib-tokenringmib-00.txt), (posted in the Internet-Drafts directory since mid July) and post messages to the list, prior to it being promoted out of the working group. Token Ring Source Route MIB This draft document was circulated on the mailing list immediately before the IETF. (Ed: The document has since been posted to the Internet-Draft directories as ``IEEE 802.5 Station Source Routing MIB'' (draft-ietf-ifmib-ssr-mib)). It is directly derived from a proprietary MIB posted to the list. The following editorial comments were made: add a reference clause, explain what the bits mean in route control, explain the syntax in route descriptor, and add display hints if possible. A new draft will be posted soon. Generic Connection MIB The document, ``Management Information Base for Management of Network Connections'' (draft-ietf-ifmib-conntable-02.txt), has been posted in the Internet-Drafts directories since mid-July. The author discussed various issues regarding its design. A discussion evolved around the ``recursive model,'' e.g., as applied to the ATM and Frame Relay (FR) MIB for CNM purposes, which could also be used by the connection MIB. In it, a MIB may be used to represent a cloud/service or a switch/constituent element. The same objects (e.g., interfaces) are reinterpreted in the two representations. For implementation purposes an explicit model should be used for a correlation between an object in one representation with an object in another. This model is not explicitly specified. This may need to be fixed, but not in the context of the connection MIB. It was decided to drop the notion of a non-coordinated MIB. Both FR and ATM can be coordinated with the addition of a pointer through the AUGMENTS mechanism. The X.25 MIB uses a very different model (i.e., not Henrietta double prime) than do FR, ATM and interworking; it cannot be coordinated. Future MIBs can be coordinated when developed. A clearer definition of coordinated must be introduced into the text. It was pointed out that the MIB must spell out very clearly what an NMS must do to manage connections, and what an NMS may do additionally to manage connections, for both pure and interworked connections. There is not yet agreement within the working group on this issue. It was decided that the connection ID space will be coalesced into a single pool for FR, ATM and interworking. The MIB must state this clearly. Similarly, the text should explicitly outlaw the (clearly improper) duplication of ifIndex for the FR, ATM and interworked interface space. It was decided that the mirroring principal was a good thing for the case of interworked connections. With it, several rows exist to represent the connection in the media specific MIBs, and additionally, several rows exist to represent the connection in the interworking MIB. The interworking MIB has a complete picture of the connection, (e.g., all endpoints and all connections) while the media-specific MIBs have a picture of their media-specific portion (e.g., the endpoints). No decision was taken on pure connections. There was discussion on simplifications to the connection MIB. Why is there an endpoint table at all? Couldn't the connection table include pointers to the media-specific endpoint table rows? Why does the connection table have five index variables? It uses two variables (e.g., LowIfIndex and LowCnID) to identify a single endpoint table row. It only really needs one variable. The notion of replacing, in the connection table, integer index variables with OID pointers was rejected (the concept was likened to a ``sucking chest wound''). It was decided that the text should capture the reasons behind this design choice. The Network Management Area Director offered a suggestion to the working group. Since it appeared that there were some design decisions left to make, and since in his estimation the working group had been going around on this MIB for quite some time, he proposed the creation of a design team to report back to the working group. The suggestion was accepted and volunteers experienced with the issues were called for. Andy Malis, Ken Rodemann, and James Watt volunteered. Connection MIB Design Team Meeting The IFMIB Working Group's connection MIB design team met on Thursday. The following people attend: o Ted Brunner o Ken Rodemann o Andy Malis o James Watt o Manu Kaycee o Ron Presti o Steve Buchko This message was delivered from the Network Management Area Director to the design team, by the working group chair: o The connection MIB was started in Spring '93, and has had significant meeting time in Spring '94 and Summer '94. o The working group is not yet unified on its model. E.g., will there be an endpoint table? What are the indexes of the connection table? This creates the perception of more design work left to do. o The working group is not yet agreed on conformance. E.g., which portions of the connection and the media-specific MIB are relevant under what circumstances? Which does an application use? This creates the perception that the working group has more consensus left to achieve. o The notion of ``recursive use'' expressed in this MIB, (although borrowed from the ATM MIB) is not yet fully understood nor modeled. In particular the inter-relationship between views of the same systems, with different ``granularities,'' is unknown. o The director and directorate can see only one clearly expressed use for this MIB: ATM to Frame Relay interworking. Therefore the Network Management Area Director suggests that: o The target status for this MIB should be experimental. o The RFC title and text should explicitly target the ATM to Frame Relay case; the object names and the model should not. o If and when another clear use of the MIB can be expressed, it should be folded in. From the design team came several comments: o The experimental status was ok, as long as the work didn't stay experimental forever. o The focus on ATM and Frame Relay was ok, as long as other cases could be done in the future. o Experience implementing the ATM MIB is just coming out now; there is no experience managing systems with it. It may be best to learn more about using the media specific MIBs before designing a standard interworking MIB. o We cannot drop this work, because ATM to Frame Relay interworking is a requirement. After this, the discussion turned toward design issues. Several points were agreed upon. A management application that sets up connections in either the pure ATM case, or the pure Frame Relay case, must work with no modifications on an agent that supports Frame Relay to ATM interworking. This is a firm requirement. One issue to consider is how to evolve a pure connection into an interworked connection. Where is the locus of control over the connection as it evolves: media-specific MIB or interworking MIB? The unification of the connection MIB's number space (cnConnectcnIndex and cnEndptCnIndexValue) with both the ATM space (atmVcCrossConnectIndex and atmVclCrossConnectIdentifier) and with the Frame Relay space (frPVCConnectIndex and frPVCEndptConnectIdentifier) is very important. Implementing three separate connection numbering spaces is too messy. To support ATM/FR interworking the ATM and FR agents have to be brought together anyway, so this has minor impact. The indexing of the cnConnectTable should be as the current draft f cnIndex, LowIfIndex, LowEndptID, HighIfIndex, HighEndptID g where the pair f ifIndex EndptID g identify an endptTable row. There are three reasons: o The LowEndptID and HighEndptID are merely unique per interface, so there is no need for centralized administration of them (across all interfaces and across ATM, FR, and interworking) o One could use the DLCI or the combined VPI and VCI as the ID. They are unique per port. This is a natural choice. o It matches the model used in the Frame Relay and ATM MIB. The only role of cnEndPtTable is to identify the media-specific endpoint table row (atmVclTable and frPVCEndptTable). It does so through an OID pointer. The cnConnectTable identifies cnEndPtTable rows, through a set of integer indexes shared between cnConnectTable and cnEndPtTable f ifIndex cnID g. The option of removing the cnEndPtTable exists. Then the two OID pointers would exist in the cnConnectTable, in addition to the five index variables. However the thought of replacing the last four of the five index variables with two OID pointers is too horrible to contemplate. The case of circuit-emulation over ATM interworking and Frame Relay over ISDN interworking were discussed. In both cases, what is carried as service on one endpoint (DS3 circuit-emulation, or FR frames) is interworked with what is fabric (DS3, or Frame Relay) on the other endpoint. This involves a layer mismatch, but at least the interfaces evolution MIB allows naming of all relevant layers. Such an interworking is more complex than ATM/FR interworking, where both endpoints are fabric. The draft's introduction provides the normative text of how to use the MIB. However a cookbook of the preferred method of using the connection MIB in common cases should be included in the MIB itself. The ATM and FR MIBs can be used (partially cloned) for this. The meeting ended and the following is an outline of the connection MIB, as the design team left it. (I have re-named some of the objects, hopefully an improvement in clarity.) cnIndexValue Integer32 cnEndptTable INDEX { ifIndex cnEndptID } cnEndptID Integer32 -DLCI / VPI<<16 + VCI cnEndptIndexValue Integer32 -link to cnConnectTable cnEndptMediaSpecificEndptPtr InstancePointer cnEndptName DisplayString - not required. perhaps useful. cnEndptRowStatus RowStatus cnConnectTable INDEX { cnConnectIndex cnConnectLowIfIndex cnConnectLowEndptID cnConnectHighIfIndex cnConnectHighEndptID } cnConnectIndex Integer32 cnConnectLowIfIndex InterfaceIndex cnConnectLowEndptID Integer32 -DLCI / VPI<<16 + VCI cnConnectHighIfIndex InterfaceIndex cnConnectHighEndptID Integer32 -DLCI / VPI<<16 + VCI cnConnectAdminStatus INTEGER cnConnectL2HOperStatus INTEGER cnConnectH2LOperStatus INTEGER cnConnectL2HLastChange TimeStamp cnConnectH2LLastChange TimeStamp cnConnectDirectionFlow -not required? use? cnConnectRowStatus RowStatus