IETF #42 WG Minutes OPS Area; RMONMIB WG Chicago, IL August 27, 1998 WG Chair: Andy Bierman (abierman@cisco.com) Minutes: Andy Bierman and Russell Dietz (rsdietz@tecelite.com) Review Material: (Current I-Ds) [1] RMON Protocol Identifiers (Version 2) [2] SMON MIB [3] HC-RMON MIB (Reviews of Current I-Ds) [4] ftp://ftp-eng.cisco.com/ftp/rmonmib/review-rmonprot-v2-03.txt [5] ftp://ftp-eng.cisco.com/ftp/rmonmib/review-smon-04.txt [6] ftp://ftp-eng.cisco.com/ftp/rmonmib/review-hcrmon-03.txt Agenda: 1) RMON Protocol Identifiers (Version 2) Discussion 2) SMON MIB Discussion 3) HC-RMON MIB Discussion 4) Interoperability Test Event Planning 5) Standards Track Advancement Planning 6) Application/Service Performance Monitoring Executive Summary: The RMONMIB WG is currently working on three different drafts. All of these drafts have been completed for some time, and peer reviews have recently been completed. The meeting was used to "review the review comments", and resolve any open issues with any of the drafts. The WG resolved almost all known issues with these drafts. The next version of each will be the "final draft", and will be forwarded to the IESG for RFC publication, by November 1998. The WG also discussed plans for an upcoming interoperability test event in January 1998, standards advancement plans for the RMON MIBs, and some ideas for a possible future WG charter. 1) RMON PIv2 Discussion The latest PI draft [1] and the associated review comments [4] were discussed by the WG. 1.1) PI document Maintenance The number of protocols supported by the RMON-2 MIB is growing all the time. This is an important issue, because RFC 2021 contains normative references to the Protocol Identifiers document. If the PI document is changing frequently, it will be cycling at Proposed Standard status. This will cause RFC 2021 to stay at Proposed Standard status indefinitely. The WG decided to split the PI document into two pieces. The beginning section, which defines the PI macro format, will become the "Protocol Identifier Reference" document and will stay on the standards track (cycle at Proposed). The hundreds of PI macros will be moved to a new document called the "Protocol Identifier Repository" document, which will be taken off the standards track and published as an Informational RFC. Additions to the PI Repository will then be decoupled from the RMON-2 MIB itself. 1.2) PI macro language and terminology The PI Reference document will be changed to emphasize that the use of "macro" in the term "PI macro" is historical, since they are not really macros. The document will also be clarified in several ways, such as: * many of the acronyms will be expanded at first use * TBDs and editor's notes will be updated and removed * document format and boilerplate will be updated as per RFCs 2026, 2119, and 2223 1.3) Protocol Verbs It is possible that support for "sub-protocols" or "verbs" will be added to the PI Reference and Repository documents in the future. These verbs would allow specific operations of various terminal protocols to be uniquely identified, for counting and service monitoring purposes. 1.4) Encapsulation Layer Protocols The encapsulation layer protocols, such as IEEE 802.1Q, cause the number of protocolDirectory entries to increase dramatically. The idea of treating such layers as just another type of "base layer" was discussed. It was decided that although few (if any) implementations actually model 802.1Q as a specific layer in each protocol identifier, there is not enough interest to change the encapsulation layer identifiers at this time. It was noted that specific "VLAN ID" and "user priority" statistics can be obtained with the SMON MIB. The only potential impact is in the protocolDistStatsTable and the RMON-2 relative-offset filtering mechanism. 1.5) Interoperability Test Issues Specific interoperability issues related to the PI Reference and (to a lesser degree) the PI Repository documents were discussed. The following requirements were identified: * Need to test agents with real traffic (e.g., traffic playback), not simulated and/or partially constructed application traffic. * Need to test protocols with specific protocolDirParameters BITS set and cleared (e.g. NFS fragments, TFTP sessions). * Need to test IP tunneling and other "multiple L3" protocol encapsulations * Need to test with some "802.1Q tagged" traffic 1.6) Wildcard Terminal Mechanism The protocol directory (PD) can contain many different encapsulations of the same application. It is desirable to create a wildcard mechanism for terminal protocols, similar to the existing L3 wildcard mechanism. This can reduce the memory used by the agent, and the polling required by the NMS application. A proposal for a new "base layer function" to identify wildcard terminals will be sent to the mailing list by Russell Dietz for the WG to evaluate. The function must allow a particular terminal PI to be identified as a "wildcard-terminal", and the L3 address type information must be preserved (for NL and AL counting purposes). If there are no strong objections posted to the mailing list, the wildcard terminal function may be altered, and then added to the PI Reference document as an optional feature, (i.e., no MIB objects will require that wildcard-terminal encapsulations be present in the PD). 1.6) Protocol Local Index Mapping Table A proposal for a new mapping feature was discussed, which would provide a simple mapping from a protocolDirLocalIndex to its associated { protocolDirID, protocolDirParameters } tuple. This will be discussed on the mailing list and deferred to future work. 2) SMON MIB Discussion The latest SMON MIB draft [2] and the associated review comments [5] were discussed by the WG. 2.1) Garbage Collection Review Comments A review issue was raised regarding the garbage collection of the smonPrioStatsTable. These entries are not garbage-collected, but the smonVlanIdStatsTable is (LRU) garbage- collected. The document will be updated to include the rationale for this decision. An individual smonPrioStatsTable has a maximum of 8 rows, which is small enough to expect an agent to account for all 8 possible minor index values, without garbage collection. 2.2) OID Assignment Conflicts The current HC-RMON and SMON drafts use the same OID assignment in some places. The SMON MIB will keep its current numbering and the HC-RMON MIB will be renumbered to fix this problem. 2.3) OwnerString Re-definition Issue There is a re-definition of the OwnerString TC, which causes popular MIB compilers to generate error messages when compiling this MIB. The OwnerString TC in RFC 1271 (later 1757) is not exactly the same as the cloned version in the Interfaces MIB (RFC 2233), partly due to the translation from SMIv1 to SMIv2. SMON imports ifIndex from the Interfaces MIB, so MIB compilers complain about the "re-definition" of the OwnerString TC. This problem is avoided in the RMON-2 MIB by importing ifIndex from RFC1213- MIB, instead of IF-MIB. (Not a great solution either!) This issue is not likely to be resolved by the RMONMIB WG, but it will be taken to the mailing list, in the hope someone will propose a solution to this "dependency mess". Perhaps when RFC 1757 is updated in SMIv2 format (see sec. 5.1) the OwnerString textual convention can be renamed to RmonOwnerString", and all usage of "OwnerString" in RMON MIBs will be changed to "RmonOwnerString" as each MIB is updated (e.g., from Proposed to Draft Standard). Hopefully, a less intrusive solution will be proposed on the mailing list instead. 2.4) SMON dataSourceCapsTable Indirection Issue The dataSourceCapsTable allows an agent to map Entity MIB physical entities (e.g., repeater backplanes) and entire VLANs to ifEntries with ifType "propVirtual(53)". There is some concern regarding customer confusion and increasing the size of the ifTable. The SMON editors will add clarifying text regarding this issue to the next SMON draft. 2.5) portCopyTable Bugs The portCopyTable conformance statement and ASN.1 comments related to the portCopyTable conformance are inconsistent. The SMON editors will change one of them to fix the problem. The portCopyIndex range will also be expanded to match the upper bound used in the InterfaceIndex textual convention. 2.6) New SMON portCopyTable Features A proposal for adding new features (i.e. columns) to the portCopyTable was discussed by the WG. There seem to be some common features that have been implemented in proprietary MIBs, which would be useful in a standard MIB. New features proposals include: * portCopyDirection: SYNTAX INTEGER { rx(1), tx(2), both(3) } A parameter to select traffic by direction. * portCopyVlanID: SYNTAX Integer32 (0..???) allow for copy of a single configured VLAN from a ingle dataSource (presumed to carry traffic from multiple VLANs). * portCopyVlanIdMask: SYNTAX BITS allow for copy of multiple configured VLANs from a single dataSource (presumed to carry traffic from multiple VLANs). * Copy only traffic that matches a certain MAC address (SA or DA). * Control table switch to configure the copying of errored frames. There seemed to be WG interest for some of the proposals, but not necessarily in the first version of the SMON MIB. The portCopyDirection object had received the most discussion. The WG held the following "vote" to gauge consensus: 1) Don't want to do any of this in the SMON MIB 2) Move the portCopyTable forward as-is, with no new features at this time. 3) Add the portCopyDirection object now, and postpone consideration for all other new features to a future release. Results: 1) 0 2) 3 3) 8 The WG Chair has posted a proposal for this object to the mailing list. Unless there are any objections within the next two weeks, the SMON editors will add it to the next SMON draft (directly to the portCopyTable). 2.7) smonVlanIdStatsId Range The smonVlanIdStatsId object has a range of 0..4095. Apparently, the new Bridge MIB has a TC to define a special VLAN index value, such that values for non-802.1Q VLANs (above 4095) can be supported. A clause in the conformance section would be needed for this MIB object, so it is clear that only index values 0..4095 are mandatory for MIB conformance. The "working proposal" is that the upper bound of this MIB object be increased to match the Bridge MIB TC. The DESCRIPTION clause will explain the "non-dot1Q" semantics of VLAN indexes above 4095. Unless there are any objections within the next two weeks, the SMON editors will make this change to the smonVlanIdStatsId object. 2.8) Interoperability Test Issues Specific interoperability issues related to the SMON MIB were discussed. The following requirements were identified: * Need to use "tagged" test traffic for multiple, specific 802.1Q VLAN IDs. * Need to use test traffic tagged with multiple, specific 802.1p user priority values. * Need to test dataSourceCapsTable against real and reported capabilities * Need to test usage the new SmonDataSource TC options, smonVlanDataSource. and entPhysicalIndex.. * Need to test portCopyTable operation and capabilities, compared to those reported in the dataSourceCapsTable. 3) HC-RMON MIB Discussion The latest High Capacity RMON draft [3] and the associated review comments [6] were discussed by the WG. 3.1) Rationale for ZeroBased counters The ZeroBasedCounter32 and ZeroBasedCounter64 textual conventions do not contain any rationale for the usage of the TC. The HC-RMON MIB editor will add some clarifying text as to the expected TC usage, explaining that these counters are found in data tables that get created by management action. The starting value of zero represents an implied poll, taken at the moment the table is instantiated. 3.2) mediaIndependentTable Conformance The mediaIndependentTable is a "stand-alone" feature, yet it is part of the conformance statement for the RMON-2 HC extensions. The HC-RMON editor will move this table to its own conformance macro. 3.3) mediaIndependantTable Duplex Changes The mediaIndepenentTable is defined such that the "out" counters are only instantiated if the port is operating in full-duplex mode. This causes a problem for NMS applications if the duplex mode of the port changes while the mediaIndependentEntry is active. There are no discontinuity indicators for either the "in" or "out" counters in this table, such as "last-activated-time" or "last-duplex-mode-change-time" Timestamp objects. There is no explicit indication of the duplex mode, which would be useful for configuring RMON alarms on duplex-mode changes. The WG will discuss this issue on the mailing list. There seemed to be WG consensus that the table is broken as-is, but it is worth fixing, and the solution should not be that difficult. Three different approaches seem to be popular on this issue: 1) the "minor tweak" solution: Change the text that says the "out" counters go away to state instead that the "out" counters never go away, but simply stop incrementing in half-duplex mode. 2) the "80/20 solution": Make the change in (1), but also add one new read-only MIB object to explicitly identify the duplex mode * mediaIndependentDuplexMode - enum { half(1), full(2) } 3) the "complete solution": Make the changes in (1) and (2), but also add some new read-only MIB objects to help detect duplex mode changes: * mediaIndependentDuplexChanges - Counter32 * mediaIndependentLastDuplexChangeTime - TimeStamp The WG will discuss this issue on the mailing list over the next two weeks, and hopefully a consensus will be reached in that time. The HC-RMON MIB cannot advance until this issue is resolved, so hopefully the WG will discuss and resolve this issue quickly. 3.4) ZeroBasedCounter64 TC This TC uses SYNTAX Counter64, which is not an entirely legal modification to the Counter64 semantics. The issue is that a counter has special semantics related to its monotonically increasing behavior. A "snapshot" of a counter does not monotonically increase, so it should be a gauge instead. The RMONMIB WG has been waiting for the SNMP WG to add Integer64, Gauge64, and/or UInteger64 to the SMIv2, but the SNMP WG finally decided not to add any new 64-bit types to the SMI in the near future. The RMONMIB WG therefore decided to leave the ZeroBasedCounter64 TC as-is. There is some field experience already that the Counter64 "wire-encoding" does not cause interoperability problems between HC-RMON agents and applications. 4) Interoperability Test Event Planning The WG discussed the possibility of another interoperability test event, to test RMON-2 and the new MIBs. 4.1) Testing Scope and Logistics The following documents would be tested: * RMON-2 MIB [RFC 2021] * RMON-2 PIv2 update to [1] * SMON MIB update to [2] * HC-RMON MIB update to [3] The timeframe for the test event will be mid or late January 1999. The test event will be hosted by InterWorking Labs, and will be held in (or close to) San Jose, CA. The testing requirements mentioned in sections 1.5 and 2.8 will be addressed at the test, as well as general interoperability of the RMON-2 and HC-RMON MIBs. Test networks consisting of 10/100 ethernet and gigabit ethernet segments will be used (assuming vendors will loan equipment and engineers for the test). Further announcements regarding this test event will be made on the WG mailing list later this year. 5) Standards Track Advancement Planning The existing RMON MIBs need to progress along the standards track. Each MIB was discussed by the WG, and The following actions will be taken for each MIB: 5.1) RFC 1513 - Token Ring RMON and RFC 1757 - RMON-1 MIB The WG Chair will issue a call for interoperability reports on the mailing list. Implementors will be asked to fill out a survey and email it back to the WG Chair, who will publish the results. These MIBs will also be converted to SMIv2 format as they are progressed on the standards track. The Token Ring RMON MIB is due to move from Proposed Standard to Draft Standard, and the RMON-1 MIB is due to move from Draft Standard to Full Standard. The WG Editor will produce converted drafts of these MIBs and the WG will discuss the conformance sections (and any other details) on the mailing list. No timeframe has been set for this task, but it is hoped that the reports and drafts will be ready be the next IETF in December 1998. 5.2) RFC 2021 - RMON-2 MIB The RMON-2 MIB will not be advanced at this time. The associated Protocol Identifiers document will cycle at Proposed Standard, and these documents will be advanced together at a later time. 5.3) RFC 2074 - RMON Protocol Identifiers This document will be obsoleted by the final, published version of the PIv2 draft [1]. The document will be split into two RFCs, as described in section 1.1. The standards track "PI Reference" document will cycle at Proposed Standard. The more dynamic "PI Repository" document will become an informational RFC, and will be decoupled from RFC 2021 and the PI Reference. 6) Application/Service Performance Monitoring The WG discussed some ideas for future work. Ideas for a charter proposal for Application or Service Level Monitoring were discussed briefly, and will be discussed further on the mailing list. The WG Chair and the Area Director want to make sure any proposed work items be measurable, verifiable and interoperable. The proposed charter should perhaps be based on metrics defined by the IPPM WG. There are differing opinions on all the features needed to do Application and/or Service Level Monitoring, as there is disagreement to what these terms even mean. The proposed charter should consider precise goals and not be limited in scope to passive protocol response timing. The WG also discussed a couple other features that may be considered in the new charter: * a "username-to-L3-address" mapping function * distribution counters for DIFFSERV codepoint usage; Augmentation to some RMON- 2 tables (e.g., protocolDistStatsTable and alHostTable) Ideas and comments on the proposed charter should be sent to the WG mailing list. A final version is expected to be forwarded to the Area Director before the next IETF in December 1998.