2.3.5 Distributed Management (disman)

NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 24-Jul-00

Chair(s):

Randy Presuhn <rpresuhn@bmc.com>

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>

Operations and Management Area Advisor:

Bert Wijnen <bwijnen@lucent.com>

Mailing Lists:

General Discussion:disman@dorothy.bmc.com
To Subscribe: disman-request@dorothy.bmc.com
In Body: subscribe disman your_email_address
Archive: ftp://ftp.peer.com/pub/disman/archives

Description of Working Group:

The Distributed Management Working Group is chartered to define an initial set of managed objects for specific distributed network management applications and a framework in which these applications and others can be consistently developed and deployed. A distributed network manager is an applicaton that acts in a manager role to perform management functions and in an agent role so that it can be remotely controlled and observed.

Distributed network management is widely recognized as a requirement for dealing with today's growing internets. A manager application is a good candidate for distribution if it requires minimal user interaction, it would potentially consume a significant amount of network resources due to frequent polling or large data retrieval, or it requires close association with the device(s) being managed.

The working group will limit its work to distributed network management applications where the main communication mechanism for monitoring and control is SNMP. Future work (and other working groups) may be chartered to investigate other distribution techniques such as CORBA or HTTP. The objects defined by the working group will be consistent with the SNMP framework. The working group will especially keep security considerations in mind when defining the interface to distributed management.

The working group will complete these tasks:

Define a Script MIB

Define a Scheduling MIB

Define a Threshold Monitoring MIB

The working group will consider existing definitions, including:

o RFC1451, The Manager to Manager MIB which was being considered by the SNMPv2 working group

o the RMON working group's work in this area

o the SNMP Mid-Level-Manager MIB which is now an expired Internet-Draft

o the work of the Application MIB working group

It is recognized that the scope of this working group is narrow relative to the potential in the area of distributed network management. This is intentional in order to increase the likelihood of producing useful, quality specifications in a timely manner. However, we will keep in mind and account for potential related or future work when developing the framework including:

o Event and alarm logging and distribution

o Historical data collection/summarization

o Topology discovery

Goals and Milestones:

Done

  

Post Internet-Draft for Threshold Monitoring MIB.

Done

  

Meet at the Montreal IETF meeting to discuss charter and review the Threshold Monitoring MIB Internet-Draft.

Done

  

Post Internet-Draft for Framework document.

Done

  

Post Internet-Draft for Script MIB.

Done

  

Submit final version of Threshold Monitor MIB Internet-Draft for consideration as a Proposed Standard. Submit updated versions of Internet-Drafts for Script MIB.

Done

  

Meet at the IETF meeting to discuss Internet-Drafts and issues that come up on the mailing list.

Done

  

Submit final versions of Internet-Drafts for Script MIB and Schedule MIB document for consideration as Proposed Standards.

Done

  

Agree on charter revisions for future work.

Done

  

Submit final versions of Internet-Drafts for Expression, Event and Notification MIB documents for consideration as Proposed Standards.

Done

  

Submit final version of Internet-Draft for Remote Ping, Traceroute, and Lookup Operations Using SMIv2

Done

  

Meeting in Oslo to discuss implementation and deployment experience with Schedule and Script mibs, identify any updates needed to these documents.

Nov 99

  

Submit updated Script and Schedule MIBs for consideration as Draft Standards.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC2591

PS

Definitions of Managed Objects for Scheduling Management Operations

RFC2592

PS

Definitions of Managed Objects for the Delegation of Management Scripts

Current Meeting Report

The DISMAN (Distributed Management) working group met on Monday, July 31, during the 48th IETF. This working group meeting was chaired by Randy Presuhn. There were approximately 80 people present. The agenda slides are available at ftp://amethyst.bmc.com/pub/disman/ietf48/ietf48-disman-agenda.ppt

This working group meeting was reported by Steve Moulton.

The first major item on the agenda was the usual administrivia. Juergen Schoenwaelder was recognized by the chair. Steve Moulton agreed to take minutes. Attendees were asked to sign the blue sheets. The agenda was reviewed, and no changes were requested. During the allocation of time, Sharon Chisholm requested 1/2 hour, Juergen Schoenwaelder requested 1/2 hour and Bob Cole requested some time to make a report from the RMONMIB working group.

The second major item on the agenda was the Status of Current Work. There are updates pending to the script and schedule MIBs, which were discussed later in this meeting. The notification/log MIB, event MIB, and expression MIB have completed IETF last call. The remote operations MIB is in the RFC editor's queue.

The third major item on the agenda was other work in progress related to DISMAN. There was a brief report on the RPERFMON BOF at the 47th IETF in Adelaide, where the idea of using synthetic sources for performance measurement was discussed. This work is now being examined in the RMONMIB working group. Bob Cole made a presentation (summarized below) on the SSPM framework. The SNMPCONF presentation was omitted; those interested were referred to the SNMPCONF Working Group meeting to take place later in the week.

Bob Cole made a presentation on SSPM (slides are available as ftp://amethyst.bmc.com/pub/disman/ietf48/sspm_p itts.ppt). The basic concept revolves around using synthetic data sources for performance measurement. Mention was made of the SSPM framework document (draft-cole-sspm-00.txt) and Carl Kalbfleisch's MIB document discussing how you might set up the probes (draft-kalbfleisch-sspmmib-00.txt). Mention was made (with out explanation of the acronyms) of several activities taking place in the RMONMIB working group, specifically, SSPM, APM/TPM, the use of the schedule MIB, and PMCAPS.

Bob presented presented several slides, including a fairly complex slide showing performance measurement architecture. In Adelaide, there were several issues presented using this architecture slide, including measurement and control protocols.

The IPPM (IP Performance Metrics) folks will talk about producing a new protocols for measurement and control.

No attempt is made to reproduce the slides here. One comment was made, whereby the full protocol stack requirement for SSPM has been declared a non-issue. Dan Romascanu discussed the Indexing and Distributing aggregation issues.

The fourth major agenda area was discussions on technical issues. The first item, closing remaining RFC2591 (schedule MIB) and RFC2592 (script MIB) issues, was presented by Juergen Schoenwaelder. The associated documents are draft-ietf-disman-schedule-mib-v2-01.txt and draft-ietf-disman-script-mib-v2-01.txt. The slides are in ftp://amethyst.bmc.com/pub/disman/ietf48/disman-issues.ps. No attempt to replicate the slides is made here. Juergen Schoenwaelder made the presentation.

Issue 04 (schedule MIB): the proposal to automatically disable failing schedules. [Names are given when the minute taker recognized the person asking questions. The dialogue has been edited some to reduce length.]

Russell Dietz: When does the script get turned back on?

Juergen: I don't know, probably never.

Russell: Will it be the default behavior to turn off the script after a certain number of failures?

Juergen:: No. The default will be to do nothing.

David Harrington: My feeling is that it should be a separate piece, as not everyone will want it. This may be a policy issue and therefore belongs in SNMPCONF.

Randy Presuhn: You have to appeal to a higher intelligence to both turn stuff off and to turn stuff back on. Any vendors have any comments?

Russell: There are a couple of products out there that have some combination of reporting the failure and stopping the script. You should probably report the failure and let a higher authority shut off the script.

Randy: is this a major or minor issue?

David H: this is a minor issue. Parts can be handled elsewhere.

Randy: Lets break this down. Should this capability be in the schedule MIB or in another special MIB?

(floor): we could do all of this in the script or event MIBs. The general purpose mechanisms are in place. Do we need to build special purpose mechanisms into the script MIB to do this?

David H: There are several issues that will come up on this that have not come up yet. How do you handle various success/failure patterns? There may be a lot more work in this than is apparent.

Russ Mundy: are people deploying this with nothing around it that can deal with failure?

(no response)

randy: Does anyone strongly believe we need to add this to this MIB?

(no response)

Bert: Should we recycle this document at proposed?

Randy: If we do not make this change, we can proceed to draft status. We will ask on the mailing list if there is any support for this. If not, then we will not do it.

Issue 05 (script MIB) is to replace the indices on the smLangTable and smExtsnTable with textual indices (by name). This would require the deprecation of these tables. Are the benefits worth the cost of the change?

The chair asked if anyone be upset if we did not change? (no response). This validates the consensus from the working group mailing list.

Issue 06 (script MIB): Dependencies between scripts and scripts versioning.

The MIB does not model inter-script dependencies (script b requires that script a is present and enabled) nor does it provide explicit support for multiple versions of a script. The comment was made that this problem probably belongs in the management station, not in the agent. David Harrington raised the point that some sort of version control can be done in the script naming, i.e. "script_1.1_for_IOS_v2.3" The agreement was to not change the tables.

Issue 07 (script MIB): Storage type of script code vs. script meta information. Is there a difference between the script storage type and the storage type of the script meta information?

Juergen: This is probably a documentation issue in the MIB.

Randy: There may be an association between the script table storage type and the persistence of the script itself. Clear as mud? (yes).

Juergen: we don't think this is a problem in the MIB definition, but in the documentation. OK with group?

(no response). General agreement is that it is OK.

Issue 10 (script MIB): Script editing in the smCodeTable.

The script MIB provides basic script editing capabilities via SNMP set operations. Implementation of the feature adds costs while the utility of this feature is questionable. [this is an enumerated value of the smScriptAdminStatus object -ed].

Should we try to simplify by taking this feature out?

There are known cases where this prevented implementation of the smCodeTable.

Randy: We should make the "editing" enumerated value of this object not necessary to claim conformance in the compliance statement. In other words, we would make the editing function optional. This wording will get set out to the mailing list for comment and approval.

Issue 11 (script MIB): Resource consumption indication in smRunTable.

It would be nice to have some sort of indication of this (cpu consumption or memory consumption). Is it possible to define metrics that are semantically meaningful and generally implementable.

Among other problems, this will require OS support and will be very implementation dependent. In particular, implementations that have all scripts executed by one script engine makes this information not available.

All possible solutions can be pursued without requiring modifications to the current document.

(floor): are you suggesting we have a script resource MIB later and let this document continue?

(there was no disagreement to this proposal).

Steve Moulton: When discussing this new MIB, we need to bear in mind that the unit of granularity may be the entire MIB engine.

Randy Presuhn: Yes.

Issue 16 (script MIB): Suspend/resume on runtime engines that do not support it.

The current specification says that the running script remains in the suspending (resuming) state when the runtime is not capable to suspend (resume) a script. This makes it impossible to determine on the manager side whether the suspend (resume) just takes a long time to complete or is not supported.

A solution would be to go from transient suspending state back into the running state when the runtime can not suspend a script.

Randy Presuhn: The issue is to disambiguate between something that takes a long time to suspend and the case where the script engine just cannot suspend the script. The suspend object needs to have a way to return the "can't suspend" case. Disambiguating into three cases

1) Engine just can't suspend script. Return error value to set. We can do this, no big deal.

2) Script just won't be suspended. Is this a real problem? No. This is a engine debugging issue.

3) Someone else reawakens script. (use access control, multiple manager-type solutions).

This item was brought to the working group's attention as the input from the mailing list was inconclusive. The sense of the room is that no action need be taken, but the question needs to be put to the mailing list for any final comment.

The next technical discussion item was a discussion of distributed active alarms by Sharon Chisholm. The slides are available as ftp://amethyst.bmc.com/pub/disman/ietf48/IETF48_DISMAN_presentation.ppt. No attempt to summarize the slides has been made here.

A draft of this work has been posted to the DISMAN mailing list.

One issue driving this work is that due to a trap storm or other events, alarms may be pushed off of the end of the notification/log MIB. The following questions were asked:

(floor): Are alarms associated with physical entities?

Sharon: Not necessarily. Alarms can come from logical devices, too. An alarm is anything you want to fix.

Randy: How do you decide what is interesting?

Sharon: There is currently no way to determine/filter.

(floor): How do you determine what alarms the device supports, and how do you determine what alarms you register for?

Sharon: This depends on the site.

There are several questions about deciding what notifications are active alarms.

(floor): Why is this in DISMAN?

Sharon: There is a industry requirement for this type of functionality, and we need a standard framework to deal with it.

The fifth agenda items have to do with working group business.

A charter update removing Bob Stewart [who has retired -ed] has been requested, as well as updating target dates for script and schedule MIBs. A working group last call for these MIBs starting September 14, 2000 was proposed without objection.

The issue of script MIB extensibility (RFC2593, experimental) was brought to the working group's attention to see if it required any action, such as moving onto the standards track. There were no comments, indicating that no action need be taken.

The question was raised about whether we take on alarms (cf. Sharon Chisholm's work). At least on person requests that we do. The issue of intellectual property in this work was raised. Sharon asserted that Nortel is working on releasing IP claims on the alarm MIB. David Harrington asked whether this is a DISMAN or a SNMPv3 issue? Russ Mundy responded that he was not sure, but that it looked like a general SNMP issue. David Perkins observed that there is a CMIP framework model that handles this problem, and, since this problem comes up so often, we ought to look into it.

Randy Presuhn stated that this will be taken to the mailing list, and advised Bert Wijnen to be prepared for a charter update for an additional work item. Bert stated that we need to decide whether this should go into DISMAN or SNMPv3. Dan Romascanu expressed interest in taking on this work. Upon request for a list of additional work items Dan Romascanu requested we look into synchronization with remote performance management, and a resource consumption MIB.

The final agenda item was Working Group meeting wrap up. A review of action items included:

Randy reminded note takers to follow the guidelines and presenters to submit their slides, and all participants to sign the blue sheets and return them.

Slides

Agenda
Distributed Management of Active Alarms
SSPM Generated Requirements
Revision of RFC 2591 and RFC 2592