Editor's Note: These minutes have not been edited. Meeting Minutes -- 38th IETF; Memphis, TN Reported by Ken Jones Area: Operational and Management Requirements Working Group: ptopomib Date: April 9, 1997 WG Chair: Ken Jones Area Advisor: Andy Bierman ------------------------- Summary ======= The Ptopo WG met on Wednesday, april 9th from 1:00 to 3:15. 55 people attended the session. Reading Material ================ ID-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 Agenda Review - Jones ===================== Ken Jones presented the agenda, which was accepted with some changes in the order of presentatons. The proposed agenda called for reviewing the 4 IDs, and then to spend the rest of the 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: o Agenda Review o Review IDs o Framework - Ken Jones o Neo-MIB - Wayne Tackabury o MIB and Discovery Protocol - Andy Bierman o Terminology - (not reviewed due to author not present) o Issues Review (list of issues provided below) o Discussion on need for Interim meeting 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: o 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. o 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. o Security - there is an issue that agent discovery and physical topology information may be a security concern in some environments. o 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 info is a good way to identify leaf devices without requiring them to implement an active topology mechanism or the PTOPO MIB. 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: o 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 o 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. 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: o the entity MIB would be extended to support a read-only chassis ID and port IDs. These IDs would be persistent across power cycles. o 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. o 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). o There was a question as to whether the device ID would be universally required to be supplied by all topology mechanisms. o 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. o 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 the discovery packets should not be forwarded by a device and must be sent on all ports, including spanning-tree-blocked ports. o 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. 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 presentations directory in the PTOPO archives. Local Topology vs Topology Server The issue is whether the WG 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 WG effort or possibly move it to DISMAN or some other WG. 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: o entity MIB extensions - are these satisfactory and are there issues with requiring implementation of portions of the entity MIB. o agent identification - is this through a t-address? o device identification - should this be more flexible.for example should it be read/write. o should the MIB include end-station (leaf) topology information. The response from San Jose was a strong yes. o how does the MIB accomodate redundant or ambiguous information - e.g. multiple agents detected on a port, and multiple device IDs detected on a port. o Should there be a separate table for connection info and agent id? o how useful are time filters for topology. The RMON group has positive feedback on their usefulness. o topology corner cases - non-PTOPO devices, multiple agents in a chassis, multiple links between devices, rings, busses (see framework document). o can the instance of the topology mechanism be used to bound the topology gathering process (see framework document) o what's the right way to detect and process topology changes. Interim Meeting Discussion ========================== We discussed the need to get active discourse occuring on the mail list. It seems that most of the work prior to the Memphis meeting happened during the 3 weeks prior to the cutoff date (Wayne was the exception). An interim meeting would have the benefit of getting work done 3 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 was 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 WGs that may be planning interim meetings as well.