One document matched: draft-ietf-snmpconf-bcp-00.txt

Internet Draft        SNMP CONFIGURATION          March 9 2000


                                                   M. MacFaden
                                      Riverstone Networks, Inc
                                                    J. Saperia
                                           JDS Consulting, Inc

          CONFIGURING NETWORKS AND DEVICES WITH SNMP
               draft-ietf-snmpconf-bcp-00.txt 






                     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.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.




1.  Introduction

Configuration (provisioning) of network elements is hard in
all but the most trivial of networks. This document describes
first hand experience with provisioning of data networks over





MacFaden&Saperia  Expires September 10th 2000         [Page 1]




Internet Draft        SNMP CONFIGURATION          March 9 2000


the past ten years.

It then enumerates key tenets in configuration in in order to:
1) set expectations for users 2) guide implementors torward
better use of the SNMP framework for configuration of data
networks.

This document is organized as follows: The background section
describes how configuration of TCP/IP networks is currently
practiced by experienced network operations staff and the
management interfaces used to perform these operations.

The requirements section enumerates the goals and fundamental
assumptions of configuration.

Section 2 describes terminology as used in this document.
Section 3 and 4 describe agent and management development
 using the SNMP framework.  Secton 5 describes relationship of
Policy Management to SNMP framework and Section 6 reviews
security issues related to the models described here.



1.1.  Background

Data network devices are configured using many methods,
however two methods remain the most common: SNMP and Command
Line Interface (CLI). Layered on top of these methods are
operational methods for deploying changes to networks in a
cautious and incremental manner.

Experienced Network Operations staff make changes to network
configurations and firmware with careful planning and well
documented procedures such as:

    A. Pass one: LAB tryout to verify reliability and
       interoperability with prior versions.
    B. Pass two: select an edge of network
       during non-critical/off hours to effect the change
       and plan for fall back should changes fail.
     1. Apply change first via cli to memory and watch
        device/network carefully over some time period
     2. After some time, write changes to persistent storage
     3. Expand changes to a few more like devices
     4. Keep mixed versions to prevent total loss of network





MacFaden&Saperia  Expires September 10th 2000         [Page 2]




Internet Draft        SNMP CONFIGURATION          March 9 2000


     5. Watch for new unkown defaults
     6. Watch for unknown side effects of changes
     7. update configurations in revision control system

Next, An analysis of the strengths and weaknesses of each
method is offered here.



1.2.  Requirements

This section defines realistic requirements for what we want
to accomplish with SNMP Configuration.

What are the goals and assumptions needed achieve state of the
art configuration on network elements.

Show that SNMP can be used to achieve these goals and that the
assumptions are practical.

The following presents a set fundamental assumptions:


1.2.1.  Fundamental Tenets of configuration

1) A loss of connectivity can occur at any point in time
between the configurator and the device being configured.
There is no conceivable protocol or sufficient voltage that
can negate this assumption.

2) Device state and configuration SHOULD be understood by a
"mere mortal" with the following assumptions:
  1) trained in the fundamentals of data communication
(bridging, routing)
  2) understands the vendor implementation

3) Operators MUST have the ability to validate proper
operation of a device before and after configuration changes.

4) The expected behavioral change exhibited by an individual
device under configuration is not as readily apparent as it
once was. Devices are more complex as they acquire more
capabilities. Interactions between capabilities are not always
well defined during configuration sequences.






MacFaden&Saperia  Expires September 10th 2000         [Page 3]




Internet Draft        SNMP CONFIGURATION          March 9 2000


5) Configuration affects network stability and network
stability affects configuration. For example, noncritical
changes to a facility such as BGP or spanning tree SHOULD NOT
cause convergence to be lost.

6) Achieving convergence in an autonomous system  is not
absolute given when  configurations are made.  While
simulations can be made, keeping track of all state data is
growing harder as features become more dynamic due to
protocols like GVRP/GARP as well as time of day configuration
capabilities found in RFC 2591.

Here then are requirements for a modern configuration
protocol:

1) Any modern configuration protocol or process MUST be
mindful of tenent #1 and take appropriate measures to leave
the network device or devices in a consistent/recognizable
state.

2) Support for testing configurations incrementally MUST be
included.

3) Diagnostic routines SHOULD be provided to verify proper
operation of complex protocols.

Debugging is an integral part of the configuration process.
Data communications technology continues to exhibit growing
complexity and as networks grow in size and data
communications functions collapse into fewer and fewer
discrete systems.

4) others go here...


2.  Terminology

Here we enumerate terms we are defining and what exiting terms
we redefine...


3.  Agent Software Development

This section describes how to implement a read-write MIB
properly. It reviews some key SNMP requirements such as





MacFaden&Saperia  Expires September 10th 2000         [Page 4]




Internet Draft        SNMP CONFIGURATION          March 9 2000


rollback of sets in a given PDU.


3.1.  MIB Module Implementation and Design

Discuss read-write operations here, RowStatus, timing out of
non-active rows.


3.1.1.  Indexing Issues

This section describes uses for Associative indexing, multiple
tables to support different indexing schemes, and other such
issues as it affects configuration.


3.1.2.  Notifications

Proper use of notifications based on application development
needs. It is hard for agent developer to know at first when
agent should use notifications is being built and even harder
if developer is not familiar with the feature being
instrumented.

Even so, there is one key rule of thumb:

1) The more frequent the event, the greater the need for
internal aggregation or throttling or potentially redesign of
the notification with the frequency in mind as found in RFC
2115 for DLCI traps per interface. There can be cases where it
is not useful to send notifications such as defined in RFC
2115 when interfaces are taken down administratively, no
frDLCIStatusChange must be sent.

Rate Limiting trap emission will be vital in the future world
where hundreds of ports that do layer 1/2/3/4/n bridging and
routing and load balancing exist in a given device. RFC 2115
includes the object frTrapMaxRate.


3.1.3.  RFC Module Compliance

There are a number of RFC MIB Modules today and new IETF
standard MIB modules written MUST contain compliance macros
per RFC 2579.





MacFaden&Saperia  Expires September 10th 2000         [Page 5]




Internet Draft        SNMP CONFIGURATION          March 9 2000


A vendor MAY provide additions to the  existing MIB Objects,
they MAY also if necessary duplicate standard objects in their
vendor name space.

They MUST not use this duplication as an alternative to
standard objects found in standards track RFCs.

A vendor SHOULD write compliance macros for enterprise
specific MIB modules as this helps document changes over time.

A vendor SHOULD also implement agent capability MIB modules to
define any variations in implementation.


3.2.  Currency with RFC MIB Module Standards

Vendors SHOULD make every attempt to keep their
implementations current with the standards versions of MIB
Modules. In particular, agents and managemement software
SHOULD follow the current STATUS of MIB objects.


3.3.  Implementing MIBs - Coverage

The SNMP based instrumentation SHOULD provide complete
coverage of the managed element to facility integrated
management.

Using module compliance macros to guide implementation, all
mandatory conformance groups MUST be implemented.


3.4.  Lifecycle considerations

This section presents one proposed lifecycle of a MIB.


3.4.1.  MIB Module


TBD









MacFaden&Saperia  Expires September 10th 2000         [Page 6]




Internet Draft        SNMP CONFIGURATION          March 9 2000


3.4.2.  Agent

TBD


3.5.  Vendor Extensions

Describe here how to relate vendor MIBs to ietf MIBs.  Fate
sharing of MIB tables such as a MIB to create some layer that
then shows up in ifTable...


3.6.  Supporting More than one Management Interface

Details how to relate data in one management interface to
another and to make the data consistent.

Only one data path to base information SHOULD exist in a
device.  There may exist multiple names for a given data
object though.  ifIndex defines some logical entity used by
SNMP manager applications, yet ifName provides mapping to CLI.


3.6.1.  Configuration State

This will describe how to track current configuration state.
At what level are changes reported as errors, per table or per
object. Is there a need for specific objects to support
changes other than RowStatus?


3.6.2.  Rollback

This section describes how SNMP can be used to maintain a
consistent state in the event of errors. Some discussion of
how this can work with large changes across tables.


3.6.3.  Incremental Changes (sequencing issues)

Varbinds can come in any order and the rule is that they all
appear to be set at the same time. Discuss this rule and how
to do partition pdus or do this logically with additional
objects...






MacFaden&Saperia  Expires September 10th 2000         [Page 7]




Internet Draft        SNMP CONFIGURATION          March 9 2000


3.6.4.  Supporting Large Changes

Describe here how to implement support where changes are made
with massive configuration files such as thousands of lines of
access control lists.


3.7.  When should changes made become effective

When should changes be realized in the device? Simple devices
like bridges performed simple set operations without
consideration for storage type, etc.

In addition, the need for near real time changes must be
understood.

While most MIB objects can be polled or set in as little as
one second intervals, most agents may require more time for
more complex operations. Agent implementations SHOULD provide
some indication of time interval needed for set completion or
retrieval of managed objects.


3.8.  Devices that use SNMP as Primary Interface

Describe this model of operation and interactions that should
be followed to stop race conditions for changes from two
interfaces.


3.9.  Devices that use SNMP as Secondary Interface

Describe this model of operation and interactions that should
be followed to stop race conditions for changes from two
interfaces.


4.  Management Software Development

Deploying configuration software requires proper thought on
how configuration to a network will be done. There are basic
connectivity issues as well a security issues.








MacFaden&Saperia  Expires September 10th 2000         [Page 8]




Internet Draft        SNMP CONFIGURATION          March 9 2000


4.1.  Protocol Operations

TBD


4.2.  Data Retrieval

TBD

This section details some important factors.


4.3.  Topology/connectivity factors

4.3.1.  In band

4.3.2.  Out of band

4.3.3.  Rules of thumb



4.4.  Device memory/Capability factors

This  section describes how to design configuration models
when device memory and capability are constrained and when
these factors are not constrained.


4.5.  Persistence expectations

Explicit persistence of set requests has always been assumed
in SNMP sets. New textual conventions such as StorageType
allow for alternative configuration models.

Explain how these work here and how to use them.


4.6.  Rate and Volume of Changes to Device

Describe different models from store and forward to real time
changes and how this relates to the volume of changes needed
to effect a feature change.







MacFaden&Saperia  Expires September 10th 2000         [Page 9]




Internet Draft        SNMP CONFIGURATION          March 9 2000


4.7.  Handling Multiple Managers

Devices are often modified by multiple management entities.
Explain how to use the SNMP framework to provide boundaries
and to audit changes made by any given manager.


4.8.  Diagnostics and Configuation

This section describes in detail the kinds of diagnostics
needed to help support proper provisioning models.



5.  Policy Based Management

Provides an overview of configuration "in the large" and how
to scale configuration to include many devices in a safe and
sane manner.



5.1.  Policy Modules

TBD..


5.2.  Requirements

TBD...


5.3.  Capability Module

TBD...


5.4.  Integration with 'device specific' module

TBD...










MacFaden&Saperia  Expires September 10th 2000        [Page 10]




Internet Draft        SNMP CONFIGURATION          March 9 2000


6.  Security Considerations

TBD...  More specific Text about security goes here. Could add
bits about snooping wire and sending.

SNMPv1 by itself is not a secure environment.  Even if the
network itself is secure (for example by using IPSec), even
then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the
objects in this MIB.

It is recommended that the implementors consider the security
features as provided by the SNMPv3 framework.  Specifically,
the use of the User-based Security Model RFC 2574 [12] and the
View-based Access Control Model RFC 2575 [15] is recommended.

It is then a customer/user responsibility to ensure that the
SNMP entity giving access to an instance of this MIB, is
properly configured to give access to the objects only to
those principals (users) that have legitimate rights to indeed
GET or SET (change/create/delete) them.





























MacFaden&Saperia  Expires September 10th 2000        [Page 11]




Internet Draft        SNMP CONFIGURATION          March 9 2000


7.  References

[1]  Harrington, D., Presuhn, R., and B. Wijnen, "An
     Architecture for Describing SNMP Management Frameworks",
     RFC 2571, April 1999.

[2]  Rose, M., and K. McCloghrie, "Structure and
     Identification of Management Information for TCP/IP-based
     Internets", STD 16, RFC 1155, May 1990.

[3]  Rose, M., and K. McCloghrie, "Concise MIB Definitions",
     STD 16, RFC 1212, March 1991.

[4]  Rose, M., "A Convention for Defining Traps for use with
     the SNMP", RFC 1215, March 1991.

[5]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
     Rose, M., and S. Waldbusser, "Structure of Management
     Information Version 2 (SMIv2)", STD 58, RFC 2578, April
     1999.

[6]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
     Rose, M., and S. Waldbusser, "Textual Conventions for
     SMIv2", STD 58, RFC 2579, April 1999.

[7]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
     Rose, M., and S. Waldbusser, "Conformance Statements for
     SMIv2", STD 58, RFC 2580, April 1999.

[8]  Case, J., Fedor, M., Schoffstall, M., and J. Davin,
     "Simple Network Management Protocol", STD 15, RFC 1157,
     May 1990.

[9]  Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
     "Introduction to Community-based SNMPv2", RFC 1901,
     January 1996.

[10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
     "Transport Mappings for Version 2 of the Simple Network
     Management Protocol (SNMPv2)", RFC 1906, January 1996.

[11] Case, J., Harrington D., Presuhn R., and B. Wijnen,
     "Message Processing and Dispatching for the Simple
     Network Management Protocol (SNMP)", RFC 2572, April
     1999.





MacFaden&Saperia  Expires September 10th 2000        [Page 12]




Internet Draft        SNMP CONFIGURATION          March 9 2000


[12] Blumenthal, U., and B. Wijnen, "User-based Security Model
     (USM) for version 3 of the Simple Network Management
     Protocol (SNMPv3)", RFC 2574, April 1999.

[13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
     "Protocol Operations for Version 2 of the Simple Network
     Management Protocol (SNMPv2)", RFC 1905, January 1996.

[14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3
     Applications", RFC 2573, April 1999.

[15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
     Access Control Model (VACM) for the Simple Network
     Management Protocol (SNMP)", RFC 2575, April 1999.

[16] McCloghrie, K. and M. Rose, Editors, "Management
     Information Base for Network Management of TCP/IP-based
     internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems,
     Performance Systems International, March 1991.

[17] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
     MIB using SMIv2", RFC 2233, Cisco Systems, FTP Software,
     November 1997.

[18] Case, J., Mundy, R., Partain, D., and B. Stewart,
     "Introduction to Version 3 of the Internet-standard
     Network Management Framework", RFC 2570, April 1999.

[19] Brown, C., and F. Baker, "Management Information Base for
     Frame Relay DTEs Using SMIv2", RFC 2115, September 1997.


8.  Intellectual Property

The IETF takes no position regarding the validity or scope of
any intellectual property or other rights that might be
claimed to  pertain to the implementation or use of the
technology described in this document or the extent to which
any license under such rights might or might not be available;
neither does it represent that it has made any effort to
identify any such rights.  Information on the IETF's
procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11.
Copies of claims of rights made available for publication and
any assurances of licenses to be made available, or the result





MacFaden&Saperia  Expires September 10th 2000        [Page 13]




Internet Draft        SNMP CONFIGURATION          March 9 2000


of an attempt made to obtain a general license or permission
for the use of such proprietary rights by implementors or
users of this specification can be obtained from the IETF
Secretariat.

The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or
other proprietary rights which may cover technology that may
be required to practice this standard.  Please address the
information to the IETF Executive Director.


9.  Editors' Addresses


     Michael R. MacFaden
     Riverstone Networks, Inc
     5200 Great America Parkway
     Santa Clara, CA 95054
     phone - +1 408 878 6500
     email - mrm@riverstonenet.com

     Jon Saperia
     174 Chapman Street
     Watertown, MA 02472
     email - spaeria@jdscons.com



10.  Full Copyright Statement

Copyright (C) The Internet Society (2000). 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





MacFaden&Saperia  Expires September 10th 2000        [Page 14]




Internet Draft        SNMP CONFIGURATION          March 9 2000


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.




































MacFaden&Saperia  Expires September 10th 2000        [Page 15]




Internet Draft        SNMP CONFIGURATION          March 9 2000


Table of Contents


1 Introduction ..........................................    1
1.1 Background ..........................................    2
1.2 Requirements ........................................    3
1.2.1 Fundamental Tenets of configuration ...............    3
2 Terminology ...........................................    4
3 Agent Software Development ............................    4
3.1 MIB Module Implementation and Design ................    5
3.1.1 Indexing Issues ...................................    5
3.1.2 Notifications .....................................    5
3.1.3 RFC Module Compliance .............................    5
3.2 Currency with RFC MIB Module Standards ..............    6
3.3 Implementing MIBs - Coverage ........................    6
3.4 Lifecycle considerations ............................    6
3.4.1 MIB Module ........................................    6
3.4.2 Agent .............................................    7
3.5 Vendor Extensions ...................................    7
3.6 Supporting More than one Management Interface .......    7
3.6.1 Configuration State ...............................    7
3.6.2 Rollback ..........................................    7
3.6.3 Incremental Changes (sequencing issues) ...........    7
3.6.4 Supporting Large Changes ..........................    8
3.7 When should changes made become effective ...........    8
3.8 Devices that use SNMP as Primary Interface ..........    8
3.9 Devices that use SNMP as Secondary Interface ........    8
4 Management Software Development .......................    8
4.1 Protocol Operations .................................    9
4.2 Data Retrieval ......................................    9
4.3 Topology/connectivity factors .......................    9
4.3.1 In band ...........................................    9
4.3.2 Out of band .......................................    9
4.3.3 Rules of thumb ....................................    9
4.4 Device memory/Capability factors ....................    9
4.5 Persistence expectations ............................    9
4.6 Rate and Volume of Changes to Device ................    9
4.7 Handling Multiple Managers ..........................   10
4.8 Diagnostics and Configuation ........................   10
5 Policy Based Management ...............................   10
5.1 Policy Modules ......................................   10
5.2 Requirements ........................................   10
5.3 Capability Module ...................................   10
5.4 Integration with 'device specific' module ...........   10
6 Security Considerations ...............................   11





MacFaden&Saperia  Expires September 10th 2000        [Page 16]




Internet Draft        SNMP CONFIGURATION          March 9 2000


7 References ............................................   12
8 Intellectual Property .................................   13
9 Editors' Addresses ....................................   14
10 Full Copyright Statement .............................   14














































MacFaden&Saperia  Expires September 10th 2000        [Page 17]