Current Meeting Report
Slides


2.3.5 Distributed Management (disman)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 09-Nov-01
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://amethyst.bmc.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 which 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 architecture defined in RFC 2571. 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 Scheduling MIB

Define a Script MIB

Define a Remote Operations MIB

Define an Expression and Event MIB to support Threshold Monitoring

Define a Notification Log MIB

Define an Alarm MIB

The working group will consider existing definitions, including:

o the RMON working group's work in this area

o the Application MIB (RFC 2564), SysAppl MIB (RFC 2287) and related standards.

The work on the Alarm MIB will take into consideration existing standards and practices, such as ITU-T X.733. Whether any mappings to these other standards appear in the Alarm MIB or in separate documents will be decided by the WG. The WG will actively seek participation from ITU participants to make ensure that the ITU work is correctly understood.

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.
Done   WG agreement on direction regarding mappings to / from other alarm frameworks
Done   Submit updated Script and Schedule MIBs for consideration as Draft Standard (or recycle at Proposed).
Mar 01   decision on question of whether recycle the Log MIB.
Done   Submit updated draft of Alarm MIB for IETF meeting
Done   Submit updated draft of Alarm MIB for IETF meeting.
Oct 01   call for implementation experience and updates to the remote operations MIB.
Oct 01   call for implementation experience and updates to the Event and Expression MIBs.
Dec 01   WG last call on Alarm Management MIB.
Jan 02   Alarm Management MIB delivered to IESG for consideration as a Proposed Standard.
Internet-Drafts:
Request For Comments:
RFCStatusTitle
RFC2591PSDefinitions of Managed Objects for Scheduling Management Operations
RFC2925PSDefinitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations
RFC2982PSDistributed Management Expression MIB
RFC2981PSEvent MIB
RFC3014PSNotification Log MIB
RFC3165PSDefinitions of Managed Objects for the Delegation of Management Scripts

Current Meeting Report

Minutes for the meeting of the disman working group session at the fifty-second IETF meeting in Salt Lake City were reported by Dan Romascanu and fleshed out by Randy Presuhn.

No changes to the posted agenda were required.

The working group reviewed the status of its current documents. Ram Kavasseri gave a report on Cisco's implementation of the Expression MIB. Their implementation first shipped in December 1998, and was based on first draft of DISMAN expression MIB, rather than on RFC 2892.

Ram reported on Cisco's implementation of the Event MIB. They have implemented it on several platforms, and one customer is working to deploy it in a production network. The clarification questions that have arisen so far do not seem to require special clarifications in the MIB text. One difficulty that has arisen is that it doesn't provide a convenient way to apply thresholding for a range of ports. Ram took the action item to provide an example to the WG mailing list.

Ram also gave an implementation report for Notification Log MIB (RFC 3014). Cisco finished implementation two moths ago, product is not yet in the hands of customers. They only needed support for default log.

Named logs are supported in code but not enabled due to question regarding access restrictions. The chair clarified that only ordinary VACM access control needs to be taken into account when the log is polled. Ram took the action item to clarify this in the text.

The group reviewed issues from the mailing list regarding the Notification Log MIB. The sense of the room on the following issues was that:

- inform resends, if detected as such, are not added to a log;

- the question of whether adding a column to the nlmLogTable to report how many variable bindings are stored in nlmLogVariableType in order to reduce the number of queries needed for retrieval was deferred so that Sharon Chisholm could do the math so that the mailing list could discuss the cost/benefit ratio with numbers in hand;

- the question of adding a variable to indicate the current log index for each named log was deferred in the same manner;

- it was agreed that text be added to indicate that no access checks beyond those required by VACM need be done when log is polled;

- access efficiency of notification logs was discussed at length. Ram and Dave Perkins will get together to create an alternate MIB proposal for more efficient retrieval, prototype it, and test it in real life scenarios. If the result implies changes that prevent advancement, the priority is on providing the right solution;

- finally, the question was raised whether we should add an nlmLogConfigAgeout for each log? Since this is a new question, this will be discussed further on the mailing list.

The group spent a few minutes looking at new and related work from other working groups. The first was the question of persistancy and the use of the StorageType textual convention. This is not handled consistently in the Event, Expression, and Log MIBs, and needs to be fixed. Ram will develop specific proposals. The second point was that the DMTF event work, originally based on X.733, has added more probably causes. Andrea Westerinen was reported to have offered to forward these additions to the disman group.

Sharon Schisholm presented the status of the Alarm MIB work and reviewed the remaining open issues. A few questions arose during the discussion:
- does the new index in the Clear table indicate clear time? answer yes, keeps the index for correlation with original.
- do we want to add an example to illustrate the relationship to the event MIB? no.
- the discussion of EngineId vs. ContextEngineId was revisited, and agreed that although it might be relevant for the proxy case, the disctinction was ultimately more trouble than it was worth, and was consequently taken out of the MIB
- Discussion of the Telecordia model was tabled until information becomes available;
- Detecting Change of state - clarification of activeAlarmModelPointer is to be changed in 04 version of the document.
- Editors will do their best to issue the draft-04 next week, a Last Call will be issued for a longer period than usual, taking into account the holidays;
- Ram and Dave P. committed to read and review
- Randy will ask on the list for positive and negative feedback as well

Kam Lam led the discussion of the Condition MIB and ARC MIB draft.
He reviewed the changes from version 00 to version 01. The open issues include:
- terminology for condition to be taken on the mailing list, with Kam to initiate the thread;
- Alarm Raised and Clear should point to the Alarm MIB;
- Alarm type definition: it was agreed to delete section 3.2;
- Section 4.1 readability: text needs fixing, diagram should be taken out
- change 'clarification' in Section 5 that says that when a resource is in ARC mode active alarm information SHALL be available for retrieval by the managing system - change active alarm with condition information;
- section 5.1 - ARC impact on alarm notifications - needs to be further work on the mailing list;
- relationship with Alarm MIB - Sharon to propose text on the mailing list

Glenn Keni gave a brief review of the work on A Clustering Architecture for Replicating Managed Objects, a replication MIB for fault tolerance. Further discussion is invited on the working group mailing list.

The meeting concluded by agreeing that there was not yet sufficient implementation or deployment feedback to merit advancement of the Expression, Log, or Event MIBs at this time. The mailing list will need to discuss the progress of the ARC/Condition MIB to determine what to do about its target date.

Slides

A Clustering Architecture for Replicating Managed Objects
Alarm MIB (Generic & ITU)
RFC 2981 (Event MIB) Implementation Report
RFC 2982 (Expression MIB) Implementation Report
RFC 3014 (Notification Log MIB) Implementation Report
Condition MIB