The snmpconf (SNMP Configuration) working group meet on Tuesday and Thursday March 28 and 30 during the 47th IETF. Below are the minutes of those meetings. Special thanks go to Carl Kalbfleish and Shawn Routhier for taking a comprehensive set of notes during these meetings. Please also note that the presentations briefly described in these notes will also be published in their original form. These notes are a bit longer than usual since much of the question and answer discussion was not removed from these minutes in order to capture as much of the meeting as possible. This single set of notes documents the 3 different sessions the WG group meet in order. The first session began with a review of the agenda which included: Agenda Bashing Administrivia Overview of Approach break Document Status - editors Work to be done by the teams Q&A The proposed agenda for the Thursday meeting was: Review of Tuesday Policy based management MIB Technology specific (Differentiated Services) policy MIB Best Current Practices Document. Dave Harrington began with a review of the three main deliverables of the Working group: A Best Current Practices document on SNMP based configuration A MIB module to be used to facilitate policy based configuration A MIB module specific to policy based configuration of differentiated services. Proposed dates for two interim working group meetings were announced with suggested locations: May 17,18,19 interim meeting Boston June 28-30 San Francisco The goal of these meetings is to facilitate delivery of drafts for the expected July 14th ID cut-off in preparation for the July IETF Meeting in Pittsburgh. Dave Harrington then introduced the editor teams currently working on the documents: 1. Capabilities MIB Module - This has been renamed the Policy MIB Module. The editors are Steve Waldbusser, Jon Saperia and Thippanna Hongal. 2. Differentiated Services Policy MIB Module - The editors are currently David Partain and Harrie Hazewinkel. 3. Best Current Practices Document for SNMP-based configuration - The editors are Mike Macfaden and Jon Saperia. The mailing list information was presented and is: General Discussion:snmpconf@snmp.com To Subscribe: snmpconf-request@snmp.com In Body: subscribe snmpconf Archive: snmpconf-request@snmp.com (index snmpconf in body) Jon Saperia began with a presentation that described the general background and goals of the working group and an overview of the current SNMP architecture and how SNMP based configuration fits into that architecture. The benefits of this integrated approach were also described. The general architecture includes a policy MIB module used by systems to advertise their capabilities (such as support for differentiated services) and the types of roles they support such as interfaces that carry traffic from executive offices. The working group is also undertaking the development of a Differentiated Services Policy MIB Module as an example of how such a module can be combined with the general Policy MIB module as a means of aggregating configuration commands in complex technologies. It is optional and up to the various technology experts to determine if such a module is necessary. These two modules, the Policy MIB Module and the Differentiated Services Policy MIB module (which is used as an example for further work that other WGs interested in other technologies may use) are designed to work with the many, many thousands of MIB objects currently defined. These new MIB modules are 'layers of abstraction' on top of the basic objects which have been and will be defined. The presentation continued with an overview of the steps for configuration that would occur in a system with these capabilities: 1. The technology specific policy subsystems would register with the policy module their capabilities. They are expressed in terms of policy type and subtype MIB Objects. 2. The manager(s) would then be able to determine system capabilities (web server, vpn support diff serv, mpls, etc.) 3. Managers define roles and associate them with specific instances in specific devices. 4. Managers send policies to managed devices such as: traffic from interfaces for executive offices need to be marked such that they are given preferential service. 5. Managed devices evaluate the policy filter and policy action MIB Objects (the two parts of a policy sent to a managed system) to determine where and when the policy is applied. 6. The technology specific module sets all necessary values to the instances which have evaluated as belonging to 'rule' expressed by the policy filter in the policy MIB Module. Randy Presuhn asked: How does one know the interface is an exec type when things are evaluated. Jon Saperia: Indicated that such information would need to be marked, most often this would require human intervention. 7. A technology specific policy MIB module may not always be required and the general Policy MIB Module may be able to fully express the details of the action to be performed without further expansion in a technology specific policy MIB Module. 8. The management software monitors usage and status to refine policy or verify changes. The meeting continued with a presentation of the Policy MIB Module by Steve Waldbusser. Policy based management provides a method of aggregating management operations and applies them globally to all elements that share certain characteristics. Policies are in the form of if (element has certain characteristic) (then do something) Examples if (it is fast ethernet and is a trunk) then (apply full duplex mode) The Framework: Policy specification exists in a policy server SNMP is used to move policy to the Policy MIB Module How the policy is instantiated in the managed system is implementation specific. A policy is a filter and action pair as described above. The intention of this architecture is to leverage extensive MIB based infrastructure. Filters can use objects to determine what to do. Actions can use objects to cause the action to be realized in the managed system. The Policy MIB Module requires: 1. The Core Architecture 2. The policy table that contains objects for communicating policies 3. Policy filter language. 4. SNMP based support infrastructure The Policy table contains: - filters and actions would probably be octet strings - description - more information about the policy these descriptions which can contain operational 'clues'. policyMatches - number of current matches, useful for debugging Policy filter language need to define a way to express a filter and action Other tables/features in the Policy MIB Module: role table, capabilities, time. About Roles: Some necessary concepts for policy have never been described in MIB objects so we need to add them ourselves. Roles can be political (is exec, outside contract), financial (gold contract), legal (lifeline) or geographical (California, insecure conduit), or engineered (backup, trunk). A table is required for the down load of this information, thus the roleEString table. Capabilities Table: The capabilities table allow managers to know what types of policies or configuration operations are supported in the managed elements. Time: policies may need to be executed only at certain times so we need time controls. We need to provide two views of time: globally consistent (UTC time) and local "business time" (MF 9-5 local time). Operational Considerations: - Policy creation: need to allow an engineer to debug a policy - Policy actions can be debugged in a lab (may be provided by a vendor or other as a library of commands) - Debugging of policy filters consists of ensuring that the filter selects the intended set of elements. (need to provide some way of getting feedback) - Need to see where a policy would be executed - table that shows where a policy is executed. Advantages of the approach: built with existing infrastructure and tools, leverages existing MIB Modules, flexibility, complete architecture, includes operational tools. After the presentation by Steve there were a number of questions and answers. Note that some of the questions are not really questions but statements of opinion. They are included here as questions (Q): Q. SNMP can be used to communicate a policy language to device. Many ways to do such communication, have the requirements for real time, reliability, etc. been considered? A. These have been thought about but it is a longer list and should be taken to the mailing list. RFC1270 may have some helpful information. Q. Have they thought about secure source of time? Policies may be pushed early and scheduled for activation at other times. This may require secure time on the local system. Q. Examples seem to be interface based, but much of the policy questions would be based on other items such as class or type of traffic. A. This is simply an artifact of the examples Many things would be available, in the particular example there would need to be a traffic classifier. Q. Policy may need to be applied to something such as all traffic to/from an IP address. Policies seem to attach to something in a device. We may want to attach policies to other items such as IP addresses which will go across larger structures (entire networks). A. Confusing taxonomy: in this particular case policy is being overloaded. Q. What is the difference between policy MIB and the PIB A. [Editorial comment from Jon Saperia who edited these notes - while both items are still in development it is difficult to make exact comparisons especially when which PIB we are speaking about is not specified. In general, if one thinks of the Policy MIB modules under discussion as providing an aggregation of configuration commands, then there is probably some similarity. The Policy Module accepts aggregated commands that are expanded locally on the managed element. This is what happens when a policyFilter is expanded to provide all the instances to which the policy action is to be applied, and the technology specific Policy MIB Modules expand the configuration command (policyAction) of say provide EF PHB to a particular DSCP value, to the many parameters needed to cause each interface selected to provide the desired behavior. Not that the Policy MIB Module also contains the expression of the Roles and Capabilities of the device which in a PIB environment would be conveyed by other means.] Q. Randy: jump up several layers of abstraction talk about configuration mgt. but this isn't configuration management, these are aids for configuration tools. For example this doesn't give any sort of version control of configuration mgt. A. Steve: different view of configuration management, we are providing the tools for helping out with configuration Follow up question by Jon: would provisioning be a better term? Randy said no. Q. Some items that are general vs. some items that are unique per system how will they be handled A. Roles (which are handled by humans) can be used to handle such items there may also need to be consistent filters etc. Such a scheme may result in an explosion of roles which could be expensive and so needs to be controlled. Q. Does this mean you will need to configure something to configure something (configuration role to configuration parameter)? A. Well yes, but you would only need to configure the role once and this may give you other features. Jon: clarification: For those items that may be easy you can just touch them directly rather than go through the role and rules. [Jon's added editorial clarification - this means that for simple configuration operations like changing an IP address, it is not necessary to use any of the mechanisms discussed thus far. It is still possible to use basic SNMP set mechanism to change any instance specific objects desired with no additional overhead.] Q. How does this connect to the policy working group. A. This work attempts to use the work in the policy WG as the base info that would be fed into things. Q. The filter/action is similar to some of the work in the policy WG but not exact. will this be a problem. They are not meant to be direct connections but are meant to be connected. Q. Configuration management is challenging task for ISP . What to keep track of what the object should look like vs. what the network is. By using MIB objects as storage are you not seeing what the network is, rather than storing what it should be. The aggregate that they are probably using are similar but are not being used in real time? Take to mailing list: How to deal with large batch of objects, How to store information about networks, How to capture design rules for network Q. Set the record straight about the meaning of policy. Doesn't think that policy is an aggregate of configuration. Policy framework talks about abstraction rather than aggregation. By using an improper definition for policy this may be different than policy framework. Suggestion that there are flaws in the scheme, the discussion focused on the little things. But we need to discuses the big things. SNMP has a known feature set that may not be proper for use as configuration mgt. Attempt to push to much information and capability down to the device. Reliability, fault tolerance Bad thing for the device to know to much of the policies, as this may require too much update. A. Take to the mailing list. The next presentation on the agenda was from David Partain on the Diffserv Policy MIB Module Current status: A skeleton that still needs to be filled in and input from the community is desired. Input to our effort has thus far come from: PIB work in the rap and Diffserv WGs, goals are similar to the PIB work but without using a new framework Goals of the Diffserv policy MIB module: - network-level policy based configuration of elements supporting diff serv - to provide a level of policy abstraction above the diff serv MIB module mapping tables - diffserv configuration template - tables to map between the goal of policies and the implementation of configuration an addition to the table won't cause changes, but an use of that policy will cause the configuration to be updated. Input to and output form the diffserv policy MIB module: - Manger may speak directly to the diffserv MIB, diffserv policy MIB module may be viewed as similar to PIB Q. Work done in policy group is a high level model of how things should work. A. Two different middle layers with upper and lower systems the same in concept. Believe that the IETF should examine why the two are different should find the conceptual differences between the PIB and the policy MIB module as this will give us good information for solving the problem Agreement from Dave that this is a good idea and that we should try to reduce the difference and hopefully come up with a single solution. David Perkins: comment to let the market decide. What's to be done - what are the abstraction needs - understand what can be or needs to be abstracted from the diff serv MIB - relationship with the policy based management MIB - put meat on the skeleton - alignment with other WGs Input from the community desired - snmpconf WG input - diffserv, policy, rap - diffserv abstractions - policy based management application developers Upcoming Milestones - post draft during next week - collect WG input - revise and post draft by Friday before interim meeting Q. Should Relationship between multiple MIB modules be standardized? A. Interrelationships will be via shared indices and probably not be full blown interfaces. Q. Has the overhead been calculated for how much this would cost. Concern that this will be expensive. This may be caused by a misunderstanding of the policy and should be taken to the list. Will there be a space crunch or will this thrash? Q. Will it be possible to have conflict between the MIBs A. Yes Q. Will there be conflict resolution. A. Yes, there doesn't seem to be any around it. The next presentation was on the Best Current Practices Document by Mike Macfaden: Presentation Topics - review problem statement - goals - requirements: user vendor - review Best Current Practices draft - review further work items Goals of BCP: Document existing knowledge and techniques which demonstrate effective use of the SNMP framework for configuration. Requirements/User: - secure authenticated access - fine grained access control - standards based - integrated view of configuration status and diagnostic info - the configuration method should not obscure what is being configured The presentation continued with a discussion of service provider requirements and the basic outline of the BCP document with some example suggestions. Tasks to be done for the Document: April - collection of info and best current practices on the mailing list - produce new draft for upcoming may meeting May - revise based on feedback compiled for 17-19 May June 28-30 - revised based on May meetings and further development Q. Seems that the best current practices goes beyond configuration is that correct? A. No. It is not the intent to go beyond configuration but there may be connections elsewhere, the particular question asked about notifications which might get involved as part of a configuration change notification. Q. Does [this work] include network wide configuration issues as well as day to day type of things. A. Yes. Q. COPS has a clear ownership for a given policy or area, having multiple managers will make this more difficult do we want to discuss it. A. The design team believes that multiple managers and interfaces will be useful/required. The meeting now turned to setting up the agenda for the Thursday meeting which will look at some of the documents in more detail. The order will be: - BCP - diff serv policy MIB module - policy MIB module Thursday March 30th Meeting. The meeting began with a discussion led by Mike Macfaden on the Best common practices document. The outline was reviewed and a call for contributions was made. Trying to get this done in a month or so, April will be busy (hopefully) Document is still young and looking for contributions BCP outline Tenets must deal with Murphy's effects, the network may be unstable at times even while configuration is happening. Undocumented defaults are bad. MIB design - the following are some example issues about MIB Module design that are targeted for inclusion in the BCP. Large amount of power available in SMI, must select the proper abstraction - may be able to use some metrics to determine if the abstraction is correct - number of objects to change, rate of change of those objects higher level error information at the application level is helpful and can be contained in MIB objects. Information about this should be in the BCP. Include some support for diagnostics to help debug things trap throttling and higher level decisions to send/not send traps persistence - how the various protocols will play together with objects tagged as read-only etc. Other general problems/benefits of having multiple management interfaces Management system design Need to show examples of things like AC and sysOR table such that agents do them properly and that managers know what they can do do with them and how they might do so. Possibly try and connect the fault system with the configuration system such that folks (users) may be able to understand that "this section of the net is under construction and may be less than smooth" Comments: GWW - any clarifications that we find should also be reflected back in the base docs that cover that area. Q. Why is policy related stuff in the doc A: As we add network wide management we may need more information and practices so that users have a general understanding of how to perform these functions with SNMP. There were multiple comments about usefulness of the work. Unknown comment- Policy is an overloaded term. Suggestion that as we move forward we more clearly define policy high level description of the policy stuff policy vs. policy rules vs. device stuff. Bert - Terminology is being handled in other WGs probably part of the policy framework WG (and charter). The next presentation was on the Differentiated Service Policy MIB Module and was lead by Harrie Hazewinkel. Rather than using the Differentiated Services MIB Module which is very complex, Harrie created a wwwPolicy MIB Module as a way of presenting the relationship that exists between the Policy MIB Module, the Technology Specific Policy Modules such as the Policy MIB Module Differentiated Services and the device/instance specific MIB Modules. Example scenario uses policy MIB, wwwbwpolicymib and wwwbwmib - wwwbwmib would probably already exist as part of other work. - policy MIB includes the filters and actions - The wwwbandwithpolicymib subsystem registers it's capability with the capability table of the policy MIB Module - the manager can then read the table and start configuring the wwwbwmib table and the various roles that may exist (this is defining the services and associating as necessary) - The policy table then is configured to map things and the wwwbwmib is updated as necessary Q. Andy - without some more details this example doesn't allow for much discussion. Unknown - perhaps we should use OIDs rather than octet strings to allow for better filtering. A. Dave Partain - Understands that this isn't most useful but this is mostly trying to show an example of sequence of events and the connections between the tables. Many people still have some difficulty understanding the example of how things should work, etc A. Randy - was able to understand it (he thinks) Q. What happens if somebody adds entries to the device table after the policy has been "activated" should such new rows be subject to the policy? A. Dave Partain - need to look at that issue - this is all part of allowing multiple interfaces/managers and we may need some extra work/objects to make it function (timestamps etc). Q. Randy - If we are doing configuration automation then the new objects wouldn't need to be updated. If we are doing policy automation then the new object would need to be updated. We need to be clear on what we are trying to do. Q. Andy - Another vote for understanding the example, with a suggestion to try and keep things simple and not get bogged down in the details. Q. unknown - this is one way to give a standard way to access a bunch of device specific information. [Editors comment - The above question is important since it correctly captures an essential component of policy based work. That is that different levels of abstraction are needed. In the SNMP environment this concept can be powerfully used since access based on a user's role (such as administrator) can be controlled quite well. For example a less 'skilled' individual may be able to turn a policy on and off as required. This would require access only to the Policy Module. A more 'experienced' individual might be given access to the technology specific MIB Modules such as the example WWW Policy Module Harrie presented above. The most skilled might be allowed to access the device specific details and modify them. Examples include the Differentiated Services MIB Module currently under discussion in the Differentiated Service Working group. unknown - multiple interfaces may lead to difficulties Q. Dave Perkins - no magic in SNMP, SNMP and MIB modules are just one way to move information the magic occurs in the other functions as they try and do something with that MIB data. Q. Jeff Case - identified one area that needs work, when multiple layers are able to manipulate the same data via different routes how do we choose which setting "wins" is it last one wins or higher authority wins or some other option. This also includes such questions as what happens when a policy has caused a change in lower layer tables - should the table be reverted when the policy is removed (or expires) etc. Q. John S. - One approach that wasn't mentioned previously - some other groups couldn't see a way to deal with the multiple manager problem. They used a new object to specify who has control Q. Jeff Case - this doesn't solve the problem, it simply moves it. What happens when control changes hands - should changes revert. Q. John S. - a solution to this problem may be intractable and at least should be in it's own RFC Q. Jeff Case - if we only allow them serially then we must disambiguate rules during change over if we allow them in parallel then we must disambiguate rules in real time. Q. John S - should this be a separate work area Q. Jeff Case - must be careful to avoid biting off too much and should try to solve the problem that we understand and that we can. Expansion in the future would be good. Q. Andy - Any solution will need to cover the multiple manager interface and multiple layers. Q. Randy - This discussion may be pushing to attempt to much too soon, doing some of the other steps first may make solving this type of problem more tractable. 1) the current work is doing well at capturing what you want your configuration to be 2) the next step should be to figure out what you currently have 3) the third step would be to make the current configuration match what you want 4) this discussion seems to be going beyond the 3rd step. Q. Jeff case - sounds like Randy is discussing new configurations available on reboots. Q. Randy - that is not what I meant, restate of his points above Q. Dave Partain - disagrees about where we are starting and thinks that we are starting at the early steps that Randy mentioned Q. Jeff Case - difficulty in exceptions - we want a general policy but with some exceptions the difficulty is how to define when the exception should be corrected and when it should be left as is. Q. Dave Perkins - some information/objects may only be available via certain interfaces, some from CLI, some from SNMP etc. A policy manager may need to be able to access multiple interfaces Q. Unknown - The policy description is good even if it isn't used to drive the object setting directly. Q. Dave Partain - will try and update things to be a little more "real" The final discussion of the day was lead by Steve Waldbusser on the Policy Based Manager MIB Module - We are building an infrastructure - We can use small building blocks, e.g. use MIBs (which may be already available). - need to add some pieces - role table - - capabilities table - used to allow managers to understand what they have to work with. - time objects - Policy Table: - simple SNMP table with octet strings for filters and actions - also includes description string, this string may be carried along through translations to more device/mechanism specific Q. Randy - Does the expression evaluation happen at a point in time or does it cover all objects? A. It covers all objects. Q. Are there constraints on objects in policy actions? A. There are no constraints. A policy action can touch any object it wants/needs, at least in theory. The two of these may lead to cycles where one policy action cause the firing of another policy filter/action. Is there any method to keep this from being infinite (no, this problem doesn't seem to be of major concern). Q. We may not have a problem with the multiple managers, if we do we can add owner strings or some other feature to prohibit this function. Q. Randy - may need owner strings to allow VACM to work with a reasonable number of entries Q. Andy - conflict resolution, who is responsible for finding conflicts in the table? A, Steve - first need to start determining what conflicts are real and some work is needed here. Q. Andy - will policy matches be tractable or will the entity need to spend a lot of time to do the updating. Q. Andy - need to formalize the octet strings for filters/actions (agreement) Q. Jeff case - does conflict resolution need to be handled for both policies from the same source or different sources, conflicts are not necessarily bad as long as there is a precedence order to resolve them Q. Andy - but we don't want the device spending all of it's time resolving them. Q. John - describe some of what happened in the policy groups when they looked at some of these problems, currently work in the policy group on information model and schema but not on the language Q. Steve - details of the language are not important yet, figuring out above that what sort of conflict resolution we are going to use is. Q. John - need to get some of the requirements before trying to write a language Q. Randy - some of the language type issues have been solved in ISO/ITU land several years ago and isn't necessarily that difficult. Is not sure that we need conflict resolution, but we would need to be careful about how often/when we do filter checking and actions. Q. unknown - suggestion to leverage the work done in the policy group especially for policy servers which can be gotten from elsewhere. Q. unknown - why is policy stuff in SNMP A. Steve - this is a policy based configuration using SNMP Q. Andy Bierman - lots of work to describe all the details, execution environment, languages etc. After this series of questions and comments Steve continued with: Policy Filter Expressions The expression details are: - Implicit SNMP retrievals - wildcarding - need to avoid locking information down to specific instances - assessors calls to retrieve data in a convenient way, small # to be defined Role Table: Two tables roleEStable and roleSEtable, one is a mirror of the other to allow the indexes to be flipped. -- roleSEtable Can this be used for substring matches? Parameter to choose substring match or exact. -- Accessor Function: Some work is necessary to decide what sort of accessor functions we may need and what the functionality would be. Capabilities table: Type defined by WG so all managers can understand them sub type allows implementers to add more specific info. More Discussion follows: Question about the type/subtype tags and if the typing will remove some of what an implementer could do. A. This is an attempt to give some structure to the list, the example may be a little off in specifics but does bring up the question of where one draws the line - should Pentium be a type or should it be something more general, should WFQ (weighted fair queue) be a type or would that be a subtype of some other concept More work is required in this area. Q. Andy - the sub type should perhaps be removed from this table and left for the enterprise to put in via an augments. Q. Andy - what about agent capabilities? A. Steve - The agent capabilities macro is not designed for this, designed for MIB compliance stuff. A. Jon - mentions the technology specific modules contain some of the details. For example in the differentiated services policy module only the types of queuing methods supported by the device would be populated in the table. Q. Andy - why not find the info from the diffserv MIB A. Steve - attempt to make it easier to figure out what other policies may be necessary - this brings the info into one place. Q. Dan - need to include some concept of device limitations on execution items - for example perhaps limiting the number of rules that may be executed at a given time which may be different than the number stored. unknown - still need to work on levels of abstraction across all of the work, at the highest level the device capabilities shouldn't need to be known, this should be something that comes in at a lower level. Steve continued the presentation: Time Time needs to be accessible and may need universal as well as local three choices: policy calendar pointer - rfc2591 accessor function multiple MIB objects Q. Andy - this group may decide to avoid time or may have a bunch of discussion that has already been happening in the other groups, (note conflict resolution becomes more difficult with time based stuff) Q. John - there seems to be several problem areas when dealing with time The presentation concluded with the following table: pmPolicyDebugPETable Operational Requirements Table to show what policies are/would be used on elements to allow the operators to debug things - before the polices go out to see what would be affected - when the policy is in use to see what is affecting things and to turn some off if necessary. Q. Andy Bierman - seems to be moving more to policy based rather than configuration and thinks that we shouldn't be redoing the work that the policy groups have been doing. Wants the outcome to be modular such that some pieces (the configuration stuff) can be used on its own. Bert Wijnen, our AD, made some closing remarks. He indicated that he was pleased with the lack of heated fights and with the progress in the various groups as well as people from the various groups getting together.