New Work in the Network Management Area Orlando, 12/10/1998 Chair: Bert Wijnen Reported by: Shawn A. Routhier http://www.ops.ietf.org Area mailing list: ops-area@ops.ietf.org Editor's note: Most of this meeting was devoted to a series of presentations with little discussion on each. I have attempted to briefly summarize each presentation, however the reader might want to examine the slides for more detail. The opening comments from the chair noted that while we may start looking at new work now, we, as promised by a previous AD, must finish SNMPv3 and SMIv2 before that new work can be started. The opening comments from the AD (Harald): The IETF's purpose is to make the internet work. The purpose of the OPS area is to manage the network, it is not to allow vendors to sell, nor to provide elegant solutions. It's purpose is to make sure we can make the internet go. Device management via SNMP is useful as long as it makes the internet work, and if other schemes will help we should investigate them. The purpose of doing new work is to make sure the internet survives, and the yardstick to measure any new ideas is "is this the most critical issue we can solve". The first presentation was from Karl E. Schohl, ANX Business Manager from the Automotive Industry Action Group. This industry is using their networks in a business to business fashion and quality is a critical factor. As such they are using network management in order to track the service quality and to handle trouble as it arises. One particular area they have worked on is defining performance and reliablity metrics in order to categorize the networks and the service levels. Currently these metrics are per technology and aren't consistent across technologies. They are looking for buy in from the NM community to supply expertise to help in building consistent methods for discovery and management. It was pointed out that MIBs for some areas they were concerned with (Tunnels and VPN) already exist and more work in those areas may not be needed. The next presentation was from Terry Davis of Boeing and was on serveral thoughts from an enterprise viewpoint. A lot of their time is spent doing middle layer work and tying existing systems together. Ideas that make these connections simpler are valuable. They are also interested in getting the end nodes included within the network management scheme, particularly to allow for management of end to end services. They have found some simple tools such as a response time MIB and traceroute functionality to be valuable. He also made the point that SNMPv3 needs to be finished. Bob Stewart wanted to bring up several issues that have been discussed in other areas but have yet to find a conclusion or home. Security - how much affect is or should security have when building mibs. Should every mib table have an owner string as part of the instances for security. Persistence and storage type - There are several questionable areas, mostly for scalars, that should be clarified. When should any changes take affect - immediately or upon reboot? Should the row be saved across reboots? And so on. Bulk data transfer - several drafts submitted that attempt to remove some of the ASN1 redundancy and then use FTP tomove the file. This is work that is looking for a home. The idea of a general method for throttling traps was brought up in other working groups and was deferred in them as out of scope. It was raised here as a possible future work item. It was pointed out that there were two sets of discussions occurring, one on managing a single device and one a managing a collection of devices. There may be a disconnect between the two and we may need to resolve it. Juergen Schoenwaelder discussed several items that might not be large enough to require their own working group but might be able to be handled in some other group or perhaps without one. The items were: the TDOMAIN/TADDRESS work from Mike Daniele, creating a single document out of several commonly used Textual Conventions, and some methods for timestamping events preferably without using a wall clock. Bob Natale described the current status of the WinSNMP effort and proposed bringing it into the IETF with a working group to update it to include SNMPv3 funtionality. Bob included a proposed WG charter and some possible candidates for WG roles. There was some discussion about the WinSNMP API and the AgentX API (no connection) and the SNMPv3 ASIs (less detailed but obviously more constrained). As well as discussion about possible backwards compatibility issues as the WG would not be required to produce a backwards compatible API. For other information about WinSNMP see the website at "www.winsnmp.com" and the mailing list at "WinSNMP@mailbag.intel.com". To subscribe send mail to "listserv@mailbag.intel.com" with a blank subject line and a message body of "subscribe winsnmp". Jim McQuaid discussed "Applications Performance on the Network". This talk assumes that the IETF isn't the appropriate forum for several areas such as, desktops, servers, applications and databases. Rather the IETF should concentrate on network issues and, more specifically in this case, on gaining an understanding of feasible network based performance metrics. The suggested deliverables would be definitions for the performance metrics, a framework for the data collection and a MIB or other method for outputting the data. The audience pointed out that some of this work might be included elsewhere such as RMON and IPPM. For other information see the mailing list at "artmib_bof@art.netscout.com", subscribe to "artmib_bof-request@art.netscout.com". Dave Thaler discussed "automated problem reporting & feedback". The concept is to allow problem reports to be automatically moved around the network, possibly triggering new testing and being modified as they move. A key to this functionality is a standard format and method for reporting network problems. Some of the issues are scalability, reporting the destination ID, and privacy. Some work has already been done in this area on the MBONE at Merit. For more information see "http://www.eecs.umich.edu/~thalerd/gdt/" or the strawman protocol in "draft-thaler-gdt-00.txt". There was some discussion that some work in this area may have been done in the CMIP world as well as the IETF. There was also discussion that there might need to be two APIs one to report an item, and another to move that information around the network. Lastly SNMP might not be the proper tool to start with as the two sides may be in different trust domains which could cause some problems. Ariel Pashtan discussed "common network management agents". Currently managers must understand different interfaces for different network elements which makes writing and using them difficult. This was a proposal to try and standardize the interfaces for the NEs to improve the management functions. One part of the propsal was to define service levels to allow managers to categorize and manipulate the elemenets more easily. There was some discussion about how this topic interacted with other areas such as DISMAN and the possibility of starting with a small area such as a common interface to a distributed mid-level manager or alarms that agents might produce and growing from there. John Ioadnnidis discussed "trust management for SNMP". This was another look at dealing with security policies. The view starts with the position that the current VACM in SNMPv3 isn't flexible enough for fine grained access control and expands to include the difficulty with expressing complex policies and managing them in general. The "trust management" scheme being worked on elsewhere in the IETF might provide another solution to the problem. In this scheme the application would from a query to send to a server to determine the appropriate access levels for a "user". More information may be found in "draft-blaze-ietf-trustmgt-keynote-00.txt" There was some discussion about possible slow downs while attempting to access a server for each packet, as the results may be cached this shouldn't be a problem. Ed Ellison presented the Policy Framework WG. They are working on some of the elements required to allow an entire set of devices to use a coherent policy from end to end. As part of their work they have liaison relationship with DMTF (http://www.dmtf.org). They are interested in retrieving information via MIBs and SNMP. This information would be used to correlate what actually happened from what was desired by the policy. For example wat service level was given vs what was desired. Dave Perkins presented proposals to complete the set of data types in use by SNMP. He suggests that the list of data types should match those find in most programming languages and should include types such as uint64, int64, float, double float and discriminated union. This should be done without breaking conforming entities or mib processing tools and without protocol or api changes. He has already done some prototyping for the types and belives this should be a short (4 months?) effort. A member of the audience asked if the new types would be usable as indexes, Dave didn't think so. Dave also suggested that work should be done on creating a new PDU for use with bulk data retrieval. The new PDU should have the same look and feel as the current PDUs, have minimal impact on SNMP entities and meet specific constraints on functionality - Dave suggests a requirement of 3x speed up over GETBULK. He believed this should be another short duration effort. The microphone was then opened to the audience for general comments. Two other work items were suggested: some of the Asset Management MIB that was discussed in the Entity MIB might be better done here and the merging of the TCP/UDP MIBs for IPv4 and IPv6. One person suggested that we continue the style of the SNMPv3 WG and try to use a moudlar architecture where possible and split the problem(s) into smaller areas with smaller WGs. The ADs mentioned the small design team approach and its success with SMIv2. Finally it was suggested that we should review the current set of tools that we have and determine which tools may be missing as well as cleaning up overlaps. There was no time left for discussion and prioritization. The discussion will be continued on the mailing list -- ops-area@ops.ietf.org, comments and/or new items should be sent to the mailing list ASAP.