Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3512

Configuring Networks and Devices with Simple Network Management Protocol (SNMP)

Pages: 83
Informational
Part 3 of 4 – Pages 41 to 58
First   Prev   Next

Top   ToC   RFC3512 - Page 41   prevText

4. Implementing SNMP Configuration Agents

4.1. Operational Consistency

Successful deployment of SNMP configuration systems depends on understanding the roles of MIB module design and agent design.
Top   ToC   RFC3512 - Page 42
   Both module and agent design need to be undertaken with an
   understanding of how UDP/IP-based SNMP behaves.  A current practice
   in MIB design is to consider the idempotency of settable objects.
   Idempotency basically means being able to invoke the same set
   operation repeatedly but resulting in only a single activation.

   Here is an example of the idempotency in action:

Manager                              Agent
--------                             ------
Set1 (Object A, Value B) --->        receives set OK and responds
                          X<-------- Response PDU(OK) is dropped by
                                     network
Manager times out
and sends again
Set2 (Object A, Value B) --->       receives set OK (does nothing),
                                    responds
                          <-------- with a Response PDU(OK)
Manager receives OK

   Had object A been defined in a stateful way, the set operation might
   have caused the Set2 operation to fail as a result of interaction
   with Set1.  If the agent implementation is not aware of such a
   possible situation on the second request, the agent may behave poorly
   by performing the set request again rather than doing nothing.

   The example above shows that all of the software that runs on a
   managed element and in managed applications should be designed in
   concert when possible.  Particular emphasis should be placed at the
   logical boundaries of the management system components in order to
   ensure correct operation.

   1. The first interface is between SNMP agents in managed devices and
      the management applications themselves.  The MIB document is a
      contract between these two entities that defines expected behavior
      - it is a type of API.

   2. The second interface is between the agent and the instrumented
      subsystem.  In some cases, the instrumented subsystem will require
      modification to allow for the dynamic nature of SNMP-based
      configuration, control and monitoring operations.  Agent
      implementors must also be sensitive to the operational code and
      device in order to minimize the impact of management on the
      primary subsystems.

   Additionally, while the SNMP protocol-level and MIB module-level
   modeling of configuration operations may be idempotent and stateless
   from one set operation to another, it may not be that way in the
Top   ToC   RFC3512 - Page 43
   underlying subsystem.  It is possible that an agent may need to
   manage this state in these subsystem architectures explicitly when it
   has placed the underlying subsystem into an "intermediate" state at a
   point in processing a series of SET PDUs.  Alternatively, depending
   on the underlying subsystem in question, the agent may be able to
   buffer all of the configuration set operations prior to activating
   them in the subsystem all at once (to accommodate the nature of the
   subsystem).

   As an example, it would be reasonable to define a MIB module to
   control Virtual Private Network (VPN) forwarding, in which a
   management station could set a set of ingress/egress IP addresses for
   the VPN gateway.  Perhaps the MIB module presumes that the level of
   transactionality is the establishment of a single row in a table
   defining the address of the ingress/egress gateway, along with some
   prefix information to assist in routing at the VPN layer to that
   gateway.  However, it would be conceivable that in an underlying
   Layer 2 VPN subsystem instrumentation, the requirement is that all
   existing gateways for a VPN be deleted before a new one can be
   defined--that, in other words, in order to add a new gateway, g(n),
   to a VPN, gateways g(1)..g(n-1) need to be removed, and then all n
   gateways reestablished with the VPN forwarding service.  In this
   case, one could imagine an agent which has some sort of timer to
   establish a bounded window for receipt of SETs for new VPN gateways,
   and to activate them in this removal-then-reestablishment of existing
   and new gateways at the end of this window.

4.2. Handling Multiple Managers

Devices are often modified by multiple management entities and with different management techniques. It is sometimes the case that an element is managed by different organizations such as when a device sits between administrative domains. There are a variety of approaches that management software can use to ensure synchronization of information between the manager(s) and the managed elements. An agent should report configuration changes performed by different entities. It should also distinguish configuration defined locally such as a default or locally specified configuration made through an alternate management interface such as a command line interface. When a change has been made to the system via SNMP, CLI, or other method, a managed element should send an notification to the manager(s) configured as recipients of these applicable notifications. These management applications should update their
Top   ToC   RFC3512 - Page 44
   local configuration repositories and then take whatever additional
   action is appropriate.  This approach can also be an early warning of
   undesired configuration changes.

   Managers should also develop mechanisms to ensure that they are
   synchronized with each other.

4.3. Specifying Row Modifiability

Once a RowStatus value is active(1) for a given row, the management application should be able to determine what the semantics are for making additional changes to a row. The RMON MIB control table objects spell out explicitly what managed objects in a row can and cannot be changed once a given RowStatus goes active. As described earlier, some operations take some time to complete. Some systems also require that they remain in a particular state for some period before moving to another. In some cases, a change to one value may require re-initialization of the system. In all of these cases, the DESCRIPTION clause should contain information about requirements of the managed system and special restrictions that managers should observe.

4.4. Implementing Write-only Access Objects

The second version of the SNMP SMI dropped direct support for a write-only object. It is therefore necessary to return something when reading an object that you may have wished to have write-only semantics. Such objects should have a DESCRIPTION clause that details what the return values should be. However, regardless of the approach, the value returned when reading the object instance should be meaningful in the context of the object's semantics.

5. Designing Configuration Management Software

In this section, we describe practices that should be used when creating and deploying management software that configures one or more systems using SNMP. Functions all configuration management software should provide, regardless of the method used to convey configuration information to the managed systems are backup, fail- over, and restoration. A management system should have the following features: 1. A method for restoring a previous configuration to one or more devices. Ideally this restoration should be time indexed so that a network can be restored to a configured state as of a specific time and date.
Top   ToC   RFC3512 - Page 45
   2. A method for saving back up versions of the configuration data in
      case of hardware or software failure.

   3. A method of providing fail-over to a secondary (management) system
      in case of a primary failure.  This capability should be deployed
      in such a way that it does not cause duplicate polling of
      configuration.

   These three capabilities are of course important for other types of
   management that are not the focus of this BCP.

5.1. Configuration Application Interactions with Managed Systems

From the point of view of the design of the management application, there are three basic requirements to evaluate relevant to SNMP protocol operations and configuration: o Set and configuration activation operations o Notifications from the device o Data retrieval and collection Depending on the requirements of the specific services being configured, many other requirements may, and probably will, also be present. The design of the system should not assume that the objects in a device that represent configuration data will remain unchanged over time. As standard MIB modules evolve and vendors add private extensions, the specific configuration parameters for a given operation are likely to change over time. Even in the case of a configuration application that is designed for a single vendor, the management application should allow for variability in the MIB objects that will be used to configure the device for a particular purpose. The best method to accomplish this is by separating, as much as possible, the operational semantics of a configuration operation from the actual data. One way that some applications achieve this is by having the specific configuration objects that are associated with a particular device be table driven rather than hard coded. Ideally, management software should verify the support in the devices it is expected to manage and report any unexpected deviations to the operator. This approach is particularly valuable when developing applications that are intended to support equipment or software from multiple vendors.
Top   ToC   RFC3512 - Page 46

5.1.1. SET Operations

Management software should be mindful of the environment in which SET operations are being deployed. The intent here is to move configuration information as efficiently as possible to the managed device. There are many ways to achieve efficiency and some are specific to given devices. One general case that all management software should employ is to reduce the number of SET PDU exchanges between the managed device and the management software to the smallest reasonable number. One approach to this is to verify the largest number of variable bindings that can fit into a SET PDU for a managed device. In some cases, the number of variable bindings to be sent in a particular PDU will be influenced by the device, the specific MIB objects and other factors. Maximizing the number of variable bindings in a SET PDU also has benefits in the area of management application transaction initiation, as we will discuss in the following section. There are, though, agents that may have implementation limitations on the number and order of varbinds they can handle in a single SET PDU. In this case, sending fewer varbinds will be necessary. As stated at the outset of this section, the management application software designer must be sensitive to the design of the SNMP software in the managed device. For example, the software in the managed device may require that all that all related configuration information for an operation be conveyed in a single PDU because it has no concept of a transaction beyond a single SNMP PDU. Another example has to do with the RowStatus textual convention. Some SNMP agents implement a subset of the features available and as such the management application must avoid using features that may not be supported in a specific table implementation (such as createAndWait).

5.1.2. Configuration Transactions

There are several types of configuration transactions that can be supported by SNMP-based configuration applications. They include transactions on a scalar object, transactions in a single table (within and across row instances), transactions across several tables in a managed device and transactions across many devices. The manager's ability to support these different transactions is partly dependent on the design of the MIB objects used in the configuration operation. To make use of any kind of transaction semantics effectively, SNMP management software must be aware of the information in the MIB modules that it is to configure so that it can effectively utilize
Top   ToC   RFC3512 - Page 47
   RowStatus objects for the control of transactions on one or more
   tables.  Such software must also be aware of control tables that the
   device supports that are used to control the status of one or more
   other tables.

   To the greatest extent possible, the management application should
   provide the facility to support transactions across multiple devices.
   This means that if a configuration operation is desired across
   multiple devices, the manager can coordinate these configuration
   operations such that they become active as close to simultaneously as
   possible.

   Several practical means are present in the SNMP model that support
   management application level transactions.  One was mentioned in the
   preceding section, that transactions can be optimized by including
   the maximum number of SET variable bindings possible in a single PDU
   sent to the agent.

   There is an important refinement to this.  The set of read-create row
   data objects for tables should be sent in a single PDU, and only
   placed across multiple PDUs if absolutely necessary.  The success of
   these set operations should be verified through the response(s) to
   the Set PDU or subsequent polling of the row data objects.  The
   applicable RowStatus object(s), may be set to active only after this
   verification.  This is the only tractable means of affording an
   opportunity for per-row rollback, particularly when the configuration
   change is across table row instances on multiple managed devices.

   Finally, where a MIB module exposes the kind of helpful transaction
   management object types that were discussed in Section 3.3.5, it is
   clearly beneficial to the integrity of the management application's
   capacity to handle transactions to make use of them.

5.1.3. Tracking Configuration Changes

As previously described in Section 3.3.5 (Summary Objects and State Tracking), agents should provide the capability for notifications to be sent to their configured management systems whenever a configuration operation is completed or is detected to have failed. The management application must be prepared to accept these notifications so that it knows the current configured state of the devices under its control. Upon receipt of the notification, the management application should use getBulk or getNext to retrieve the configuration from the agent and store the relevant contents in the management application database. The GetBulkRequest-PDU is useful for this whenever supported by the managed device, since it is more efficient than the GetNextRequest-PDU when retrieving large amounts
Top   ToC   RFC3512 - Page 48
   of data.  For the purposes of backward compatibility, the management
   station should also support and make use of the GetNextRequest-PDU
   when the agent does not support the GetBulkRequest-PDU.

   Management systems should also provide configuration options with
   defaults for users that tend to retrieve the smallest amount of data
   to achieve the particular goal of the application, to avoid
   unnecessary load on managed devices for the most common retrieval
   operations.

5.1.4. Scalability of Data Retrieval

The techniques for efficient data retrieval described in the preceding sections comprise only one aspect of what application developers should consider in this regard when developing configuration applications. Management applications should provide for distributed processing of the configuration operations. This also extends to management functions that are not the focus of this document. Techniques of distributed processing can also be used to provide resilience in the case of network failures. An SNMP-based configuration management system might be deployed in a distributed fashion where three systems in different locations keep each other synchronized. This synchronization can be accomplished without additional polling of network devices through a variety of techniques. In the case of a failure, a 'backup' system can take over the configuration responsibilities from the failed manager without having to re-synchronize with the managed elements since it will already be up to date.

6. Deployment and Security Issues

Now that we have considered the design of SNMP MIB data for configuration, agent implementation of its access, and management application issues in configuration using SNMP, we turn to a variety of operational considerations which transcend all three areas.

6.1. Basic assumptions about Configuration

The following basic assumptions are made about real world configuration models. 1) Operations must understand and must be trained in the operation of a given technology. No configuration system can prevent an untrained operator from causing outages due to misconfiguration. 2) Systems undergoing configuration changes must be able to cope with unexpected loss of communication at any time.
Top   ToC   RFC3512 - Page 49
      During configuration operations, network elements must take
      appropriate measures to leave the configuration in a
      consistent/recognizable state by either rolling back to a
      previously valid state or changing to a well-defined or default
      state.

   3) Configuration exists on a scale from relatively unchanging to a
      high volume, high rate of change.  The former is often referred to
      as "set and forget" to indicate that the configuration changes
      quite infrequently.  The latter, "near real-time change control"
      implies a high frequency of configuration change.  Design of
      configuration management must take into account the rate and
      volume of change expected in a given configuration subsystem.

6.2. Secure Agent Considerations

Vendors should not ship a device with a community string 'public' or 'private', and agents should not define default community strings except when needed to bootstrap devices that do not have secondary management interfaces. Defaults lead to security issues that have been recognized and exploited. When using SNMPv1, supporting read- only community strings is a common practice. Version 3 of the SNMP represents the current standard for the Internet Management Framework and is recommended for all network management applications. In particular, SNMPv3 provides authorization, authentication, and confidentiality protection and is essential to meeting the security considerations for all management of devices that support SNMP-based configuration.

6.3. Authentication Notifications

The default state of RFC 1215 [17] Authentication notifications should be off. One does not want to risk accidentally sending out authentication failure information, which by itself could constitute a security liability. Enabling authentication Notifications should be done in the context of a management security scheme which considers the proper recipients of this information. There are other liabilities where authentication notifications are generated without proper security infrastructure. When notifications are sent in SNMPv1 trap PDUs, unsolicited packets to a device can causes one or more trap PDUs to be created and sent to management stations. If these traps flow on shared access media and links, the community string from the trap may be gleaned and exploited to gain access to the device. At the very least, this risk should be mitigated by having the authentication trap PDU be conveyed with a
Top   ToC   RFC3512 - Page 50
   community string which is only used for authentication traps from the
   agent, and would be useless for access inbound to the agent to get at
   other management data.

   A further liability of authentication traps can be seen when they are
   being generated in the face of a Denial Of Service (DOS) attack, in
   the form of a flood of PDUs with invalid community strings, on the
   agent system.  If it is bad enough that the system is having to
   respond to and recover from the invalid agent data accesses, but the
   problem will be compounded if a separate Authentication notification
   PDU is sent to each recipient on the management network.

6.4. Sensitive Information Handling

Some MIB modules contain objects that may contain data for keys, passwords and other such sensitive information and hence must be protected from unauthorized access. MIB documents that are created in the IETF must have a 'Security Considerations' section, which details how sensitive information should be protected. Similarly, MIB module designers who create MIB documents for private MIB objects should include similar information so that users of the products containing these objects can take appropriate precautions. Even if a device does support DES, it should be noted that configuration of keys for other protocols via SNMP Sets protected by DES should not be allowed if the other keys are longer than the 56 bit DES keys protecting the SNMP transmission. The DESCRIPTION clause for these object types and their Security Considerations sections in the documents which define them should make it clear how and why these specific objects are sensitive and that a user should only make them accessible for encrypted SNMP access. Vendors should also document sensitive objects in a similar fashion. Confidentiality is not a mandatory portion of the SNMPv3 management framework [6]. Prior to SNMPv3, providing customized views of MIB module data was difficult. This led to objects being defined such as the following from [41].
Top   ToC   RFC3512 - Page 51
   docsDevNmAccessEntry OBJECT-TYPE
       SYNTAX      DocsDevNmAccessEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "An entry describing access to SNMP objects by a
            particular network management station.  An entry in
            this table is not readable unless the management station
            has read-write permission (either implicit if the table
            is empty, or explicit through an entry in this table.
            Entries are ordered by docsDevNmAccessIndex.  The first
            matching entry (e.g., matching IP address and community
            string) is used to derive access."
       INDEX { docsDevNmAccessIndex  }
       ::= {  docsDevNmAccessTable 1 }

   New MIB modules should capitalize on existing security capabilities
   of SNMPv3 Framework.  One way they can do this is by indicating the
   level of security appropriate to different object types.  For
   example, objects that change the configuration of the system might be
   protected by using the authentication mechanisms in SNMPv3.
   Specifically, it is useful to design MIB module object grouping with
   considerations for VACM views definition, such that users can define
   and properly scope what tables are visible to a given user and view.

7. Policy-based Management

In some designs and implementations, a common practice used to move large amounts of data involves using SNMP as a control channel in combination with other protocols defined for transporting bulk data. This approach is sub-optimal since it raises a number of security and other concerns. Transferring large amounts of configuration data via SNMP can be efficiently performed with several of the techniques described earlier in this document. This policy section shows how even greater efficiency can be achieved using a set of relatively new design mechanisms. This section gives background and defines terms that are relevant to this field and describes some deployment approaches.

7.1. What Is the Meaning of 'Policy-based'?

In the past few years of output from standards organizations and networking vendor marketing departments, the term 'policy' has been heavily used, touted, and contorted in meaning. The result is that the true meaning of 'policy' is unclear without greater qualification where it is used. [42] gives the term 'policy' two explicit definitions:
Top   ToC   RFC3512 - Page 52
   -  A definite goal, course or method of action to guide and determine
      present and future decisions.  "Policies" are implemented or
      executed within a particular context (such as policies defined
      within a business unit).

   -  Policies as a set of rules to administer, manage, and control
      access to network resources.

      Note that these two views are not contradictory since individual
      rules may be defined in support of business goals.

   As it pertains to our discussion of the term 'policy-based
   configuration', the meaning is significantly more specific.  In this
   context, we refer to a way of integrating data and the management
   actions which use it in such a way that:

   -  there is the ability to specify "default" configuration data for a
      number of instances of managed elements, where those instances can
      be correlated in some data driven or algorithmic way.  The engine
      to do this correlation and activate instances from defaults may
      reside in the agent or externally.  Where the representation of
      these defaults are in the MIB design itself, the object types
      supporting this notion are referred to as "template objects".

   -  the activation of instance data derived from template object types
      results from minimal activation directives from the management
      application, once the instances of the template object types have
      been established.

   -  somewhat independently, the architecture of the overall management
      agent may accommodate the definition and evaluation of management
      and configuration policies.  The side-effects of the evaluation of
      these policies typically include the activation of certain
      configuration directives.  Where management data design exposes
      template object types, the policy-driven activation can (and
      ideally, should) include the application of template object
      instances to the analogous managed element instance-level values.

   As it pertains to template object data, the underlying notions
   implied here have been prevalent for some time in non-SNMP management
   regimes.  A common feature of many command line interfaces for
   configuring routers is the specification of one or more access
   control lists.  These typically provide a set of IP prefixes, BGP
   autonomous system numbers, or other such identifying constructs (see,
   for example, [42]).  Once these access control lists are assembled,
   their application to various interfaces, routing processes, and the
   like are specified typically in the configuration of what the access
   control list is applied to.  Consistent with the prior properties to
Top   ToC   RFC3512 - Page 53
   define our use of policy-based configuration, a) the access list is
   defined independent from its point of application, and b) its
   application is independent of the access list definition.  For
   example, changing the application of an access list from one
   interface to the other does not require a change in the access list
   itself.  The first point just mentioned suggests what is necessary
   for template-based data organization.  The second suggests its
   application in a policy-based manner.

   Let us now examine the motivation for such a system or subsystem
   (perhaps bounded at the level of a 'template-enabled' MIB module,
   given the above definition).  Let us explore the importance of
   policy-based techniques to configuration specifically.

7.2. Organization of Data in an SNMP-Based Policy System

The number of configurable parameters and 'instances' such as interfaces has increased as equipment has become larger and more complex. At the same time, there is a need to configure many of these systems to operate in a coordinated fashion. This enables the delivery of new specialized services that require this coordinated configuration. Examples include delivery of virtual private networks and connections that guarantee specific service levels. The growth in size and complexity of configuration information has significant implications for its organization as well as its efficient transfer to the management agent. As an example, an agent that implements the Bridge MIB [24] could be used to represent a large VLAN with some 65,000 port entries. Configuring such a VLAN would require the establishment of dot1dStpPortTable and dot1DStaticTable entries for each such virtual port. Each table entry would contain several parameters. A more efficient approach is to provide default values for the creation of new entries that are appropriate to the VLAN environment in our example. The local management infrastructure should then iterate across the system setting the default values to the selected ports as groups. To date, this kind of large-scale configuration has been accomplished with file transfer, by setting individual MIB objects, or with many CLI commands. In each of these approaches the details for each instance are contained in the file, CLI commands or MIB objects. That is, they contain not only the value, and type of object, but also the exact instance of the object to which to apply the value. It is this property that tends to make configuration operations explode as the number of instances (such as interfaces) grows. This per-instance approach can work for a few machines configured by
Top   ToC   RFC3512 - Page 54
   experts, but there is a need for a more scalable solution.
   Template-based data organization and policy-based management
   abstracts the details above the instance level, which means that
   fewer SET requests are sent to a managed device.

   Realization of such a policy-driven system requires agents that can
   take defaults and apply them to instances based on a rule that
   defines under what conditions the defaults (policy) are to be
   applied.  A policy-driven configuration system which is to be
   scalable needs to expose a means of layering its application of
   defaults at discrete ranges of granularity.  The spectrum of that
   granularity might have a starting hierarchy point to apply defaults
   at the breadth of a network service.

   Ultimately, such a layering ends up with features to support
   instance-level object instance data within the running agent.

   An example of this kind of layering is implicit in the principle of
   operations of a SNMPCONF Policy-Based Management MIB [36] (PM-MIB)
   implementation.  However, other entity management systems have been
   employing these kinds of techniques end-to-end for some time, in some
   cases using SNMP, in some cases using other encodings and transfer
   technologies.  What the PM-MIB seeks to establish, in an environment
   ideal for its deployment, is an adaptation between MIB module data
   which was not designed using template object types, and the ability
   to allow the PM-MIB agent engine to apply instances of that data as
   though it were template-based.

7.3. Information Related to Policy-based Configuration

In order for effective policy management to take place, a range of information about the network elements is needed to avoid making poor policy decisions. Even in those cases where policy-based configuration is not in use, much of the information described in this section can be useful input to the decision-making process about what type of configuration operations to do. For this discussion it is important to make distinctions between distribution of policy to a system, activation of a policy in a system, and changes/failures that take place during the time the policy is expected to be active. For example, if an interface is down that is included in a policy that is distributed, there may not be an error since the policy may not be scheduled for activation until a later time. On the other hand, if a policy is distributed and applied to an interface that should be operational and it is not, clearly this is a problem, although it is not an error in the configuration policy
Top   ToC   RFC3512 - Page 55
   itself.  With this as background, here are some areas to consider
   that are important to making good policy configuration decisions and
   establishing when a policy has 'failed'.

   o  The operational state of network elements that are to be
      configured.

      Care should be taken to determine if the sub-components to be
      configured are available for use.  In some cases the elements may
      not be available.  The policy configuration software should
      determine if this is a prerequisite to policy installation or if
      the condition is even acceptable.  This decision is separate from
      the one to be made about policy activation.  Installation is when
      the policy is sent from the policy manager to the managed device
      and activation is turning on the policy.  In those cases where
      policy is distributed when the sub-component such as an interface
      or disk is not available, the managed system should send a
      notification to the designated management station when the policy
      is to become active or if the resource is still not available.

   o  The capabilities of the devices in the network.

      A capability can be almost any unit of work a network element can
      perform.  These include routing protocols supported, Web server
      and OS versions, queuing mechanisms supported on each interface
      that can be used to support different qualities of service, and
      many others.  This information can be obtained from the
      capabilities table of the Policy MIB module [36].

      Historically, management applications have had to obtain this type
      of information by issuing get requests for objects they might want
      to use.  This approach is far less efficient since it requires
      many get requests and is more error prone since some instances
      will not exist until configured.  The new capabilities table is an
      improvement on the current technique.

   o  The capacity of the devices to perform the desired work.

      Capability is an ability to perform the desired work while a
      capacity is a measure of how much of that capability the system
      has.  The policy configuration application should, wherever
      possible, evaluate the capacity of the network element to perform
      the work identified by the policy.  In some systems it will not be
      possible to obtain the capacity of the managed elements to perform
      the desired work directly, even though it may be possible to
      monitor the amount of work the element performs.  In these cases,
      the management application may benefit from pre-configured
Top   ToC   RFC3512 - Page 56
      information about the capacity of different network elements so
      that evaluations of the resources available can be done before
      distributing new policies.

      Utilization refers to how much capacity for a particular
      capability has been consumed.  For devices that have been under
      policy configuration control for any period of time, a certain
      percentage of the available capacity of the managed elements will
      be used.  Policies should not be distributed to systems that do
      not have the resources to carry out the policy in a reasonable
      period of time.

7.4. Schedule and Time Issues

This section applies equally to systems that are not policy-based as well as policy-based systems, since configuration operations often need to be synchronized across time zones. Wherever possible, the network elements should support time information using the standard DateAndTime TC that includes local time zone information. Policy- based management often requires more complex time expressions than can be conveyed with the DateAndTime TC. See the Policy-Based Management MIB document [36] for more information. Some deployed systems do not store complex notions of local time and thus may not be able to process policy directives properly that contain time zone relevant data. For this reason, policy management applications should have the ability to ascertain the time keeping abilities of the managed system and make adjustments to the policy for those systems that are time-zone challenged.

7.5. Conflict Detection, Resolution and Error Reporting

Policies sent to a device may contain conflicting instructions. Detection of such commands can occur at the device or management level and may be resolved using any number of mechanisms (examples are, last configuration set wins, or abort change). These unintended conflicts should be reported. Conflicts can occur at different levels in a chain of commands. Each 'layer' in policy management system should be able to check for some errors and report them. This is conceptually identical to programs raising an exception and passing that information on to software that can do something meaningful with it. At the instance level, conflict detection has been performed in a limited way for some time in software that realizes MIB objects at this level of resolution. This detection is independent of policy. The types of 'conflicts' usually checked for are resource availability and validity of the set operations. In a policy enabled
Top   ToC   RFC3512 - Page 57
   system, there are no additional requirements for this software
   assuming that good error detection and reporting appropriate to this
   level have already been implemented.

7.5.1. Changes to Configuration Outside of the Policy System

It is essential to consider changes to configuration that are initiated outside of the policy system. A goal of SNMP-based policy management is to coexist with other kinds of management software that have historically been instance based management. The best example is the command line interface. A notification should be sent whenever an out-of-policy control change is made to an element that is under the control of policy. This notification should include the policy that was affected, the instance of the element that was changed and the object and value that it was changed to. Even for those systems that have no concept of policy control, the ideas presented above make sense. That is, if SNMP co-exists with other access methods such as a CLI, it is essential that the management station remain synchronized with changes that might have been made to the managed device using other methods. As a result, the approach of sending a notification when another access method makes a change is a good one. Of course this should be configurable by the user.

7.6. More about Notifications in a Policy System

Notifications can be useful in determining a failure of a policy as a result of an error in the policy or element(s) under policy control. As with all notifications, they should be defined and controlled in such a way that they do not create a problem by sending more than are helpful over a specific period of time. For example, if a policy is controlling 1,000 interfaces and fails, one notification rather than 1,000 may be the better approach. In addition, such notifications should be defined to include as much information as possible to aid in problem resolution.

7.7. Using Policy to Move Less Configuration Data

One of the advantages of policy-based configuration with SNMP is that many configuration operations can be conveyed with a small amount of data. Changing a single configuration parameter for each of 100 interfaces on a system might require 100 CLI commands or 100 SNMP variable bindings using conventional techniques.
Top   ToC   RFC3512 - Page 58
   Using policy-based configuration with SNMP, a single SET PDU can be
   sent with the policy information necessary to apply a configuration
   change to 100 similar interfaces.  This efficiency gain is the result
   of eliminating the need to send the value for each instance to be
   configured.  The 'default' for each of the instances included in the
   policy is sent, and the rule for selection of the instances that the
   default is to be applied to can also be carried (see the Policy MIB
   module [36]).

   To extend the example above, assume that there are 10 parameters that
   need to change.  Using conventional techniques, there would now be
   1,000 variable bindings, one for each instance of each new value for
   each interface.  Using policy-based configuration with SNMP, it is
   still likely that all the information can be conveyed in one SET PDU.
   The only difference in this case is that there are ten parameters
   sent that will be the 'template' used to create instances on the
   managed interfaces.

   This efficiency gain not only applies to SET operations, but also to
   those management operations that require configuration information.
   Since the policy is also held in the storage for cross-instance
   defaults (for example, the pmPolicyTable in [36]), an entire data set
   that potentially controls hundreds of rows of information can be
   retrieved in a single GET request.

   A policy-friendly data organization such as this is consistent and
   integrates well with MIB module objects which support "summary"
   activation and activation reporting, of the kind discussed in Section
   3.3.5.



(page 58 continued on part 4)

Next Section