NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Ken Jones <kjones@baynetworks.com>
Operations and Management Area Director(s):
Scott Bradner <sob@harvard.edu>
Michael O'Dell <mo@uu.net>
Deirdre Kostick <kostick@qsun.att.com>
General Discussion:ptopo@3com.com
To Subscribe: ptopo-request@3com.com
Archive: ftp ftp.3com.com (login: ptopo, passwd: ptopo)
Document Editor: Gilbert Ho (Gilbert_Ho@3mail.3com.com)
The goals of this working group are:
· To agree on and document the common framework/model for discussing physical topology · To standardize a set of managed objects that provide physical topology information · 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:
Minutes of the Physical Topology MIB (PTOPOMIB) Working Group
Reported by: Ken Jones
The PTOPOMIB Working Group met on Wednesday, April 9th from 1:00 to 3:15. Fifty-five people attended the session.Reading MaterialID-1: Network Element Object MIB (Neo-MIB)
draft-tackabury-neo-mib-00.txt
ID-2: Physical Topology Framework
draft-kjones-ptopo-framework-00.txt
ID-3: Physical Topology MIB and Discovery Protocol
draft-bierman-ptopo-MIB-proto-00.txt
ID-4: Physical Topology Terminology
draft-malachi-topology-terms-00.txt
Ken Jones presented the agenda, which was accepted with changes in the order of presentations. The proposed agenda called for reviewing the four IDs and spend the remaining time discussing key issues, with a goal of reaching consensus within the group if possible, and deferring contentious issues to the mailing list.
The following was the final agenda:
MIB and Discovery Protocol - Andy Bierman
Terminology - (Not reviewed due to author not present)
Issues Review (List of issues provided below)
Discussion on need for Interim meeting
II (a). Physical Topology Framework (ID-2) - Jones
Ken Jones reviewed the framework document. A copy of the ID and the presentation can be found in the PTOPO archives (ftp.3com.com). Key points and issues raised include the following:
The definition of physical topology is the external interconnection of physical ports. Can be 1:1 or 1:n. It is a linear relationship - there is no concept of hierarchy required.
The common MIB should be independent of the topology mechanism(s) used and should represent the agent's local view of the physical topology. That view may be incomplete and/or redundant. The MIB should also contain information about other agents that have been discovered by this agent. These other agents may contain physical topology data.
Security - there is an issue that agent discovery and physical topology information may be a security concern in some environments.
Use of datalink information to determine physical topology. The framework document describes a method of determining physical topology based on detecting which MAC addresses have been seen on which ports. There was a question about whether this datalink information should be used to understand physical topology. It was pointed out that datalink information is a good way to identify leaf devices without requiring them to implement an active topology mechanism or the PTOPO MIB.
II (b). Network Element Object MIB (ID-1) - Tackabury
Wayne Tackabury reviewed the Neo-MIB document. A copy of his presentation and the ID can be found in the PTOPO archive (ftp.3com.com). Key points and issues raised include the following:
· This MIB supports both the local topology agent and the topology server agent. It is also extensible to layers above physical topology. Wayne presented an example of how VLAN topology would be represented in the MIB
· It was suggested that the identifier used to indicate the topology mechanism used to collect the data be included in the index. This would allow a management application to readily retrieve all topology information obtained through a particular mechanism.
II (c).Physical Topology MIB and Discovery Protocol (ID-3) - Bierman
Andy Bierman reviewed the MIB and discovery protocol document. A copy of his presentation and the ID can be found in the PTOPO archive (ftp.3com.com). Key points and issues raised include the following:
· The entity MIB would be extended to support a read-only chassis ID and port IDs. These IDs would be persistent across power cycles.
· The MIB contains both physical connectivity information and agent identification information, as described in the framework document. The MIB provides local topology - it is not a topology server.
· The MIB does not allow for representation of partial topology information (e.g., if remote port is not known), or for ambiguous information (e.g., several devices are known to exist downstream from a port, but the actual physical connections are not known (also known as a cloud).
· There was a question as to whether the device ID would be universally required to be supplied by all topology mechanisms.
· There is a 128-byte limit on the size of an index, so we need to be careful how many strings we use as indices.
· The PTOPO Discovery Protocol is proposed as an example mechanism that could be used to populate the PTOPO MIB. The mechanism proposed would be for store and forward devices since a device should not forward the discovery packets and must be sent on all ports, including spanning-tree-blocked ports.
· It was pointed out that the PTOPO agent is different than the topology mechanism "application" and we should be careful not to confuse the two.
III. Issues Discussion - Jones
Ken Jones led a discussion on a number of issues. Two major issues were discussed and consensus was reached. The other issues will be discussed on the mailing list. The list of issues can be found in the presentation directory in the PTOPO archives.
Local Topology vs Topology Server
The issue is whether the Working Group should focus just on local topology for now or whether it should include a topology server. The MIB requirements for both could be very similar, although the topology server could have additional requirements. A proposal was made to focus on local topology for now and either work on the topology server as a future Working Group effort or possibly move it to DISMAN or some other Working Group. Topology issues such as connections to local printers through a printer port would also not be part of local topology MIB. A straw vote was taken on this issue and the group felt strongly that it should focus on local topology for now.
Do we need to specify topology mechanisms?
The group felt very strongly that we need to specify one or more mechanisms in order to provide enough information to allow interoperable implementations. It was agreed that we can't limit the MIB or the implementations to a single mechanism - we must allow use of existing mechanisms, both standard and proprietary. We must allow the overlapping use of different mechanisms. Data in the MIB should be identified with the topology mechanism used to discover that data.
There were several other issues that we did not have time to cover. The following is a brief summary of these issues:
· Entity MIB extensions - are these satisfactory and are there issues with requiring implementation of portions of the entity MIB.
· Agent identification - is this through a t-address?
· Device identification - should this be more flexible? For example, should it be read/write?
· Should the MIB include end-station (leaf) topology information? The response from San Jose was a strong yes.
· How does the MIB accommodate redundant or ambiguous information - e.g., multiple agents detected on a port, and multiple device IDs detected on a port.
· Should there be a separate table for connection information and agent ID?
· How useful are time filters for topology? The RMON group has positive feedback on their usefulness.
· Topology corner cases - non-PTOPO devices, multiple agents in a chassis, multiple links between devices, rings, busses (see framework document).
· Can the instance of the topology mechanism be used to bound the topology gathering process (see framework document)?
· What's the right way to detect and process topology changes?
IV. Interim Meeting Discussion
We discussed the need to get active discourse occurring on the mail list. It seems that most of the work prior to the Memphis meeting happened during the three weeks prior to the cutoff date (Wayne was the exception). An interim meeting would have the benefit of getting work done three weeks ahead of time, but we really need a more focused effort from the group.
It was agreed that the chairman would determine whether sufficient progress is being made on the mail list, and if not would call for an interim meeting to be held sometime in June. We will also try to coordinate with other Operations and Management Working Groups that may be planning interim meetings as well.
2.
PTOPO Agent Proposal Attenes
List