Editor's note: These minutes have not been edited. Summary ======= Meeting notes were taken by Andy Bierman and Ken Jones. The Ptopo WG met twice in San Jose, first on Monday from 3:30 to 5:30 and then on Tuesday from 9:00 to 11:30. 65 people attended the sessions. Since the minutes are fairly long, they begin with a summary of action items, followed by detailed accounts of each discussion (in chronological order). Reading Material ================ ID-1: Definitions of Managed Objects for Topology Servers draft-greene-topology-mib-00.txt ID-2: N. Schaller's Meta-MIB draft-tackabury-email-metamib ID-3: Definition of Managed Objects for Physical Topology Agents draft-desai-ptopo-mib-00.txt Review of Schedule, Action Items - Jones ======================================== There was a proposal made for an interim meeting prior to the April IETF but it was generally felt that with the intervening holidays, it was best to focus on email discussions in preparation for April. We need to get proposals posted quickly in order to move the group toward publication of WG-owned I-Ds (model and MIB document) prior to the April meeting. The following action items were taken: o Terminology - Yoni Malachi, who is our document editor, will gather input from the current submissions and put together a proposal for a set of terminology to be used in future discussions. This terminology can be changed before we "go to press" but having a common set of terms early on will make discussion easier. DATE 1/15/97 o MIB Requirements - Prakash Desai will prepare a set of requirements for the MIB and also for topology mechanisms. DATE 1/15/97 o Entity MIB - Andy Bierman will evaluate how we can leverage the Entity MIB to support our work and will submit a writeup. DATE 1/15/97 o MIB submissions - there are a number of additional submissions being prepared by WG members. These should be posted ASAP as Internet Drafts so we can evaluate and discuss via Email. These should be posted by DATE 1/15/97. The archive is now up and running at ftp.3com.com. Login as "ptopo" with a password of "ptopo". CD to USR and then PTOPO to access the archive. To submit documents to the archive mail them to kjones@baynetworks.com. ------------- Monday, Dec 9 ------------- Ken Jones presented the agenda, which was accepted as proposed with some changes in the order of presentations. The following was the final agenda: o Agenda Review o Charter review o Review of submissions o Topology MIB discussion - Maria Greene o Meta-MIB (H.N. Schaller) discussion - Wayne Tackabury o Topology Model and MIB discussion - Prakash Desai o Mac-Based Topology Mechanism - John Flick o Open discussion - gather input and ideas o Review of schedule, action items Charter Review - Jones/Bierman ============================== The charter (http://www.ietf.org/html.charters/ptopomib-charter.html) was reviewed. o Logical vs Physical topology - the focus of the WG is physical topology. The charter says this could be an area for future work items, but it should not impede progress on the primary focus of physical connectivity. There was strong consensus that solving the problem of physical connectivity is a high priority and forms the basis for understanding logical topology (e.g., VLANs or network layer subnet structure). o What is and isn't physical topology - there was significant discussion about the definition of physical topology. The goal is to represent the physical connectivity of devices in a network and not to represent connectivity within a device (such as the interconnection of ports to backplanes in a multisegment hub, or the interconnection of ports to VLANs in a switch). Other MIBs, such as the Repeater MIB or Entity MIB can be used to understand the internal connectivity. Physical topology should simply be the interconnection between ports on one device to ports on a different device. o Are we focused on LAN topology or do we include WAN topology - The MIB should be able to provide topology info for any type of device, which raised two important issues - scalability and clouds. o Scalability - there must be some containment mechanism or localization of topology mechanisms so that topology can scale across large networks. You can't flood networks with topology information or expect an agent to maintain topology information for a very large collection of devices. The "sphere" mechanism presented later provides a way of specifying containment for topology mechanisms. o Clouds - if physical topology is defined by how ports on one device are connected to ports on another device, there are situations where you may know there is something between two ports but you can't determine what it is. For instance, two devices connected by WAN links (that do not support or allow access to the Ptopo MIB), or several devices interconnected through an unmanaged hub. In these cases, there must be a way of representing the something between these devices. The concept of a cloud is useful, which shows connectivity between devices but allows for unmanaged devices in the topology. o Specifying topology mechanisms - the charter states that we will define the general requirements for topology mechanisms in order to support the proposed MIB, will identify existing mechanisms, and may propose new mechanisms where required. There was discussion as to whether we must have standard topology mechanisms in order to realize the promise of the Ptopo MIB. If we define the boundary rules between different topology mechanisms, then we should be able to allow standard or proprietary mechanisms to be used - with the burden placed on the boundary devices themselves. This is an important issue that we must deal with early on. o Geography - there was a question raised as to whether the Ptopo MIB should include geographic information, and the general feeling was that it should not. The focus is on the physical interconnection of devices and not where those devices are physically located. o Security - there were several concerns about security both for the topology mechanisms and the information in the MIB. It was suggested that security issues be dealt with up front rather than as an afterthought, and that the containment approach used for topology mechanisms be considered for containment of security management. o Entity MIB - since we are dealing with physical ports on devices, it was felt that there could be a strong tie-in to the physical inventory portion of the Entity MIB. In later discussions, it seems that some things were left out of the Entity MIB that we might need, so we might want to go back to the Entity MIB WG and make suggestions for additions. In general, it was felt that requiring implementation of the Entity MIB along with the Ptopo MIB was acceptable - we definitely do not want to re-invent stuff that's already been done by other WGs. Topology MIB discussion (ID-1) - Greene ======================================= Maria briefly reviewed the topology MIB she submitted to the WG mailing list several months ago, and then led a discussion on the key attributes of the MIB. The following are the key points raised during the discussion: o the MIB defines a way of grouping devices together into hierarchical relationships, referred to as "domains". This is useful at all levels of the OSI model and systems can belong to many different domains. This grouping of systems could be used as a way to provide scalability by grouping physically connected devices and building up a hierarchical physical model. o We discussed the concept of an Agent_ID, which would be used to uniquely identify an agent. There was some discussion of this concept in the Entity MIB but we believe it was dropped from that MIB. o the MIB contains a field to indicate what mechanism was used to discover each object, which seemed very useful. It also allowes manual entry of topology info which is seen as very important. o it was questioned whether a MIB could be defined generically that would work for different topology mechanisms. The analogy was made to the routing table MIB that works regardless of the underlying routing protocol. This is a very good analogy for what we are trying to accomplish. o a point was raised that it is useful to have timestamps on tables to know when topology changes have occurred. ------------ Tues, Dec 10 ------------ Meta-MIB discussion (ID-2) - Tackabury =============================== Wayne briefly reviewed the Meta-Management MIB that had originally been posted by N. Schaller last year to the Entity MIB WG and then led a discussion of the MIB. The following is the list of key points brought up during this discussion: o This MIB also contains the concept of domains, where a domain is a collection of objects and/or other domains. It allows a hierarchical representation of physical topology, potentially ranging from the semiconductor level up to the interconnection of enterprises. o We discussed the concept of a "topology server" as opposed to a "topology agent". The server contains topology information for a portion of the network, while the agent reports its own view of its local topology and a management station may be required to assemble information from many agents to determine the actual physical topology. The goal of the working group is closer aligned with the "topology agent" model, so that we can gather and report topology information using fairly inexpensive agents. In practice, the two approaches could result in fairly similar MIBs. For example, a "topology agent" might report information for each of its local ports, indicating what devices exist "downstream" from each port. A "topology server" might extend this table to allow the MIB to contain downstream information for ports on other devices. However, a topology server MIB might also contain information such as icon type, color, location on a map, etc which we definitely do not want to incorporate as part of the Ptobo MIB. o we discussed how different media technologies make it harder or easier to gather physical topology information. For store and forward devices, it is fairly easy for them to exchange information with another device connected to each port and report complete topology information in the MIB. For shared media devices, it is often only possible to report the list of devices which have been identified as "downstream" from a particular port, and it is only possible to determine the actual physical neighbor by gathering the downstream information from each of the downstream devices in an interactive manner. Topology Model and MIB discussion (ID-2) - Desai ================================================ Prakash reviewed the Physical Topology presentation originally given at the Montreal NM Directorate meeting, followed by a presentation and discussion of his Topology MIB proposal. The key points raised during this discussion: o the model presented addresses the issue of containment - how to limit the proliferation of topology information and yet still allow a management station to learn the physical topology of arbitrarily large networks. If every device learns about and maintains information about every other device, then the MIB requirements are N-squared, which does not scale well. Additionally, many topology mechanisms require some sort of broadcast messages to be sent which also requires some form of containment. o the MIB proposed is very much aligned with the "topology agent" model discussed earlier. For each local port under control of this agent, it contains one or more row entries identifying information for devices it has seen "downstream" from that port. The information includes the address of the device's agent and may include port information from that device. If a single entry exists for a local port, then the neighbor topology may be complete. If multiple entries exist for a local port, it will be necessary to go query the downstream agents to determine the actual physical arrangement. o it was pointed out that if the MIB were extended to include a system identifier for the "local" ports, then the MIB could also function as a server MIB, reporting port information for many devices. MAC-based topology mechanism - Flick ==================================== John presented an overview of the topology mechanism that has been incorporated into the Repeater MIB. The following are the key issues discussed: o The mechanism is based on first discovering the list of MAC addresses that exist within a repeater network and then listening on individual repeater ports to determine if that address exists downstream from that port. By using an iterative process, it is possible to determine the physical connectivity of the shared media network. o The Repeater MIB contains some control elements to enable a manager to set up the repeater to listen for a specific MAC address on a port. If the address is detected, a flag is updated in the MIB. A manager must follow an algorithm to program devices in the network and gather the information required to learn the network topology. An alternative mechanism employed by some vendors automatically collects MAC information from each port and doesn't require the manager to control the device in real time. o this presentation helped shed light on the types of topology mechanisms that might be encountered. This one requires a substantial amount of real-time manager interaction in order to make it work. For this mechanism, it might make sense to let a "topology manager" learn the topology and represent it using a "topology server" approach to the Ptopo MIB. If the mechanism doesn't require real-time control, then the Ptopo MIB could be used to return the MAC information for each port. Open Discussion - Jones ======================= The goal of this part of the meeting was to review some of the issues raised and open the floor for any other issues and concerns. Many issues and ideas were discussed during the presentations so this was a fairly short discussion. The following were the key areas discussed: o end station topology - In simple terms, a network consists of interconnection devices (e.g. routers, hubs, switches) and end stations. In a typical network there may be 1 to 2 orders of magnitude more end stations than interconnection devices. The question was raised to get a consensus to focus on just interconnection device topology or to include end station topology. The group felt that understanding the entire network was important and the WG should work toward physical topology for both types of devices. o An informal poll was taken to determine the mixture of the audience. About half the group was interested in physical topology from a device perspective, about half from a management application perspective. A small group represented actual users.