[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/