Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/ptopomib/ptopomib-minutes-96dec.txt

Text File | 1997-01-30 | 15KB | 322 lines

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 [e-mail].


-------------
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.