[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-ops-mumble-conf_management-02.txt
I see high value in reaching consensus on provisioning
requirements (for all approaches), but I'm unsure of the
risks of evaluating evolving approaches. cops-pr/pib needs
more work before evaluation as a solution. There
are still too many outstanding issues.
More references need to be identified in the draft, for
instance, qos pib and snmp extension approaches.
Could the goals of this draft be interpreted as:
(1) describe the process and issues of provisioning,
(2) define provisioning requirements, and then
(3) evaluate known methods for supporting provisioning
(stengths and weaknesses of current approaches).
Is this design team chartered to determine and recommend
whether cops-pr or snmp is the better approach? Or is
the goal simply to identify requirements for a policy
provisioning mechanism.
Another requirement is to support in-device, as well as,
proxy translators. Though, proxies move operators away
from focussing on network-wide policies versus the
diffent number and kinds of device-local configurations
for different devices. Proxy translators should be the
exception rather than the general rule for integrated
solutions. Further, regardless of in-device or proxy,
translation is between middle-level policies and
device-local configuration, and vice-versa. High level
policies should be in the language of the user/customer.
-----Original Message-----
From: Luis A. Sanchez [mailto:lsanchez@bbn.com]
Sent: Wednesday, October 13, 1999 6:48 PM
To: mumble@ops.ietf.org
Subject: draft-ops-mumble-conf_management-02.txt
Folks,
this is a first cut at the configuration management draft. It
includes background information, statement of the problem and
requirements. The document is _not_ finished _this_ is the first
cut. The text will evolve as we continue progressing towards our
goal. Please submit any comments to this list and/or to the
authors. Thanks!
Luis
***********
Internet Draft Keith McCloghrie, Cisco
draft-ops-mumble-conf_management-02.txt Luis Sanchez, BBN
Expires in Six Months Jon Saperia, Consultant
October 22, 1999
Evaluation of COPS/PIB and SNMP/MIB approaches for configuration
management of IP-based networks.
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
K. McCloghrie, L. Sanchez, J. Saperia [page 1]
Internet Draft October, 1999
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Motivation, Scope and Goals of this document . . . . . . . 2
1.2 Requirements Terminology . . . . . . . . . . . . . . . . . 3
1.3 Audience . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Definition of Technical Terms. . . . . . . . . . . . . . . 3
2. Statement of the Problem . . . . . . . . . . . . . . . . . . . 4
3. Requirements for an IP-based Configuration Management System . 7
K. McCloghrie, L. Sanchez, J. Saperia [page 2]
Internet Draft October, 1999
1. Introduction
1.1 Motivation, Scope and Goals of this document
Over the past months, a number of IETF working groups have
introduced new technologies which offer integrated and
differentiated services. To support these new technologies,
working group members found that they had new requirements for
configuration of these technologies. One of these new requirements
was for the provisioning (configuration) of behavior at the
network level.
An example of this type of configuration would be instructing all
routers in a network to provide 'gold' service to a particular set
of customers. Depending on the specific network equipment and
definition of 'gold' service, this configuration request might
translate to different configuration parameters on different
vendors equipment and many individual configuration commands at
the router. This higher level of configuration management has come
to commonly be known as policy based management.
Working groups associated with these new technologies believed
that the existing SNMP based management framework, while adequate
for fault, configuration management at the individual instance
(e.g., interface) level, performance and other management
functions commonly associated with it, was not able to meet these
new needs. As a result they began working on new solutions and
approaches.
COPS [COPS] for RSVP [RSVP] provides routers with the opportunity
to ask their Policy Server for an admit/reject decision for a
particular RSVP session. This model allows routers to outsource
their resource allocation decisions to some other entity. However,
this model does not work with DiffServ [DSARCH] where there is no
signalling protocol. Therefore, the policies that affect resource
allocation decisions must be provisioned to the routers. It became
evident that there was a need for cordinating both RSVP-based and
DiffServ-based policies to provide end2end QoS. Working groups
began to extend and leverage approaches such as COPS for RSVP to
support Diffserv policies. This gave birth to COPS-PR [COPS-PR].
These extensions caused concern that the IETF was about to develop
a set of fragmented solutions which were locally optimized for
specific technologies and not well integrated in the existing
Internet Management Framework. The concern prompted some of the
Area Directors associated with Operations and Management, the
Transport and General areas, and some IAB members to organize a
two day meeting in mid September 1999. The primary purpose of the
meeting was to examine the requirements for configuration
management and evaluate the COPS/PIB and SNMP/MIB approaches in
light of these requirements.
K. McCloghrie, L. Sanchez, J. Saperia [page 3]
Internet Draft October, 1999
By the end of the two day meeting there was no consensus on
several issues and as a result a number of 'design teams' were
created. This document is the output of the design team chartered
with the identification of a global set of configuration
management requirements and the further evaluation of the COPS/PIB
and SNMP/MIB based approaches with respect to these requirements.
In addition, the design team was chartered with investigation of
enhancements to both of these approaches and evaluation of the
costs associated with their development and deployment.
1.2 Requirements Terminology
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT"
and "MAY" that appear in this document are to be interpreted as
described in RFC 2119 [Bra97].
1.3 Audience
The target audience for this document includes system designers,
implementers of network configuration and management technology
and others interested in gaining a general background
understanding of the issues related to configuration management in
general, and in the Internet in particular along with associated
requirements. In addition, the audience are those people who wish
to gain additional information about how COPS-PR and SNMP have
been measured against those requirements. This document assumes
that the reader is familiar with the Internet Protocol, related
networking technology, and general network management terms and
concepts.
1.4 Definition of Technical Terms
Device-Local Configuration
Configuration data that is specific to a particular network
device. This is the finest level of granularity for configuring
network devices.
Network-Wide Configuration
Configuration data that is not specific to any particular network
device and from which two or more device-local configurations can
be derived. Network-wide configuration provides a level of
abstraction above device-local configurations.
Configuration Data Translator
A function that transforms Configuration Management Data
(high-level policies) or Network-wide configuration data
(middle-level policies) into device local configurations
(low-level policies) based on the generic capabilities of network
devices. This function can be performed either by devices
themselves or by some intermediate entity.
K. McCloghrie, L. Sanchez, J. Saperia [page 4]
Internet Draft October, 1999
2. Statement of the Problem
Configuring large networks is becoming an increasingly difficult
task. The problem intensifies as networks increase their size, not
only in terms of number of devices, but also with a greater
variety of devices, with each device having increasing
functionality and complexity. That is, networks are getting more
complex in multiple dimensions simultaneously (number of devices,
time scales for configuration, etc.) making the task of
configuring these just as complex.
Traditionally, configuring a network device has been a three step
process. First, the network operator, engineer or entity
responsible for the network creates a model of the network and its
expected behavior. This is formalized and recorded in the form of
high-level policies. These policies are then translated into
device-local configurations and provisioned into each network
device for enforcement. Any high-level policy changes ( changes in
the network topology and/or its expected behavior) need to be
translated and provisioned to all network devices affected by the
change. Figure 1 depicts this traditional model and shows how
high-level policies for a network are translated into four
device-local configurations. In this model, network operators or
engineers function as configuration data translators. Network
operators or engineers translate the high-level policies to
device-local configuration data.
A configuration data translator could take the topology
independent behavior description such as high-level policies
(first input source) combine it with topology information (second
input source) as well as status/performance/monitoring information
(third input source) to derive device-local configurations. Note
that there could be several configuration data translators
operating in tandem on a set of devices. However, there could be
only one configuration data translator operating at a particular
device at any given instance.
K. McCloghrie, L. Sanchez, J. Saperia [page 5]
Internet Draft October, 1999
Configuration Management
Data (High-level Policies)
|
|
|
|
Network V Network
Topology -----> Configuration <---- Status/performance
Information Data Translator(s) Information
|
|
|
|
-------------------------------------------------
| | | |
Device Device Device Device
Local Local Local Local
Conf(1) Conf(2) Conf(3) Conf(4)
Figure 1. Current model for configuring network devices.
Historically, network operators and engineers used protocols and
mechanisms such as SNMP and CLI applications to provision or
configure network devices. In their current versions, these
mechanisms have proven to be difficult to use because of their
low-level of granularity and their device-specific nature. This
problem is worse when provisioning multiple network devices
requiring large amounts of configuration data.
It is evident that network administrators and existing
configuration management software can not keep up with the growth
in complexity of networks and that an efficient, integrated
configuration management solution is needed. Several IETF Working
Groups working on this problem converged into adding a layer of
abstraction to the traditional configuration management process
described in figure 1. Figure 2 depicts this process. As in the
previous figure, first the network operator, engineer or entity
responsible for the network creates a model of the network and its
expected behavior. This is formalized and recorded in the form of
high-level policies.
K. McCloghrie, L. Sanchez, J. Saperia [page 6]
Internet Draft October, 1999
Configuration Management
Data (High-level Policies)
|
|
|
|
Network V Network
Topology -----> Network-Wide <---- Status/performance
Information Configuration Information
Data
|
|
|
|
V
Configuration
Data Translator(s)
|
|
|
|
-------------------------------------------------
| | | |
Device Device Device Device
Local Local Local Local
Conf(1) Conf(2) Conf(3) Conf(4)
Figure 2. Propose model for configuring network devices.
These policies are combined with topology information as well as
status/performance information to generate network-wide
configuration data. These middle level-policies are simpler to
manage and represent behaviors shared by multiple network devices.
Device local configurations are generated by automated
configuration data translators and supply to each network device
for enforcement. Note how this model only describes the function
of the configuration data translators and it does not dictate its
functional location. This is to say that translators may reside
outside of the devices (as it was the case in figure 1 since they
were humans) or may be collocated with each device if
necessary.
As in the previous model, any high-level policy changes (changes
in the network topology and/or its expected behavior) needs to be
propagated to all network devices affected by the change. However,
in the configuration model depeicted in figure 2 network operators
and engineers can specify the behavior of the network in a
simplified manner reducing the amount of device specific knowledge
needed.
K. McCloghrie, L. Sanchez, J. Saperia [page 7]
Internet Draft October, 1999
One should keep in mind that in some cases per instance device
local configuration is needed in network devices. An integrated
solution MUST allowed room for this. Also, the introduction of
automated configuration data translators assumes that all
information needed to make an error free conversion of
network-wide configuration data into device-local configuration
data is available. In the event that such data is not available
the solution MUST detect this and act accordingly.
3. Requirements for an IP-based Configuration Management System
A well defined and integrated management infrastructure is
essential to effective network operations. A management
environment which has non integrated components with overlapping
functions raises the cost of management.
The following requirements for configuration management will be
used in evaluating the cost effectiveness of the extension to SNMP
and/or the use of COPS-PR with modifications for configuration
management. An integrated configuration management solution MUST:
- provide means by which the behavior of the network can
be specified at a level of abstraction (network-wide
configuration) higher than a set of configuration
information specific to individual devices,
- be capable of translating network-wide configurations into
device-local configuration. The identification of the relevant
subset of the network-wide policies to be down-loaded is
according to the capabilities of each device,
- be capable to interpret device-local configuration, status and
monitoring information within the context of network-wide
configurations,
- be capable of provisioning (eg., adding, modifying, deleting,
dumping, restoring) complete or partial configuration data to
network devices,
- provide efficient means compare to today's mechanisms (CLI, SNMP)
to provision large amounts of configuration data,
- provide secure means to provision configuration
data. The system must provide provide support for access
control, authentication, integrity-checking, replay-
protection and/or privacy security services. The minimum
level of granularity for access control and authentication
is host based. The system SHOULD support user/role based
access control and authentication,
K. McCloghrie, L. Sanchez, J. Saperia [page 8]
Internet Draft October, 1999
- provide expiration time capabilities to configuration data. It
is required that some configuration data items be set to expire,
and other items be set to never expire,
- provide error detection (including data-specific errors) and
failure recovery mechanisms for the provisioning of
configuration data,
- eliminate the potential for mis-configuration occurring through
shared write access to the device's configuration data,
- provide facilities (with host and user-based authentication
granularity) to help in tracing back configuration changes,
- allow for the configuration of redundant components (both as
network elements and configuration application platforms). In
addition, the system should support the concept of individuals
(humans) in different roles with different access privileges,
- be flexible and extensible to accommodate for future
needs. Configuration management data models are not fixed for
all time and are subject to evolution like any other management
data model. It is therefore necessary to anticipate that changes
will be needed, but it is not possible to anticipate what those
changes might be. Such changes could be to the configuration
data model, supporting message types, data types, etc., and to
provide mechanisms that can deal with these changes effectively
without causing inter-operability problems or having to
replace/update large amounts of fielded networking devices,
- leverage of the existing SNMP management infrastructure where
possible. The system MUST leverage knowledge of and experience
with MIBs and SMI.
4. Evaluation ...
References
[Bra97] Bradner, S., "Key Words for use in RFCs to indicate
Requirement Levels", RFC2119, March 1997.
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R.,
and A. Sastry, "The COPS (Common Open Policy Service) Protocol",
draft- ietf-rap-cops-07.txt, work-in-progress, August 1999.
[RSVP] Braden, R. ed. et al., "Resource ReSerVation Protocol
(RSVP) Version 1 - Functional Specification", RFC 2205, September
1997.
[COPS-PROV] Reichmeyer, F., Herzog, S., Chan, K., Durham, D.,
Yavatkar, R., Gai, S., McCloghrie, K., and A. Smith, "COPS Usage
for Policy Provisioning", draft-ietf-rap-pr-00.txt,
work-in-progress, June 1999.
K. McCloghrie, L. Sanchez, J. Saperia [page 9]
Internet Draft October, 1999
Disclaimer
The views and specification here are those of the authors and are
not necessarily those of their employers. The authors and their
employers specifically disclaim responsibility for any problems
arising from correct or incorrect implementation or use of this
specification.
Copyright (C) The Internet Society (November 1997). All
Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English. The limited permissions granted above
are perpetual and will not be revoked by the Internet Society or
its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Author Information
Keith McCloghrie Jon Saperia
Cisco Systems, Inc. Independent Consultant
170 West Tasman Drive 174 Chapman Street
San Jose, CA 95134-1706 Watertown, MA 02472
USA USA
Email: kzm@cisco.com" Email: saperia@mediaone.net
Phone: 408-526-5260 Telephone: +1 (617) 744-1079
Luis A. Sanchez
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
USA
Email: lsanchez@bbn.com
Telephone: +1 (617) 873-3351
K. McCloghrie, L. Sanchez, J. Saperia [page 10]