LYNCH@A.ISI.EDU (Dan Lynch) (11/24/87)
To facilitate information spread on some current network management protocol developments, I am forwarding this set of "minutes" of a recent meeting. Dan *********** Vendors Position Statement on TCP/IP Network Management Standards Working Document - 11/20/87 A lot of email has been exchanged recently, speculating on the TCP/IP network vendors intentions with respect to Network Management standards. It is time for the vendors themselves to explain their position on this topic. On 11/4/87, a group of vendors actively involved with the effort of the Network Management Working Group of the IETF met for the purpose of: 1) assessing the current status of the network management standards efforts with respect to the goals that they had agreed to in May 1987. 2) discussing plans to implement the proposed standards and incorporate them in vendor products. 3) discussing plans to demonstrate interoperability of network management among vendor products. The participants to the meeting included the following vendors: Bridge Communications CMC Data General Excelan Hewlett-Packard Sun Microsystems Sytek 3Com Ungermann-Bass These participants represent a substantial and representative subset of the TCP/IP vendor community at large and are collectively referred to as "the vendors" in the rest of this document. In the course of the discussion on the agenda items listed above, a consensus was reached on five major points: 1) The vendors cannot endorse or implement the recently circulated RFCs describing the HEMS system in their current form for the following reasons: - The HEMS approach does not satisfy a key goal of the Network Management Working Group goals statement [1] which is to provide a "clear migration path to OSI network management." - The services definition RFC [2] authored by Lee Lebarre is a major element in the strategy of providing a clear migration path to OSI and protecting major network management application investments. The ability to deliver these services is a key requirement for choosing a management protocol. The HEMP/Query protocols do not provide this capability while CMIP does. - While the HEMS project provides significant insight into the technical issues of TCP/IP network management, it has not been driven by the same charter as the vendors adopted for the Network Management Group [1]. The requirements for delivering early implementations of HEMS for the gateway monitoring needs of the NSFNet have made discussions and compromises very difficult, and have prevented the HEMS developers from taking into account the vendors key technical concerns and strategic requirement. 2) The vendors continue to treat the Network Management Working Group Goals and Scope document [1] as their common objective statement. In particular, they recognize that the transition from TCP/IP to OSI is inevitable. 3) The vendors agree that the Service Definition RFC BBBB [1] and the HEMS definition of the Management Information can be used as a solid working base on which to build a network managment system for TCP/IP environments. 4) The vendors favor a network management standard approach based upon the CMIP/TCP/IP stack which meets the overall objective of easing the migration to the OSI environment. In particular, it preserves the vendors investment in network management applications and makes the management of hybrid (TCP/IP and OSI) networks significantly easier. They intend to submit concrete proposals to substantiate this approach to the IETF. Alternatively, the vendors would also agree to consider enhancements to HEMP that preserve the integrity of the Management Services interface as defined by RFC BBBB. 5) The vendors remain committed to completing the development of TCP/IP network management standards in an aggressive time frame and take as a goal to demonstrate interoperability of network management in the fall of 1988. In summary, a strong consensus has emerged in the vendor community in favor of a CMIS-based approach. While the quality of the work produced for HEMS is not in question, the vendors are driven by different motivations. They are ultimately responsible for investing considerable development resources to engineer the network management products that will truly create the standard. In network management as well as other areas, the vendors must make choices that maximaze their return on investment of development resources over time. They intend to work within the Network Management Working Group structure of the IETF to pursue these goals. References: [1] TCP/IP Network Management Working Group: Goals and Scope - Revision 3 - 6/18/87 [2] RFC BBBB: Management Services for TCP/IP Network Management, Lee Labarre - 10/87 -------
trewitt@MIASMA.STANFORD.EDU (Glenn Trewitt) (11/24/87)
[Sorry about the long note, but I've been waiting to hear a statement from the NetMan vendors subgroup to hear just what it is that's going on. Now I've heard, so now I have something to comment on.] Fascinating. All of this talk about what CMIP privides. When listening to the two main proponents of CMIP in the Network Management meetings (up until the last one, of course, which I did not attend), I have heard a lot of statements about what "CMIP Provides". Yet the proposals about what CMIP is to do are constantly changing. At the last meeting in Tokyo, where CMIP was to be voted up from its current "Draft Proposal" status, it was rejected. My understanding is that this was the second time it was rejected, and that there is considerable dissent about just what CMIP will do, and how will it do it. Nowhere else but at the NetMan meetings have I heard such definite statements about what CMIP "is" and "does" and "provides". In talking to some people at Sydney University, I heard estimates of 3-4 years until the ISO monitoring effort produces anything concrete. Surely they aren't TCP/IP lackeys? I do know them to be very practical, however. While I understand the vendors' concerns, I don't agree with the way these concerns color their outlook on ISO migration and short- to medium-term managment solutions. The only thing that ISO management offers that is not included in monitoring proposals such as HEMS or SGMP is an overall architectural definition. This architecture defines the framework that monitoring protocols (such as CMIP or HEMP) operate within. There is no reason that HEMS can't fit into the ISO framework. Many hours were spent discussing how that could be done. Some members of the committee refused to accept the notion that HEMS could conform to the architecture, even though the protocol looks quite different than CMIP. Or, I should say, "what CMIP currently looks like". Architecture aside, the two protocols provide similar services (HEMS offers some not in CMIS). Both will require two major implementation efforts, and each of these efforts will require far more effort than the implementation of HEMS, and probably even more than CMIP. 1) Servers for extracting data from protocol implementations (kernel data structures, etc). Interfaces between protocol modules and the server will be at a very low level and likely will be peculiar to the OS primitives available. There is far more dependency upon environment here than upon the querying mechanism (HEMP or CMIP). 2) Application programs for manipulating this virtual data base. These include programs to keep track of what's going on in the network, systems to produce coherent summaries of network activity from many points of view, specialized "assistants" to help ferret out problems, and finally, programs to do high-level control operations, rather than mucking around down in the dirt. None of these applications depends in the slightest upon the underlying monitoring protocol, except at the very lowest subroutine call level. This is all a lot of work, and it completely overshadows the cost of implementing either of these protocols, much less migrating from one to the other. But there is one difference between the two systems. HEMS is specified now, and CMIS isn't. Plus, CMIS may not be recognizable as CMIS by the time it is nailed down. Defining a network management on the basis of a protocol that changes several times a year simply means that the Network Management WG will end up defining yet another protocol, something that was NOT in its original charter. Please note that I have not touched upon the technical merits (or lack thereof) of either system. As one of the authors of HEMS, I am quite biased about which one I prefer. I do, however, feel that the decisions that Craig and I made in designing HEMS have been validated by Craig's implementation experience. This is something that can't be said of CMIS, which is strictly a paper design right now. If anybody is interested in a discussion of the technical aspects of the two systems, I would be happy to oblige. Another issue I would like to see explored is the apparent domination of the Network Management WG by the "vendors", to the exclusion of the "non-vendors". My impression is that there is a lot of writing going on right now, none of which I am seeing discussed in the open forums available for it (such as netman@amadeus or gwmon@sh.cs.net). I never heard a word about the meeting, except second hand, by accident. What I did hear is that it specifically excluded non-vendors. Now, I suppose that it's fine for vendors to share their concerns with each other, but it seems like a rather dramatic change of course happened at that meeting. Several of the people in attendance had never attended a NetMan meeting before, and several people (including myself) who had attended the meetings from the beginning were excluded. Since when have vendors been in charge of (pre-)defining Internet standards? - Glenn Trewitt P.S. I'll probably regret this in the morning. :-)
rcallon@PARK-STREET.BBN.COM (Ross Callon) (11/24/87)
The goal of a protocol which can be implemented in a reasonably short time frame (one of the goals of HEMS) seems inconsistent with the goal of being consistent with ISO network management protocols. If you want to be consistent with the ISO protocols, then you should wait until they are done. If you want something now (or within 6 months), then you are going to have to use something that is available now (or can be developed in 6 months). I don't understand why it is useful to have something which is sort of vaguely like what we think CMIP is going to look like when it is done. Either you are compatible with an ISO standard or you're not. Being sort of close doesn't seem to buy all that much. (This assumes that it is not possible to get "close enough" to interoperate with the eventual ISO International Standard without changes, which I think is a fairly safe assumption). I think it would be easier to implement HEMS (or SGMP or HMP), and accept that we will need to change at some time in the future, than to argue at great length as to how to define a protocol which resembles CMIP as much as possible, which will still need to be implemented and then changed at some time in the future. There is a lot of talk about being protocol consistent, but relatively little about other aspects of building a network management system. A network management system which want to manage multiple vendor's equipment in an Internet is going to have to speak more than one network management protocol whether you like it or not. If the slowness of ISO doesn't assure this, then the large amount of existing equipment and/or IBM is going to assure it instead. What is more difficult is to deal with incompatible data sets returned from different devices, inconsistencies in the way that the database is stored in different network management systems, etc. Thus if you are worried about the eventual transition from TCP/IP to ISO, you should, for example, be worried about the differences between the set of network management metrics defined by HEMS and that being worked on for gateways in ANSI X3S33, and you should think about what you intend to do with either set of data when you get it into your system. [Note: My reference to the slowness of ISO should NOT in any way be interpreted as a complaint. The process of developing an international standard is of necessity a very slow and laborious process. The complexity of network management make the CMIP development even harder. However, we have to accept that this process is not likely to speed up.] Ross
hedrick@ARAMIS.RUTGERS.EDU (Charles Hedrick) (11/25/87)
My concern is rather the opposite of the others that I have heard. I am concerned that participants in the closed Netman meeting have made a decision which, although plausible, will have no effect other than excluding them from the IP community. It is clear that HEMS and SGMP will be implemented by the major gateway vendors, and on Unix. (I wish we could pick one or the other, but I have a feeling we will end up with both HEMS and SGMP everywhere.) This will happen by January. The hope had been that we could avoid completely separate IP and ISO implementations by the work of the Netman group. If this has really failed, the result will be separate IP and ISO work, not CMIS over IP. Experience is very clear that a few months delay in this business is fatal. It is probably not too late to make extensions to HEMS if necessary to allow the Netman group to meet its goals. In my view it is too late to come up with another protocol. I am hoping that all of the participants in Netman can somehow be persuaded to try again. I think we need to find a way to make things proceed according to the original gameplan. In this context it is important to avoid seeing the issue as somehow "the vendors" against the IP community. Not all vendors were present at the meeting. Indeed the purveyors of the major gateway implementations were noticable by their absence. So I'd like to see us avoid using "the vendors" as if there were one such entity, and they all adopted the same position. I am in fact avoiding assigning any term to those who participated in the meeting in question, since I am unable to find any term that is not emotionally loaded.
LYNCH@A.ISI.EDU.UUCP (11/25/87)
Charles, Thank you for clearly stating your views. I agree that any path is going to take a lot of work. It would be best if we all could get on with the "work" to be done. The characterization of the vendors who are favoring the CMIS approach is best described as "end system vendors" as opposed to "gateway vendors". They see their customers as drowning in network "administration" details in addition to netowrk "management" details. A few years back you (and I) were running timesharing systems and we did that with a ton of software and human procedures that were tightly integrated (evefn if by dint of hard work and numerous kludges that remained invisible to our customers). The joy of networking has stripped managers of that tight integration of administrative tools. Dealing with routing protocol misbehaviour is only the tip of the iceberg (even if that tip will still sink the largest ship someday). So, end users need to have their entire "computing facilities" managed. I think that is what this group of vendors is wrestling with. I hope all parties can find a way to combine efforts for the benefit of all users. After all, satisfied users are the lifeblood of us all. Dan -------
gross@gateway.mitre.ORG (Phill Gross) (11/26/87)
> I don't understand why it is useful to have something which is sort > of vaguely like what we think CMIP is going to look like when it is > done. Either you are compatible with an ISO standard or you're not. > Being sort of close doesn't seem to buy all that much. Ross, I have been informed in private that these days it is a wise business decision to at least give the appearance of conforming to OSI standards. Utilizing TCP and IP is fine because it is already here, but for something that needs to implemented from scratch, I've been told that many vendors feel contrained to an OSI solution. The argument about avoiding development costs by not implementing twice may not be as important as soothing nervous customers about multi-vendor OSI interoperability. If vendors were only concerned with not implementing twice, they might have taken a harder look at the Simple Gateway Monitoring Protocol (SGMP) effort. SGMP is yet a third network management consortium effort that started about the same time as (and has drawn from) HEMS and Netman. At the Boulder IETF meeting, a very impressive real-time demo was given of a PC based SGMP package (with whizbang color graphics) monitoring a real state-wide regional network. My understanding is that C source code is available for tested, interoperable implementations under BSD Unix, MS-DOS and two other platforms. SGMP has been documented in a recent RFC and I think there are plans for it be discussed at the upcoming Interoperability conference. For vendors whose goal is to minimize development costs, perhaps SGMP deserves a closer look. Phill Gross
louie@TRANTOR.UMD.EDU ("Louis A. Mamakos") (11/27/87)
Date: Wed, 25 Nov 87 18:09:37 EST From: gross@gateway.mitre.org (Phill Gross) Message-Id: <8711252309.AA05871@gateway.mitre.org> Subject: re: Network Management > I don't understand why it is useful to have something which is sort > of vaguely like what we think CMIP is going to look like when it is > done. Either you are compatible with an ISO standard or you're not. > Being sort of close doesn't seem to buy all that much. Ross, I have been informed in private that these days it is a wise business decision to at least give the appearance of conforming to OSI standards. Utilizing TCP and IP is fine because it is already here, but for something that needs to implemented from scratch, I've been told that many vendors feel contrained to an OSI solution. The argument about avoiding development costs by not implementing twice may not be as important as soothing nervous customers about multi-vendor OSI interoperability. If vendors were only concerned with not implementing twice, they might have taken a harder look at the Simple Gateway Monitoring Protocol (SGMP) effort. As a customer of network products, I'm not interested in the "appearance" of a product in anyway; just what it does. It seems that products developed to "soothe" customers and as useful as those developed to actually solve my problems. I was kinda glad that the vendors I buy products from weren't listed as being part of the group that made this decision. If I can't buy it, I'll have to build it myself. The vendor that builds it for me gets my business. The appearence of ISO compatibility is not something that I'd go out and build. Just wanted to give you another "customer's" perspective. Louis A. Mamakos University of Maryland Computer Science Center
jon@CS.UCL.AC.UK (Jon Crowcroft) (05/30/88)
A couple of weeks ago i sent a message to this list asking about management tools for TCP/IP type networks. One ground rule was the public availability of said tools (i.e. exclude expensive things, but include things at least binary avail like tcpdump). The categories for tools of interest were: configuration e.g. gated/rip/egp/routed - routes bind - names rdist - info distrib. info-servers - distr. info db - ucl distr. account management thorn ds - a nearly real X.500 (but over TCP as well as OSI) directory service fault finding/performance ping - liveness/reachability/errors ttcp - udp/tcp traffic gen. etherfind/tcpdump - protocol behaviour - intruder detection... statistics NSStat - overall net stats probe - ucl icmp based reachability prog. flakeway - ucl PC based fake arpanet map - UCL traffic analyser helps decide where to partition your LAN So far i've had 6 replies saying "gosh that would be a very useful list of info. to collate" and 0 replies saying, "heres a really neat program for doing everything and it runs on anything bigger than a pocket calculator, speaks LAT, X.25, can parse ASN.1 and pretty print an X.400 header. it also makes excuses for..." can anyone help... jon
keyles@rubbs.FIDONET.ORG (Michael Keyles) (02/10/89)
Hi, Does anyone have a pointer to a SNMP package for a Sun and/or an RT? My firm is starting to have several machines that produce snmp stats, but we have no way of looking at it. Thanks. Mike -- Michael Keyles - via FidoNet node 1:107/520 UUCP: ...!rutgers!rubbs!keyles ARPA: keyles@rubbs.FIDONET.ORG
kzm@TWG.COM (Keith McCloghrie) (02/14/89)
Mike & Dave, You both asked about the availability of a Network Management station supporting SNMP on a Sun workstation. We have such a product. We also have SNMP agent software to go with our TCP/IP products for VMS and 386/Streams. If you would like more information, let me know. Keith McCloghrie The Wollongong Group.
erik@yarra.oz.au (Erik Lecis) (03/08/91)
Hi!
Does anyone have any opinions re: lan management packages?
I am currently investigating SG's Netvisualyzer, HP's LanProbe and
Sun's SunNet (I am particularly interested in Sun based offerings as the
site has a large investment in their workstations).
I will summarize responses.
Tx.
--
-m------- Erik Lecis - Systems Engineer E-mail: erik@yarra.oz.au
---mmm----- Pyramid Technology Corporation Pty Ltd
-----mmmmm--- 1st Floor, 553 St. Kilda Road,
-------mmmmmmm- Melbourne, Victoria 3000, AUSTRALIA tel: +61 3 521 3799willis@cs.tamu.edu (Willis Marti) (03/08/91)
"Hi! Does anyone have any opinions re: lan management packages?" We have HP's LanProbe, which uses a specialized hardware box to gather data and a PCompatible running Windows (ugh) to display info & command the box. Connections can be direct (9600baud), over the same ethernet you're monitoring or thru a builtin 2400 baud modem. I love it for monitoring lower level performance, and for being able to do some fancy packet tracing AT THE SAME TIME! So you can be monitoring netowrk 'health' and debugging somebody's router problems... Lots of other neat features... We've used SGI's Netvisualyzer and, IMO, it's a different kind of beast. More like the next level up in terms of the picture you see. I also believe that you can't count on seeing *every* packet with a general purpose workstation. So decide on what level of net mgmt you want. ------------------------------------------------------------------------------- Willis F. Marti Internet: willis@cs.tamu.edu Director, Computer Services Group, Dept of Computer Science, Texas A&M Univ. ---Not an official document of Texas A&M---
nrm1838@dsacg3.dsac.dla.mil (James D. Cassell) (04/12/91)
We are interested in anyone's experience in managing large router networks.
Our network currently consists of 23 routers (cisco) connecting large
(600+ hosts) LANs. The router network will be expanded to bring in
another 250-350 LANs (mostly much smaller LANS than are now on the
network).
We currently have no network management hardware or software (for the
WAN stuff). We have looked at cisco's NetCentral Station, but have
heard mixed reviews of this product from other users (too slow, can't
handle very large networks, etc.).
Any information, experiences, war stories, etc. will be greatly
appreciated. We have our hands full managing the current 23 routers,
I can't immagine 400 of them!
Thanks,
Jim
--
Jim Cassell | jcassell@dsac.dla.mil
DSAC-RMB, P.O. Box 1605 | 614-238-9971
Columbus, Ohio 43216 | Input standard disclaimer here ...