Network Working Group J. Saperia
Internet-Draft IronBridge Networks
Expires March 2000 J. Schoenwaelder
TU Braunschweig
14. September 1999
Policy-Based Enhancements to the SNMP Framework
<draft-schoenw-policy-snmp-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. 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
Distribution of this document is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This memo takes a look at some of the work on policy-driven networks
currently being done in several IETF working groups. The proposed
solutions (like COPS and PIBs) focus on solving local problems of
policy management. It is the view of the authors that while local
solutions like COPS can be more effective than more general ones, the
advantages to effective management through the use of a single
integrated management framework (an improved SNMP) outweigh the gains
of locally optimized solutions.
Saperia & Schoenwaelder [Page 1]
Internet-Draft Policy-Based SNMP Enhancements September 1999
Table of Contents
1 Introduction ................................................. 3
2 Background ................................................... 3
3 Statement of the Problem - Need for Integrated Management .... 4
4 Requirements ................................................. 4
4.1 Multiple Management Stations ............................... 4
4.2 Multiple Users in Multiple Roles ........................... 5
4.3 Connection-oriented and Connection-less Management ......... 5
4.4 Hierarchically Managed Networks/Overlapping Domains ........ 5
Integration ............................................... 6
4.6 Compatibility with SNMP Management Data .................... 6
4.7 Multiple Configurations and Switching Configurations ....... 6
4.8 Evolution of Configuration Management Data ................. 7
5 Issues with COPS/PIB Approach ................................ 7
5.1 Incomplete SoPI Definition ................................. 7
5.2 PIB Instance Identification ................................ 8
5.3 Missing Contexts ........................................... 8
5.4 Evolution of PIBs .......................................... 8
5.5 Configuration Management for exisiting MIBs ................ 9
5.6 Manual Translations between PIBs and MIBs .................. 9
6 Possible Changes to SNMP ..................................... 9
6.1 SMIv2 Extensions to Define Operations ...................... 9
6.2 SNMP Transaction Support ................................... 10
6.3 Transport over TCP ......................................... 10
6.4 Additional Protocol Operations ............................. 10
6.5 Efficiency Improvements .................................... 11
7 Comments on draft-kzm-policy-protocomp-00.txt ................ 11
7.1 Section 3.3 Exclusive Access by the PDP .................... 11
7.2 Section 3.5 COPS Takes Advantage of TCP .................... 11
7.3 Section 3.7 COPS over TCP (Revisited) ...................... 14
7.4 Section 3.8 Modifying Message Formats ...................... 14
7.5 Section 3.9 Initiation by the PEP .......................... 15
7.6 Section 3.10 Deleting Policy ............................... 15
7.7 Additional Sections ........................................ 16
8 Conclusions .................................................. 17
9 Suggested Plan of Action ..................................... 18
10 References .................................................. 19
11 Authors' Address ............................................ 20
Saperia & Schoenwaelder [Page 2]
Internet-Draft Policy-Based SNMP Enhancements September 1999
1. Introduction
With the addition of Differentiated Services and other technologies,
the need for policy based management has grown. A number of working
groups including the Policy Framework and Resource Allocation
Protocol working groups needed support for the configuration of
policy in the network. SNMP was evaluated by these working groups and
in some cases and found lacking in a number of areas. As a result,
new work was undertaken which led to COPS and PIBs among other
things. These solutions focused on solving the local problems of
policy management.
This document was prepared for a meeting involving some of the
involved area directors and working group participants scheduled to
take place in mid September 1999. The purpose of the meeting is to
help the Area Directors gather information about the various
proposals and the needs that they are to address. In addition, these
needs will be evaluated against the features available in SNMP. This
document has an additional purpose in addition to preparation for the
meeting. It is background for a proposal to integrate the best
features of COPS/PIBs and the best features of SNMP that is hoped
will evolve from the Chicago meeting. Local solutions like COPS can
be, if properly specified and implemented, more effective than
general ones. However, the advantages to effective management through
the use of a single integrated management framework (e.g., an
improved SNMP) far outweigh the gains of locally optimized solutions.
2. Background
Over the years SNMP has evolved and most recently has undergone the
addition of improved security and refinement of the specifications.
In many important areas, such as the ability to retrieve large
amounts of data and support complex configuration operations, many
people felt that SNMP did not provide adequate solutions.
Given this view, people sought other solutions to fill in the gaps
(real or perceived) that existed in SNMP.
The solutions range from formal protocol proposal like COPS to
informal and proprietary solutions offered by vendors or implemented
by network operations staffs. The result is a management environment
which is fragmented. SNMP has been dominant in the areas of network
status monitoring and statistics gathering, but has not been widely
used for configuration management. This fundamental split makes
problem resolution more costly and difficult.
The original focus of this draft was to have been cross referencing
on how SNMP can meet the stated needs of the community. In the view
of the authors, SNMP does need some enhancements in order to be
Saperia & Schoenwaelder [Page 3]
Internet-Draft Policy-Based SNMP Enhancements September 1999
effective in the policy area. These enhancements are not driven only
by policy requirements since they can benefit all areas of
management. We are advocates for effective management - not for a
particular protocol. We felt that a good approach would be to work
with the community to develop a clearly articulated list of
requirements (which should not be to difficult), evaluate some of the
principles that have been developed for COPS etc. and create a list
of additions needed for SNMP. This is based on the belief that the
Internet needs an integrated management approach to deal with the
challenges of the coming years.
3. Statement of the Problem - Need for Integrated Management
It is a strongly held view by many that when configuration
information (policy provisioning data is just one kind of
configuration data) is in a different form than fault and other types
of data, that management becomes more difficult. Imagine a network
operator tasked with relating the failure of an interface which is
the backup interface (in a sonet APS sense) to an SLA if the SLA has
been expressed in a form which makes it difficult to associate the
failed component. This can only be done when instance level
information is known. This is not a dismissal of the powerful
concept of classes found in the various framework and schema
documents that have been published over the past few months. To the
contrary, the concepts can be well used to augment the existing
management framework. Using this approach a more integrated method
of management can be achieved.
4. Requirements
For effective management to take place, there are a number of
requirements relevant to the current discussion which can not be
ignored. Below are some of the areas which any policy management
paradigm must address to successfully integrate into currently
deployed Internet management environment.
4.1. Multiple Management Stations
Multiple management systems exist today for concurrent access to
managed elements for a wide variety of reasons. In modern networks
service and performance interruptions must be kept to a minimum -
this applies to the management infrastructure as well. As a result,
multiple standby management components are often on hot stand-by and
in full sync with their primary counterparts to avoid extra delay for
connection re-establishment in the case of failure. These standby
components are often geographically dispersed.
Saperia & Schoenwaelder [Page 4]
Internet-Draft Policy-Based SNMP Enhancements September 1999
Beyond the basic issues of multiple redundant components, multiple
management systems may need to be in communication with managed
devices (often concurrently) for other reasons. In some cases,
different organizations within the management community perform
different configuration functions (e.g., routing, versus provisioning
of the hardware). These different aspects are often related to
policy.
4.2. Multiple Users in Multiple Roles
From the previous item, it should be clear that multiple users must
have access to a single system - often concurrently. What is also
true is that not all management personnel are given the same
privileges with respect to access to information. Some people are
allowed only read access to certain configuration information while
others are permitted to have full access to a wider range of
management objects inside the network elements. A restricted few
have wide and full access. Even in these cases, there may be some
systems within a particular administrative domain that have even more
restrictive access. Policy/Configuration information is sensitive and
management operations staffs require flexibility in the permissions
given people in different roles.
4.3. Connection-oriented and Connection-less Management
A great deal has been written and tried over time for management with
connection-oriented and connection-less approaches. What may be
needed is a combination of the two since neither one meets all types
of requirements. Connection-less polling for short term information
is far less costly than maintaining many (potentially thousands) of
connections for the collection of this type of data - connection-
oriented management systems have always been problematic with regard
to scale. Status polling for certain types of information also has
some scale problems, so asynchronous notification is a viable
scalable alternative.
Connection-oriented management for the retrieval of large amounts of
data or the transmission of complex configuration information has
proved to be of great value over time.
4.4. Hierarchically Managed Networks/Overlapping Domains
Networks of size must provide for some level of hierarchical
management and overlapping management domains. Often management has
a functional flavor where the WAN folks deal with part of the net,
and the local people deal with another part of the network. To some
extent, even in the policy area there will be overlap. Imagine an
Saperia & Schoenwaelder [Page 5]
Internet-Draft Policy-Based SNMP Enhancements September 1999
edge device which is subject to the policies of multiple
administrative domains. Hierarchy is not always exactly straight up
and down and it is often the case that policy does not have clean
boundaries and systems must to some degree have multiple masters.
4.5. Policy and Instance Specific Information - Required Integration
The idea of saving data transfer to the PEP by avoiding the
granularity of instance level data is a helpful concept. There is
often some configuration information that is required on a per
instance basis. A good example would be the IP address of an
interface. It is essential that these two types of information,
general policy rules/roles and specific instance related information
be well connected otherwise detecting and correcting configuration
errors will be more difficult.
One of the side effects of requiring the PEP to convert to instance
level data is that while the transmission of the data to the machine
would be less resource intensive than if SNMP based instance level
data were sent, there will be considerable additional processing
needed to make the conversion. In addition it will require a global
knowledge of the system and 'smarts' to make the conversion that are
not currently available in many systems. Please also see next point.
4.6. Compatibility with SNMP Management Data
If a card or some other hardware or software component fails, it is
important to tie this to the SLA or SLAs that are in jeopardy. In
large systems especially this will require the tight integration of
the information described in the various policy documents with other
standard information. The failure will always be expressed in terms
of instance specific information. In fact only by evaluation of the
instance specific information can a determination be made about the
impact to an SLA.
Similarly, data about the utilization of various resources in the
network is necessarily collected via SNMP based mechanisms. It will
be impossible to make good policy decisions without this information.
The conversion of this (SNMP) data to another format could be costly.
4.7. Multiple Configurations and Switching Configurations
Configuration management systems in general have to support the
notion of multiple configurations. There are usually at least two
configurations stored in networking devices: The currently active
configuration and a configuration which is stored in stable storage
and reloaded upon re-initialization.
Saperia & Schoenwaelder [Page 6]
Internet-Draft Policy-Based SNMP Enhancements September 1999
Some devices contain additional configuration sets so that changes
can be made without risking disruption to existing services and to
allow operators to program automated switching between different
complex configurations (e.g. based on the time of day). Such a switch
between configurations may affect lots of devices and it should
therefore be supported in an effective way.
4.8. Evolution of Configuration Management Data
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 changes in the configuration data
model and to provide mechanisms that can deal with changes
effectively without causing interoperability problems or having to
replace/update large amounts of fielded networking devices.
5. Issues with COPS/PIB Approach
This section lists some problems with the current COPS/PIBs approach.
The focus here is on conceptual problems rather than technical
details of the specifications.
5.1. Incomplete SoPI Definition
The COPS policy provisioning protocol [COPS-PR] requires a new
language called Structure of Policy Information (SoPI) which is used
to define concrete policy objects in a Policy Information Base (PIB).
SoPI is defined by refering to the SMIv2 standard and making several
changes as described in Section 4.1 in [WHY-COPS]. There are several
problems with this approach.
First, the ad-hoc definition of SoPI leaves many issues unspecified.
It is for example unclear whether the usage of the Counter32 SMIv2
base type is allowed in PIBs. It is also unclear how SMIv2 base data
types with restricted SMIv2 access interact with the POLICY-ACCESS
clause. Another example are the SMIv2 macros to describe compliance
requirements. Are they also applicable to PIBs? Or is every
implementation required to implement a full PIB even if some of the
PIB objects do not make sense on a particular device?
These are only examples of questions that arise since there is no
real definition of the Structure of Policy Information (SoPI). Many
more can be found be carefully analyzing the SMIv2 definition in
light of the COPS/PIB approach to policy provisioning.
Saperia & Schoenwaelder [Page 7]
Internet-Draft Policy-Based SNMP Enhancements September 1999
5.2. PIB Instance Identification
The SoPI and the COPS protocol requires that all instances are
indentified by what is called a Policy Rule Instance Identifier
(PRID). The POLICY-FRAMEWORK-PIB [COPS-PIB] introduces the
PolicyInstanceId textual convention derived from Unsigned32 to
identify policy rule instances.
It is at least unclear whether more complex PRIDs are legal.
Simple-minded PRIDs introduce a need to map MIB instance identifiers,
which are in many cases complex and meaningful, to PRID values used
in PIBs. Furthermore, such a simple PRID identification schemes makes
direct translation of PIBs into MIBs in many cases useless since
table indexing in MIBs is usually optimized for typical retrieval
operations and/or efficient access control.
5.3. Missing Contexts
The SNMP evolution has lead to the introduction of contexts which
contain collections of MIB variables. Contexts turn out to be a very
useful thing in order to handle multiple instantiations of MIB trees,
which would map to multiple configurations in the policy provisioning
scenario.
The COPS/PIB approach is missing a similar mechanism. Instead, each
instance of a rule class can only exist once. It is therefore not
possible to easily describe and manipulate multiple configurations,
which makes policy changes at for example a particular time during a
day costly. In this scenario, COPS/PIBs require to remove all policy
data from all PEPs and to install new policy data on them.
5.4. Evolution of PIBs
SMIv2 MIBs and the SNMP protocol have the important property that
individual definitions can be added, updated or removed without
having to deprecate complete tables. This allows for a smooth
evolution of SMIv2 MIBs and experience with for example the
Interfaces MIB [RFC-2233] shows that changes are unavoidable.
The PIBs in contrast do not support such an evolution of PIBs. The
reason is basically that the install/remove/notify operations are
bound to a PIB class (which corresponds to a MIB table) and that the
COPS-PR protocol only transfers a sequence of values. Thus, changes
like the addition of an element to a class (table) requires to
completely redefine the whole table.
Furthermore, it can be expected that some implementations will not
support all elements of a class (table) definition. There is no
Saperia & Schoenwaelder [Page 8]
Internet-Draft Policy-Based SNMP Enhancements September 1999
mechanism to deal with this situation in an explicit way. Hence, a
PEP which does not support all elements of a class (table) still has
to conform to the interface and it has to provide/accept dummy values
during notify or install operations. This can lead to serious
problems in troubleshooting situations since dummy values are hard to
identify.
5.5. Configuration Management for exisiting MIBs
The COPS/PIBs proposal can not be directly applied for policy
provisioning with existing MIBs. A good example are SNMP access
control tables [RFC-2575] or IP forwarding tables [RFC-2096] for
which well known MIB definitions do exist.
The fact that there are two different languages to describe the same
information seems like a costly way to operate networks and it will
lead to duplication of work within the IETF. It will also lead to
more complexity in typical implementations.
5.6. Manual Translations between PIBs and MIBs
There is no algorithm that can automatically convert a PIB into a
MIB. There are also no provisions to leverage existing MIBs and to
make them available for more efficient configuration management
without having to manually redefine the MIB as a PIB.
The authors believe that it is desirable to have a single and
coherent language and format for defining management information. In
particular, it should be possible to use the same definition for
monitoring and configuration management purposes. The introduction of
multiple languages with manual translations between them introduces
costs and another source of possible inconsistencies.
6. Possible Changes to SNMP
In this section, we will briefly outline changes to the SNMP
Framework that will enhance the SNMP Framework to support Policy-
Based management. Some of the changes listed below are actually
being worked on for other reasons, mainly to improve the efficiency
of bulk data transfers.
6.1. SMIv2 Extensions to Define Operations
The SMIv2 should be extended to allow the definition of operations on
collections of managed objects (typically on table rows). A
Saperia & Schoenwaelder [Page 9]
Internet-Draft Policy-Based SNMP Enhancements September 1999
definition of an operation should include the operation signature,
which includes the operation name (a registered OID value), the
arguments of the operation (a list of object-types), the results
produced by the operation (a list of object-types) and operation
specific exceptions. It is important to reduce the degree of freedom
that currently exist with the SNMP set operation. Furthermore, it is
necessary that SMIv2 defined operations can be mapped to APIs in
frequently used implementation languages automatically in order to
make the development of (configuration) management applications more
efficient and cost effective.
An SMIv2 extension for operations will allow the definition of
install/remove/notify operations on table rows for existing as well
as future MIB modules. Care must be taken to allow proper versioning
of operation definitions since MIB definitions (such as conceptual
table) can and will change over time.
6.2. SNMP Transaction Support
There is a need for enhanced transaction support across sequences of
simple SNMP operations. In its simplest form, a transaction will be
made up of a sequence of SNMP operations targeted at the same SNMP
entity.
6.3. Transport over TCP
An SNMP over TCP transport mapping is needed in order to enable more
efficient bulk data transfers and to ease the implementation of
larger transactions. A document defining SNMP over TCP is under
development by the Network Management Research Group (NMRG) [SNMP-
TCP].
It is important to realize that an SNMP over TCP transport mapping
complements the SNMP over UDP transport mapping and does not replace
it.
6.4. Additional Protocol Operations
The SNMP protocol could be extended with additional PDUs if necessary
that realize operations on collections of object-types. This
minimally requires the introduction of a new "CallOperation" PDU.
Support for larger transactions may require the introduction of
additional PDUs unless one uses other mechanisms for transaction
handling (such as contexts or transport system mechanisms).
Saperia & Schoenwaelder [Page 10]
Internet-Draft Policy-Based SNMP Enhancements September 1999
6.5. Efficiency Improvements
Bulk data transfers are not very efficient with SNMP since the
payload contains large amounts of redundant OID fragments. This is
caused by common OID prefixes and instance identifiers in the
payload. A compression scheme is one potential solution to increase
the bandwidth efficiency of SNMP [SNMP-COMP]. Such a mechanism may
have advantages over alternate encoding schemes since the receiving
application still has access to full instance-level names rather than
just a sequence of values. This provides for robustness since
ordering or omission problems in the encoded values, which may be
caused by legal changes to the MIB definition or simply
implementations that support only subsets of the standardized
configuration information, can be detected and dealt with.
7. Comments on draft-kzm-policy-protocomp-00.txt
This section comments on the document [WHY-COPS] which was intended
as a comparison between COPS and SNMP. The introduction read in part,
"it has been requested that a comparison be undertaken as to why COPS
is better suited to this than a (modified if necessary) version of
SNMP".
At first glance, it seems to be well written and appears to make a
number of good points. However, upon closer examination, several of
the points made in that document deserve further scrutiny in order to
arrive at a more balanced view.
7.1. Section 3.3 Exclusive Access by the PDP
An early major point of the [WHY-COPS] document is that different
requirements have led to different design choices for COPS/PIBs vis-
a-vis SNMP/MIB. One of these requirements differences is with regard
to the "single PDP" versus "multiple manager" dimension and the
design choices that spring therefrom.
The COPS document considers the possibility of multiple PDPs
operating on a system which had multiple sets of policy. It was not
made clear how this can or should/will work within a single managed
system.
7.2. Section 3.5 COPS Takes Advantage of TCP
A second major point is that of choice of transport: TCP versus UDP.
It has a number of sub-points.
The first is maximum message size. The document contrasts the
Saperia & Schoenwaelder [Page 11]
Internet-Draft Policy-Based SNMP Enhancements September 1999
maximum message size of a COPS object (64KB) with the minimum size an
SNMP implementation must support (484 bytes). It fails to
acknowledge that the maximum message size of an SNMP message is also
64KB (actually virtually unlimited -- limited to 2 billion varbinds
and the practical limit comes from the buffering capability of the
underlying operating system and maximum message size of the transport
which goes up to 64KB for UDP). The document does correctly state
that messages this large are rare. One could quibble over the stated
value of 1500 bytes but it is not of importance for this discussion.
One reason this is of no importance is that the SNMP-based framework
allows a large transaction to be broken into groups of multiple,
smaller, transactions. Each transaction-let can be transported
independently and then made to go active simultaneously. Not only
can all columns of an entire row be made active simultaneously,
multiple rows can be made active simultaneously. This is a MIB and
application design issue, not a protocol issue, as it properly should
be. The related portions of policy can be conveyed independently and
made active simultaneously, hence SNMP-based management can be used
to convey policy information (or any other information) without
concern for the maximum message size. Operational experience
indicates that it is possible to move a management script consisting
of multiple tens of kilobytes via SNMP/MIB and then to activate the
script. Although it is not suggested that SNMP will replace FTP over
TCP, the applicability to moving other management information, such
as policy configuration data, is obvious.
Section 3.5 talks about the problems with incremental creation of a
read-create table and how atomic access is easier to implement and
test. In many of today's modern SNMP implementations, the code to
implement incremental and atomic row creation and deletion are a part
of a subroutine library and the grungy details are isolated from the
developer who uses it and who may not be an SNMP expert. As a result
of wrapping a powerful API and automatically generated code around
the row creation, implementation and test is not as difficult as
represented and movement to COPS' atomic creation does not yield the
stated advantages.
Finally, with regard to incremental creation, there is an additional
important point worthy of discussion. One reason for the ability to
handle incremental creation is that there is a possibility of version
skew in the version of the information known by the sender and the
information known by the receiver as would occur because of evolution
of the PIB, such evolution to be expected. COPS/PIB needs a robust
mechanism for dealing with this evolution.
Another point made in the discussion of TCP versus UDP is that COPS
can afford to rely on TCP because the design choices for COPS assume
that the network is up and working. SNMP's typical use of UDP is an
appropriate one because research and field experience have shown that
Saperia & Schoenwaelder [Page 12]
Internet-Draft Policy-Based SNMP Enhancements September 1999
UDP, with an appropriate application layer retransmission strategy is
more robust, and provides a lower mean time to conduct a transaction,
than does TCP with it one-size-fits-all retransmission algorithm.
This is particularly true when the network is at or near congestion
collapse.
It seems obvious that if you ever want SNMP to work, you want it to
work when the network is at or near congestion collapse, and the
choice of a UDP transport with an intelligent application-layer
retransmission algorithm would be an appropriate design choice.
Similarly, it seems obvious that if you ever want policies to work,
especially RSVP and diffserv-related policy, you want it to work when
the network is at or near congestion collapse, and the choice of a
UDP transport with an intelligent application-layer retransmission
algorithm would again be an appropriate design choice. Such a choice
would be important in minimizing the mean time to complete those
transactions that could be used to bring the network back from the
brink of congestion collapse.
The [WHY-COPS] document failed to make the critical distinction
between transport reliability obtained through retransmission and
transactional integrity.
A third major point is that SNMP operations are more complex than are
necessary for COPS/PIBs.
In order to make this point, the authors use an example from the
User-based Security Model (USM) for creating a row in a user table,
along with appropriate secrets. Aspects of this table that are not
explained in the document are that the creation of secrets on the new
user comes from a manipulation of the keys of a user being "cloned"
from. These operations allow the creation of a new user and new
secrets to be done in the clear, but without disclosing either the
new or the old secrets. Consequently, neither the old nor the new
secret can be read, and the operation must be idempotent. The
operation must be performed at least once and at most once, therefore
exactly once even during periods of network instability. Therefore,
this is fundamentally a harder problem than typically encountered.
Furthermore, sometimes writers of specifications intentionally elect
to write algorithms in "simpleminded" baby steps in the interest of
reader understanding rather than implementation efficiency. This
algorithm is such an example. As a result, it is inappropriate to
compare a COPS-based approach with no exception handling to a non-
optimized approach with exception handling. A better comparison would
be to document the steps one would use with a COPS-based approach to
perform an idempotent operation and to be able to determine if the
operation succeeded or failed in the presence of a race condition
between the loss of the management connection and the conclusion of
Saperia & Schoenwaelder [Page 13]
Internet-Draft Policy-Based SNMP Enhancements September 1999
the transaction/sending of the response.
Of course, it is possible that a COPS proponent might say that it is
not necessary or appropriate to perform operations that must be
conducted exactly once. If that is the case, then it is not
appropriate to compare with an example that achieves that which is
unnecessary.
7.3. Section 3.7 COPS over TCP (Revisited)
Section 3.7 claims that the use of COPS over TCP is different from
and superior to SNMP/MIB with respect to the volatility of
provisioned policy information. The document states that COPS over
TCP can invoke an expire timeout on provisioned policy information
after loss of communications with a PDP. The expire timeout
information comes as a part of the policy information.
Sometimes the [WHY-COPS] document uses "SNMP" to mean the entire
SNMP-based Internet-standard Management Framework (including the SMI,
MIB, and Protocol with security and administration) and at other
times uses "SNMP" to mean merely the protocol portion of the
management framework. This is unfortunate and sometimes misleads the
reader.
The section goes on to say that SNMP is different whereas in reality
it is the same. In the SNMP-based management framework, the
volatility of MIB information to be stored, as the document states,
is communicated along with the MIB information. Having volatility
information or timer information in MIB data which could be directly
applied to expiry rules is neither new nor unusual. One of the
oldest examples is ipRouteAge, which dates back to MIB I and 1988.
More recently, it has become customary for MIB documents to use the
StorageType textual convention, which designates data to be volatile,
non-volatile, permanent, etc. It is obviously easy to use a similar
textual convention to associate a time-based MIB object which conveys
expiry information with MIB-based policy data in an manner that is
exactly analogous to that of COPS over TCP. In this case, the expiry
would be invoked when communications between the PDP and PEP were
lost.
Contrary to the claim, SNMP is no different and COPS over TCP offers
no advantages in this regard.
7.4. Section 3.8 Modifying Message Formats
Section 3.8 makes the point that COPS messages use a TLV format,
making COPS superior to SNMP. SNMP similarly uses a TLV format.
Saperia & Schoenwaelder [Page 14]
Internet-Draft Policy-Based SNMP Enhancements September 1999
Section 3.8 also speaks to the fact that in SNMP the varbindlist in a
response is identical to that of the corresponding request. This is
an important design feature. This feature was added in order to
insure that systems (including managers and agents) designed around
the SNMP-based management framework were able to attain transactional
integrity. It is important to distinguish between transactional
integrity and transport reliability.
7.5. Section 3.9 Initiation by the PEP
It is interesting to note that the document compares apples and
oranges in that it contrasts the COPS approach wherein the PEP, such
as a router, querying the PDP, i.e., pulling the policy data.
However, in the SNMP approach, it has the PDP doing set requests on
the PEP, i.e., pushing the policy data. Section 3.9 dismisses this
approach without a fair analysis.
The SNMP protocol has since its invention a mechanism to send
unsolicited notifications. SNMPv3 includes a confirmed operation to
submit notifications. It is therefore very well possible that a PEP
can initiate a configuration over SNMP in much the same way a
configuration can be initiated using COPS by sending a notification
to the PDP which in turn installs the relevant MIB objects on the
PEP. The statement that a PEP router likely requires a command
generator for this purpose seems to ignore this possibility and may
mislead readers.
The analysis fails to consider the use of logical contexts to sort
out the subset of relevant policies for a given router and throws in
SQL as a red herring. According to the last paragraph of the
section, the COPS approach is for the PEP to indicate its
capabilities and status to the PDP. The PDP then sends the relevant
policies via COPS. It is equally practical for the PEP to use an
SNMP/MIB-based approach to indicate its capabilities and status to
the PDP and for the PDP to provide the relevant policies via
SNMP/MIB.
7.6. Section 3.10 Deleting Policy
Section 3.10 rightly states that MIB objects can be used to delete
multiple instances to be deleted and that RowStatus is a common
mechanism for deleting a particular row. If there is a need for a
mechanism to delete all rows in a table, definition and
implementation is done through the MIB, i.e., this is a MIB
definition issue. The fact that objects to delete all rows in a
table are rare is simply a reflection of the fact that the
requirement for such a capability has been rare.
Saperia & Schoenwaelder [Page 15]
Internet-Draft Policy-Based SNMP Enhancements September 1999
7.7. Additional Sections
Later sections of the document discuss hypothetical scenarios. During
the meeting we can discuss a wide range of opportunities for
modification of SNMP and integrating value add features from
COPS/PIBs.
Saperia & Schoenwaelder [Page 16]
Internet-Draft Policy-Based SNMP Enhancements September 1999
8. Conclusions
The publication of COPS as a proposed standard without consideration
of how that standard is to relate to the IETF standard management
protocol, SNMP, will have a number of undesired effects. This would
be particularly unfortunate if the benefits of the COPS/PIB approach
were not as significant as claimed in [WHY-COPS]. The undesired
effects include fragmenting focus and resources in the IETF, vendors
and customers, and adding confusion in an already difficult area. For
example, how does the policy information in COPS relate to the
instance based fault information which is widely deployed using SNMP?
The already difficult problem of management will be made more so if
we start configuring policy with COPS/PIBs and do other management
with SNMP. Some excellent work has taken place in the Policy area.
Some of the COPS ideas, and a good deal of the work described in the
Policy Framework and other documents are very helpful - they do not
require a new protocol. Implementing these ideas with SNMP where
changes are necessary to support them would result in a unified
management environment utilizing the best features of both.
In the end it is necessary to read performance information via SNMP.
Policy information can be read by SNMP. Configuration of device
instance specific information via SNMP is and will continue to be
done. The only item remaining is configuration of policy based
information. It makes sense to evolve SNMP so that it can meet this
important requirement.
The differences between the COPS/PIB approach and the SNMP/MIB
approach are not as great as presented. The advantages of COPS/PIB
over SNMP/MIB do not outweigh the importance of a single, consistent,
and coordinated management approach which is complementary to the
vast installed base of SNMP-based management.
Saperia & Schoenwaelder [Page 17]
Internet-Draft Policy-Based SNMP Enhancements September 1999
9. Suggested Plan of Action
Many of the best proposals are the result of a concentrated effort by
interested and involved individuals. We recommend that this approach
be used in this case. Realizing that time is important and that
pragmatic trade-offs are necessary the following is the recommended
course of action:
1. Within a short time of the meeting the involved area directors
and working group chairs should reach agreement on details with
regard to the participants. That is, they will have selected
(or be in the process of selecting) a small group of individuals
representing many disciplines. This approach has been
successfully employed many times in a variety of circumstances
in the IETF.
2. The first step will be the laundry listing of policy related
features which are deemed mandatory. Input for this effort will
naturally come from COPS/PIBs and much of the other related work
that has been done. This work should be completed in time for
the IETF in Washington.
3. The Area Directors and Working Group Chairs should work together
to make good presentations to the working groups involved so
that the community can add anything to the requirements.
4. Within 2 weeks after the close of the IETF, requirements
gathering should close. The closure of this phase is not a
prerequisite to starting the other phases of the project listed
below.
5. After the requirements have been identified, the changes
necessary to SNMP should be isolated.
6. These changes should then be integrated into a revised set of
the impacted SNMP documents and put out for a review about 1
month prior to the spring IETF.
7. Issues can be discussed at the Spring IETF and then closed on
the mailing lists within 4 - 6 weeks after the meeting.
Saperia & Schoenwaelder [Page 18]
Internet-Draft Policy-Based SNMP Enhancements September 1999
10. References
[RAP-FRAME] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
for Policy-based Admission Control", draft-ietf-rap-
framework-03.txt, April 1999.
[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, August 1999.
[COPS-PR] 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-cops-pr-00.txt, June
1999.
[COPS-PIB] Fine, M., McCloghrie, K., Seligson, J., Chan, K., Hahn, S.,
and A. Smith, "Quality of Service Policy Information Base",
draft-mfine-cops-pib-01.txt, June 1999.
[WHY-COPS] McCloghrie, K., and M. Fine, "A Comparison of Policy
Provisioning Protocols", draft-kzm-policy-protcomp-00.txt,
September 1999.
[SNMP-TCP] J. Schoenwaelder (editor), "SNMP-over-TCP Transport
Mapping", draft-irtf-nmrg-snmp-tcp-01.txt, June 1999.
[SNMP-COMP] J. Schoenwaelder (editor), "SNMP Payload Compression",
draft-irtf-nmrg-snmp-compression-00.txt, June 1999.
[RFC-2096] F. Baker, "IP Forwarding Table MIB", RFC 2096, January 1997.
[RFC-2233] McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB
using SMIv2", RFC 2233, November 1997.
[RFC-2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", RFC 2575, April 1999.
Saperia & Schoenwaelder [Page 19]
Internet-Draft Policy-Based SNMP Enhancements September 1999
11. Authors' Address
Jon Saperia
IronBridge Networks
55 Hayden Avenue
Lexington, MA 02173
USA
Phone: +1 781-402-8029
Fax: +1 781-402-8090
EMail: saperia@mediaone.net
Juergen Schoenwaelder
TU Braunschweig
Bueltenweg 74/75
38106 Braunschweig
Germany
Phone: +49 531 391-3283
EMail: schoenw@ibr.cs.tu-bs.de
Saperia & Schoenwaelder [Page 20]