Hi folks,
This short document is, in my humble opinion, an excellent
source for our requirements for PWG WBMM schemas, protocols,
and management functionality:
ftp://ftp.isi.edu/in-notes/rfc3535.txt
The "network operators" surveyed in RFC 3535 are ISPs (Internet
Service Providers), but their needs are very similar to third-
party service providers for enterprise network mgmt.
For a list of the positive and negative aspects of half-dozen
current network management protocols (some proprietary), see
section 2 "Network Management Technologies" (first paragraph
appended below).
Noteworthy is section 3 "Operator Requirements" (appended below).
I suggest we review these requirements in the WBMM context. I
believe that _most_ of them are highly relevant.
Cheers,
- Ira McDonald
High North Inc
-----------------------------------------------------------------------
[excerpts from RFC 3535]
Abstract
This document provides an overview of a workshop held by the Internet
Architecture Board (IAB) on Network Management. The workshop was
hosted by CNRI in Reston, VA, USA on June 4 thru June 6, 2002. The
goal of the workshop was to continue the important dialog started
between network operators and protocol developers, and to guide the
IETFs focus on future work regarding network management. This report
summarizes the discussions and lists the conclusions and
recommendations to the Internet Engineering Task Force (IETF)
community.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Network Management Technologies . . . . . . . . . . . . . . . 3
2.1 SNMP / SMI / MIBs . . . . . . . . . . . . . . . . . . . 4
2.2 COPS-PR / SPPI / PIBs . . . . . . . . . . . . . . . . . 5
2.3 CIM / MOF / UML / PCIM . . . . . . . . . . . . . . . . . 6
2.4 CLI / TELNET / SSH . . . . . . . . . . . . . . . . . . . 7
2.5 HTTP / HTML . . . . . . . . . . . . . . . . . . . . . . 8
2.6 XML . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Operator Requirements . . . . . . . . . . . . . . . . . . . . 10
4. SNMP Framework Discussions . . . . . . . . . . . . . . . . . . 12
5. Consolidated Observations . . . . . . . . . . . . . . . . . . 14
6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
Normative References . . . . . . . . . . . . . . . . . . . . . . 18
Informative References . . . . . . . . . . . . . . . . . . . . . 18
Appendix - Participants . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 20
<...>
2. Network Management Technologies
During the breakout sessions, the protocol developers assembled a
list of the various network management technologies that are
available or under active development. For each technology, a list
of strong (+) and weak (-) points were identified. There are also
some characteristics which appear to be neutral (o).
The list does not attempt to be complete. Focus was given to IETF
specific technologies (SNMP, COPS-PR, PCIM) and widely used
proprietary technologies (CLI, HTTP/HTML, XML). The existence of
other generic management technologies (such as TL1, CORBA, CMIP/GDMO,
TMN) or specific management technologies for specific problem domains
(such as RADIUS, DHCP, BGP, OSPF) were acknowledged, but were not the
focus of discussion.
<...>
3. Operator Requirements
During the breakout session, the operators were asked to identify
needs that have not been sufficiently addressed. The results
produced during the breakout session were later discussed and
resulted in the following list of operator requirements.
1. Ease of use is a key requirement for any network management
technology from the operators point of view.
2. It is necessary to make a clear distinction between configuration
data, data that describes operational state and statistics. Some
devices make it very hard to determine which parameters were
administratively configured and which were obtained via other
mechanisms such as routing protocols.
3. It is required to be able to fetch separately configuration data,
operational state data, and statistics from devices, and to be
able to compare these between devices.
4. It is necessary to enable operators to concentrate on the
configuration of the network as a whole rather than individual
devices.
5. Support for configuration transactions across a number of devices
would significantly simplify network configuration management.
6. Given configuration A and configuration B, it should be possible
to generate the operations necessary to get from A to B with
minimal state changes and effects on network and systems. It is
important to minimize the impact caused by configuration changes.
7. A mechanism to dump and restore configurations is a primitive
operation needed by operators. Standards for pulling and pushing
configurations from/to devices are desirable.
8. It must be easy to do consistency checks of configurations over
time and between the ends of a link in order to determine the
changes between two configurations and whether those
configurations are consistent.
9. Network wide configurations are typically stored in central
master databases and transformed into formats that can be pushed
to devices, either by generating sequences of CLI commands or
complete configuration files that are pushed to devices. There
is no common database schema for network configuration, although
the models used by various operators are probably very similar.
It is desirable to extract, document, and standardize the common
parts of these network wide configuration database schemas.
10. It is highly desirable that text processing tools such as diff,
and version management tools such as RCS or CVS, can be used to
process configurations, which implies that devices should not
arbitrarily reorder data such as access control lists.
11. The granularity of access control needed on management interfaces
needs to match operational needs. Typical requirements are a
role-based access control model and the principle of least
privilege, where a user can be given only the minimum access
necessary to perform a required task.
12. It must be possible to do consistency checks of access control
lists across devices.
13. It is important to distinguish between the distribution of
configurations and the activation of a certain configuration.
Devices should be able to hold multiple configurations.
14. SNMP access control is data-oriented, while CLI access control is
usually command (task) oriented. Depending on the management
function, sometimes data-oriented or task-oriented access control
makes more sense. As such, it is a requirement to support both
data-oriented and task-oriented access control.
This archive was generated by hypermail 2b29 : Mon Jun 23 2003 - 12:30:00 EDT