1. Configuration Management With The Internet-Standard Management Framework Jon Saperia saperia@mediaone.net Adelaide IETF March 2000

2. Background/Goals Document existing knowledge and techniques regarding effective mechanisms for device-specific and policy-based configuration. Leverage considerable experience and fielded implementations of SNMP-based management.

3. Background/Goals Continued This discussion is made possible through the enabling technology - the SNMPv3 framework that allows safe sets. Add components (MIB Modules) to Internet Standard Management Framework to improve device and policy-based configuration management with SNMP. Provide an example for policy-based configuration management with SNMP that illustrates the principles.

4. Benefits of the Approach Scope –Device-specific configuration –Network-wide configuration Power of rules and roles Abstraction level –Low: individual objects and instances –High: collections of objects Consistent with existing investments

5. Architectural Introduction: Three New Documents Best Current Practices - how to effectively perform device and policy-based configuration management. Policy-Based Management MIB Module Technology-Specific Policy MIB Modules … plus other Standard and Vendor-Specific MIB Modules

6. SNMP Architecture Management Application(s) Managed Elements SNMP Agent The MIB i.e., MIB Modules

7. The Architectural View This is a simplified view of the architecture. The architecture includes the usual suspects of command generators, command responders and notification originators.

8. Policy-Enabled SNMP-Based Configuration: Architecture Management Application(s) Managed Elements SNMP Agent Policy-Based MIB Module The MIB i.e., MIB Modules

9. Policy-Based MIB Module One could think about this as mid level managers that are embedded inside the devices Gives you the power of rules and roles and thereby giving you network-wide versus element by element and device-wide versus instance specific configuration.

10. Policy-Based MIB Module Continued We chose to have one of these there could be many of them. We think there are several advantages of having one. That does not prevent us having more than one in the future.

11. Policy-Enabled SNMP-Based Configuration: Example 1 Management Application(s) Managed Elements ifTable SNMP Agent Policy-Based MIB Module

12. Two Levels of Access There are multiple levels of abstraction - exposed to the administrator - operators may have access to one level and the engineers may have access to another. Policy based configuration/configuration of policy.

13. Policy-Enabled SNMP-Based Configuration: Example 2 Management Application(s) Managed Elements Diff. Serv MIB Module SNMP Agent Policy-Based MIB Module Diff. Serv. Policy MIB Module

14. Multiple Levels of Abstraction We have both scope and abstraction And multiple levels are exposed for different operational personnel.

15. Technical Overview Technology-specific Policy subsystem registers with policy module (capabilities type and sub type) Manager then ‘knows’ system capabilities (e.g., WEB Server, VPN Support, Diff Serv, MPLS) Managers define Roles and associate them with specific instances in specific devices Managers send policies to managed devices

16. Technical Overview - Continued Managed devices evaluate the PolicyRule and PolicyAction to determine where and when the policy is applied. Policy-specific module sets all necessary values either directly, or, if present, via instance specific subsystem.

17. Technical Overview - Continued Policy MIB Module does not require policy-specific modules. Management software monitors usage and status to refine policy or verify policy changes.