CURRENT_MEETING_REPORT_ Reported by Fred Baker/ACC SNMP Device Discovery BOF Minutes Prior to meeting at the IETF, there was an extended discussion on the SNMP and finder@emerald.acc.com mailing lists. It is summarized as follows, as it represents a significant context to the BOF held at the IETF meeting. Essentially, we have two problems and at least three solutions on the table. The purpose of the BOF is exploratory - there exists a subset of individuals who feel that there is no viable problem to solve, and if there is it should not be solved; there are others who support various viewpoints. We need to get all the laundry on the table and come up with a problem statement before we can either proceed or decide to not proceed. The problems are: o Within a single administrative domain, it should be possible for Network Management Systems to locate all of the systems appropriate for them to manage (e.g., with SNMP) without preconfiguration. This is believed to be helpful to Network Managers in that they now have positive assurance that they do in fact know all of the key devices in their networks. This viewpoint has been presented by a couple of vendors, and was in fact the start of the discussion. o Within a single administrative domain, it is possible and probable that devices are added to the network without the knowledge of the network manager. Several Network Managers have indicated a desire to know literally all of the devices on their networks, and their network layer attributes. The potential solutions may be classified as ``first person'', ``second person'', and ``third person'' solutions, and there are a couple of variations on each of those: First Person: Examples of current deployment: Wide area: RWHO... Immediate Neighbor: OSPF, ES-IS, IS-IS, DECNET, RIP, DECNET, DEC MOP, DEC LAT... Each SNMP-manageable device on the network periodically emits a trap which announces its presence to interested parties. The trap is sent to a multicast which is received by interested parties on the extended LAN. Its contents include Object Identifiers of MIB Groups supported by the device, system.sysObjectID, and the Read-only community string/party to be used with this agent. If we presume that the probability that a multicast will reach all of its intended recipients > some value, then the probability that all of the network managers know about all of the devices they should manage within some amount of time is a function of the emission rate and the time limit. 1 A second version of this might use IP Multicasting to propagate information throughout the administrative domain. Concerns: First approach: Impact of SNMP Security Architecture not yet analyzed. Does not propagate information beyond router. Second approach: scaling, definition of administrative boundaries, some details in SNMP. Impact of SNMP Security Architecture not yet analyzed. Doesn't solve second problem. second person: Examples of current deployment: ARP, 802.5 RIF Discovery, DEC RBMS Each interested party does something to elicit a response from the systems it is concerned about. This might include sweeping MIBs and then pinging new folks discovered in ARP caches, etc. Someone has suggested letter bombs - broadcast a GET system.sysDescr, and collect the responses. In the latter class of solution, there would need to be either some random ``host delay'' to avoid flooding the network, or an ``exclusion group'' to advise responders to NOT respond. Concerns: scaling, traffic level, both burst and sustained, definition of administrative boundaries. Sweeps may solve second problem, or at least part of it, but this is not assured. broadcast ``pings'' only solve it for the architectures whose ``ping'' is used, and not all architectures define a ``ping''. third person: Examples of current deployment: RMON MIB A subset of the systems in the network actively notify the interested NMSs of new systems that they detect. ``Detection'' is somewhat imprecise - one proposal defines detection to be a protocol specific neighboring relationship; another defines it as the use of a LAN source address. In the latter, the RMON MIB is proposed as a solution. Concerns: With the RMON MIB, no network layer information is captured. If the network manager is not on the local wire with the system found, it has no information other than the MAC Address and the location of the monitor with which to do anything further and no protocol with which to get it. With the RMON MIB, only LAN systems are detected, and then only on LANs that have objects defined in RMON. As it stands today, RMON is fairly obviously targeted at Ethernet. For use on Token Ring or FDDI, there is additional work defined by the RMON WG. Multipoint networks such as SMDS and Frame Relay are not addressed; this may or may not be an issue - can we assume that contracts exist in the presence of these technologies? Are private networks a concern? With the protocol specific detection, a router or bridge could advertise the MAC and network layer information to the NMS; the fact that a TRAP is unreliable means that the NMS might nonetheless fail to learn the information. Use of a SET has been suggested, but some feel that specifying an application residing in the router or bridge is distasteful. Each NMS could also poll the subset of systems (monitors, routers, etc, a limited subset of the network) for new information. The BOF was started with a presentation by Anil Rijsinghani of 2 Digital, whose question on the SNMP Mailing List is what actually started the whole debate. His fundamental concern, echoed by some other vendors, was that there is today no single, reliable, way to find all of the SNMP Manageable devices in an administrative domain. Corollary to that, there is no way to determine what MIBs any given station supports. Even a MIB walk may not return that information if a MIB is primarily composed of tables and the service is not currently configured or active. Mechanisms that are available depend on assumptions that may not hold, such as the use of the ``public'' community in SNMP or that SNMP capable systems periodically send SNMP messages. Other drawbacks of existing mechanisms may include: they are complex, generate excessive traffic, and require every NMS to perform its own discovery. Requirements of a solution to this problem include: it should be reliable (discover every SNMP device), be simple, use small amount of network bandwidth, require a small amount of agent effort, should work regardless of powerup sequence, impose a low load on others and convey useful standardized information. The remainder of the BOF was given over to determining what problem the assembled company wanted to solve; this is a non-trivial problem in its own right. The discussion was as wide-ranging, and a number of quite divergent opinions were presented. It was generally felt that the problems of finding all SNMP capable systems, finding all SNMP/UDP/IP capable systems, and finding all systems that use the Internet were quite distinct and call for different solutions, and that finding all equipment attached to the Internet is not a solvable problem. After much discussion, it was concluded that the fundamental problem seeking solution borrowed components of each of these problems. Network Managers do in fact need to know what equipment is attached to their networks, and are helped by products which will perform this function. Products that do this utilize the RMON MIB, proprietary MIBs and algorithms, and scan such tables as the ARP cache and Routing cache. However, the problem of device discovery does not include a number of other functions (such as drawing a picture or matrix of Internet connectivity). These are ``next step'' processes which follow the discovery of the systems in the network. Given this much problem definition, the conclusion was reached that the RMON MIB could be extended to solve much of the discovery process. The reasons that it is inadequate now are: it is limited to finding systems attached to LANs, and it does not capture the protocol type or network layer protocol addresses that a device is using. As a result, the information captured about a system found by RMON, as it stands, cannot be used to perform the next step, that of pinging the device, especially if the device is separated from the NMS by a router. Therefore, the ultimate solution reached was to recommend that the RMON MIB be extended with a table containing, at minimum, the following information: deviceTable deviceEntry [deviceMacAddress, deviceProtocol] deviceMacAddress OCTET STRING deviceProtocol OCTET STRING or OBJECT IDENTIFIER deviceProtocolAddress OCTET STRING There may not be a protocol address for all protocols layered onto 3 the Data Link Layer, so the NMS must expect that deviceProtocolAddress may have a length of zero octets. A prototype MIB will be forwarded to Mike Ehrlinger of MTI for consideration by the RMON WG. Attendees Miriam Amos Nihart miriam@decwet.zso.dec.com Robert Austein sra@asylum.sf.ca.us Fred Baker fbaker@emerald.acc.com Steve Bostock steveb@novell.com David Bridgham dab@asylum.sf.ca.us Theodore Brunner tob@thumper.bellcore.com Jeffrey Buffum buffum@vos.stratus.com Lida Carrier lida@apple.com Jeffrey Case case@cs.utk.edu Richard Cherry rcherry@wc.novell.com James Codespote jpcodes@tycho.ncsc.mil Dave Cullerot cullerot@ctron.com James Davin jrd@ptt.lcs.mit.edu Jeff Erwin Bill Fardy fardy@ctron.com Shawn Gallagher gallagher@quiver.enet.dec.com William Jackson jackson@manta.nosc.mil Ron Jacoby rj@sgi.com Satish Joshi sjoshi@synoptics.com Scott Kaplan Frank Kastenholz kasten@europa.clearpoint.com David Kaufman Manu Kaycee kaycee@ctron.com Mark Kepke mak@cnd.hp.com Yoav Kluger ykluger@fibhaifa.com Stev Knowles stev@ftp.com Deidre Kostick dck2@sabre.bellcore.com Ron Lau Keith McCloghrie kzm@hls.com Evan McGinnis bem@3com.com David Minnich dwm@fibercom.com Michael Newell mnewell@nhqvax.hg.nasa.gov David Perkins dperkins@synoptics.com Radia Perlman perlman@radia.enet.dec.com Robert Purvy bpurvy@us.oracle.com Anil Rijsinghani anil@levers.enet.dec.com Michael Ritter mwritter@applelink.apple.com Jonathan Saperia saperia@tcpjon.enet.dec.com Mark Schaefer schaefer@davidsys.com John Seligson johns@ultra.com Timon Sloane peernet!timon@uunet.uu.net Ravi Srinivasan ravi@eng.vitalink.com Bob Stewart rlstewart@eng.xyplex.com Bruce Taber taber@interlan.com Iris Tal 437-3580@mcimail.com Mark Therieau markt@python.eng.microcom.com Dean Throop throop@dg-rtp.dg.com John Veizades veizades@apple.com Sudhanshu Verma verma@hpspdla.hp.com 4 Lee Wade wade@nsipo.arc.nasa.gov Steven Waldbusser waldbusser@andrew.cmu.edu Jeremy Wilson Junekang Yang natadm!yang@uunet.uu.net John Ziegler ziegler@artel.com 5