2.4.10 Physical Topology MIB (ptopomib)

NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 03-Nov-97

Chair(s):

Ken Jones <kjones@baynetworks.com>

Operations and Management Area Director(s):

John Curran <jcurran@bbn.com>
Michael O'Dell <mo@uu.net>

Operations and Management Area Advisor:

John Curran <jcurran@bbn.com>

Mailing Lists:

General Discussion:ptopo@3com.com
To Subscribe: ptopo-request@3com.com
Archive: ftp ftp.3com.com (login: ptopo, passwd: ptopo)

Description of Working Group:

Document Editor: Gilbert Ho (Gilbert_Ho@3mail.3com.com)

The goals of this working group are:

o to agree on and document the common framework/model for discussing physical topology o to standardize a set of managed objects that provide physical topology information o to document media specific mechanisms to communicate topology information.

The managed objects should provide sufficient information to allow a management workstation to navigate across a set of agents in order to learn the topology of arbitrarily large networks, and these objects should be as independent as possible from the specific underlying networking media which comprise the network. These objects will be the minimum necessary to provide the ability to support the physical topology discovery, and will be consistent with the SNMP framework and existing SNMP standards.

In defining these objects, it is anticipated that the working group will leverage existing work for representing port-based information, such as in the Repeater MIB (RFC 1516 or later) and may also leverage work in the entity MIB for describing logical and physical relationships.

The working group will define the general requirements for topology mechanisms in order to support the proposed MIB. It will also identify existing topology mechanisms for common LAN media types and may propose new topology mechanisms for LAN media types where required. It is a goal of the common topology MIB to allow the use of either standard or proprietary topology mechanisms within the underlying media.

At this time, it is not a goal of the working group to support the collection or representation of logical topology information, such as VLAN configuration or subnet structure. It is anticipated that this could be an area for future work items, so some consideration will be given to extensibility of the models and to the MIB. However, this consideration must not be allowed to impede progress on the primary focus of physical connectivity.

Goals and Milestones:

Oct 96

  

Working Group formation approved by IESG Solicit input (proprietary MIBs, model)

Nov 96

  

Hold Interim meeting in San Jose

Nov 96

  

Post Internet-Draft for topology MIB

Nov 96

  

Post Internet-Draft for topology model

Dec 96

  

Working Group meeting at IETF-San Jose to review the initial IDs

Feb 97

  

Post revised Internet-Draft(s)

Mar 97

  

Review Internet-Draft(s) at IETF meeting

Jun 97

  

Submit final version of Internet-Draft(s) to IESG for consideration as a Proposed Standard

Internet-Drafts:

No Request For Comments

Current Meeting Report

Minutes of the Physical Topology MIB (PTOPOMIB) WG

Chair: Ken Jones

Reported by: Andy Bierman

Summary

The PTOPOMIB WG met at this meeting to advance the documents in progress, the PTOPO MIB and the PTOPO Discovery Protocol (PDP).

A 'page by page' review of the documents was conducted. The sections below contain a summary of every issue raised in each of the two documents.

Most issues were resolved, and the next set of drafts are expected to be the final versions before a "WG Last Call" is held.

Agenda

Document Reviews:
draft-ietf-ptopomib-mib-01.txt (PTOPO MIB)
draft-ietf-ptopomib-pdp-01.txt (PDP Protocol and MIB)

I. PTOPO MIB Review

Sec 2.) Update boiler-plate text

The introductory text describes the SNMPv2 SMI, and should be updated to mention the SNMPv3 framework.

Sec 3.4) Clarify design goals

The bullet on 'Partial Topology Support' says a PTOPO agent keeps information derived from the "best" source. This will be clarified to indicate that redundant information is okay, and an agent does not have to remove "good data" when adding new information. However, an agent should not present topology information known to be incorrect.

The bullet on 'Agent Location Neutrality' will be removed, since the working group decided not to develop a MIB to support both the Topology Agent and Topology Server functions.

Sec 5.2 and 5.3) Mandatory Entity MIB and Interfaces MIB Support

A suggestion was made to decouple the identification of physical components from the Interfaces MIB and Entity MIB, and allow proprietary identifiers instead. After much debate, the WG decided not to change this requirement, but clarifying text will be added to these sections, to indicate the level of compliance required for PTOPO MIB support.

p. 18 - PtopoAddrSeenState TC) Clarify Enumeration Semantics

The TC will be clarified to indicate that an agent maintains a 'best effort' approach. The agent must have some internal information to justify changing the "AddrSeenState" from the value 'unknown(2)' to either 'one-addr(3)' or 'multi-addr(4)'.

p. 19 - ptopoConnTable DESCRIPTION) Incorrect Text

The text states that the table contains one row per physical entry. This will be changed to "one or more rows" per physical entry.

p. 21 - ptopoConnIndex DESCRIPTION) Index Reuse Issue

A long discussion on the index reuse issue was held. Either an index value must be reused (e.g., relearn a connection, so reuse the old index), may be reused, or must not be reused between reboots.

Resolution: No semantics are attached to the ptopoConnIndex, so index values may be reused between reboots. An NMS should not assume a particular ptopoConnIndex value maps to a particular remote port (e.g., even columns such as ptopoConnRemoteChassis can change).

p. 27 - ptopoConnTabReplaces object) Useless Counter

It was decided that this counter will be incrementing too often to be useful, and it will increment as a result of normal operation of a PTOPO agent. This counter will be removed.

p. 29 - ptopoConfigChange NOTIFICATION) Trap Throttling

A debate was held over the throttling behavior for this trap. At issue was the default throttling interval (5 sec.) and whether this should be a configurable parameter instead of a constant.

The notion of a "startup quiet time" and a "reconfig quiet time," i.e., different throttling intervals based on 'condition', was discussed.

Resolutions: A r/w MIB object will be added to configure the throttling interval, which also replaces the 'ptopoConfigTrapsEnabled' MIB object. The range of the new MIB object will be (0 | 5..3600) seconds. The DEFVAL is zero, which means transmission of the trap is disabled by default. It is suggested that the interval be set to 60 as a default, when transmission of this notification is enabled.

General PDP Dependencies

There are several places in the document where the PTOPO Discovery Protocol is used as an example of a protocol suitable for supporting the PTOPO MIB. Clarifying text will be added as appropriate, to indicate that PDP implementation is not required for compliant implementation of the PTOPO MIB.

II. PDP Review

Sec. 4.3.1) Proposal to make checksum validation optional

A proposal was made to make the PDP checksum completely optional. Currently, checksum generation is optional and checksum validation is mandatory. This issue caused a great deal of discussion. Many feel that the data link layer FCS is sufficient, and another checksum, even a simple checksum, is not needed. Some believed that optional validation makes the feature completely unreliable, and would rather have the checksum removed.

Resolution: The checksum field will be removed from the PDP message.

Sec. 4.5.5) PDP Shutdown procedures are too restrictive

The PDP Shutdown procedures described for transmission (4.5.5.1) and reception (4.5.5.2) will be changed. The restrictions related to pdpOperStatus will be removed.

p. 21 - pdpSuppressEntry INDEX) Support on Repeater devices

The granularity of PDP suppression can't be supported by repeaters, particularly for PDP message transmission. Clarifying text will be added to this section, relaxing the 'per-port' transmission granularity requirement for repeaters. For devices which cannot limit transmission of a PDP message to a single port (but rather a group of ports), an agent implementor should choose one port to identify the port group, and should limit PDP transmission to one message per port group (rather than one per port) if possible.

p. 26 -- pdpStatsInPkts) MIB object name is unclear

The name of the MIB object is unclear, since it doesn't convey whether the counter includes all received PDP messages, or just valid received PDP messages. The MIB object will be renamed to 'pdpStatsInGoodPkts', and the behavior is unchanged (i.e., the counter will increment only when a valid PDP message is received).

sec. 4.1) Frame encapsulation

The WG must decide if a special multicast MAC address can be obtained from IEEE, and if not, can a special MAC address be assigned by IANA. The WG Last Call for this document cannot start until this issue is resolved, although the actual value of the special address can be assigned later in the process.

The Ethertype used to identify the PDP message must also be assigned. This may actually be defined under LLC/SNAP, i.e., by using 'IANA' as the numbering authority in the SNAP OUI field.

Conclusions

After both drafts are revised and republished, and the frame encapsulation issues are resolved, the WG Last Call for both documents can begin.

Note that the 'Persistent Identifiers' document has been deferred to the recently reactivated Entity MIB WG. The PTOPOMIB WG expects that the entPhysicalAlias object definition will be made stable as soon as possible, so PTOPO MIB implementations can be started.

Slides

None Received

Attendees List

go to list

Previous PageNext Page