2.4.9 Physical Topology MIB (ptopomib)

NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98

Chair(s):

Ken Jones <kjones@baynetworks.com>

Operations and Management Area Director(s):

Harald Alvestrand <Harald.Alvestrand@maxware.no>
Bert Wijnen <wijnen@vnet.ibm.com>

Operations and Management Area Advisor:

Harald Alvestrand <Harald.Alvestrand@maxware.no>

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

OPS Area
PTOPOMIB WG Meeting Minutes
43rd IETF
Orlando, FL USA
December 11, 1998
Minutes by Andy Bierman

Review Material

(1) Physical Topology MIB <draft-ietf-ptopomib-mib-03.txt>

(2) Physical Topology Discovery Protocol and MIB <draft-ietf-ptopomib-pdp-03.txt>

Agenda

Issues - PTOPO MIB I-D
- Issues - PDP I-D
- Ready for WG Last Call?
- Intellectual Property Discussion
- Next Steps for the PTOPOMIB WG

Minutes

1) Issues - PTOPO MIB I-D

There were no new comments on this draft, and no new issues raised at the meeting regarding this draft.

2) Issues - PDP I-D

The only open issue for this draft is related to the MAC address assignment for the PTOPO Discovery Protocol.

THe following table describes the desired behavior for bridging entities, which either implements PDP (pdp-aware) or doesn't implement PDP (pdp-unaware).

STP port

PDP-unaware

PDP-aware

state

bridges

bridges

blocked

discard

tx/rx, no fwd

forwarding

flood

tx/rx. prefer no fwd

For ports In the STP blocked state, PDP-aware bridge HW may drop received PDP PDUs instead of processing them. This is undesirable, since the discovery of physical topology information should not be impeded or limited by logical network topologies.

The Assigned Numbers document (RFC 1700, p. 172) defines an IANA Ethernet Address Block, which is reserved for special multicast addresses such as the one needed for PDP. (These addresses are in the range 01-00-5E-00-00-00 to 01-00-5E-7F-FF-FF.) The static forwarding table of each PDP-aware bridge could be configured to prevent PDP messages from being forwarded on every port except the "CPU port/higher level PDP entity".

The WG prefers to obtain an IEEE multicast address, such that the desired forwarding behavior is achieved without static FDB configuration. [Ed. - not sure what range this is.] If this address assignment is not possible, then the WG will ask IANA if a group address assignment from the IANA Ethernet Block.

3) Ready for WG Last Call?

The WG agreed that both documents are complete (pending the MAC address assignment), and they should be forwarded to the Area Director so the IESG review process may start right away.

4) Intellectual Property Discussion

There was a brief discussion on the IBM patent issues relating to both PTOPOMIB WG documents. The WG will continue to monitor any progress on vendor implementations and any (publicly-available) patent issue resolution details.

A straw-poll was taken to measure vendor interest in implementing the MIB and/or PDP in next 6 - 9 months
- none plan to implement PDP
- 3 plan to implement the PTOPO MIB; more will be interested if/when the patent issues are resolved

It was noted by the Area Director that 90% of negotiations end up with a license fee around 1% of the product price.

5) Next Steps for the PTOPOMIB WG

The WG discussed some possible future work items:

- other discovery protocols
- e.g., relation to ILMI
- logical topology
- identify VLAN trunking, STP, etc.
- domain topology (topology server)
- mgr-to-mgr topology info exchange
- schema definitions
- DTMF wants schema for CIM model
- end-to-end topology across the internet???

A straw poll was held to gauge interest in future work: 6 think consideration of at least one of these work items in about a year is appropriate. 2 think no future work by this WG is needed.

There was some strong objection to duplication of MIB objects, such as those found in the ILMI MIB, Bridge MIB, etc. The topology server work item seemed to be the most popular (and in some cases the only) area of future work of interest to most WG members.

Any and all of these issues may be discussed on the WG mailing list after the current work is completed.

Slides

None received.