
Message-Id: <199701021216.AA26741@utopia.hclt.com>
Subject: Why is it so silent?
To: ptopo@nsd.3com.com
Date: Thu, 2 Jan 1997 17:46:00 +0530 (IST)
From: "Murugan R." <murugan@utopia.hclt.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit


Hello,

Right from the time I registered to this mailing-list, I didn't
receive even a single mail about any discussion (if at all anything
took place).  What is the plan for this group?  Any info. on future
work is appreciated.

Please reply.

---
Murugan Rajagopal,
HCL Technologies Limited,
India.


Received: from cnri by ietf.org id aa01144; 2 Jan 97 13:11 EST
Received: from janus.3com.com by CNRI.Reston.VA.US id aa14697;
          2 Jan 97 13:11 EST
Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.2) with ESMTP id KAA16768; Thu, 2 Jan 1997 10:08:45 -0800 (PST)
Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.2) with ESMTP id JAA09083; Thu, 2 Jan 1997 09:56:06 -0800 (PST)
Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by chicago.nsd.3com.com (8.8.2/8.8.2) with ESMTP id JAA28901 for <ptopo@nsd.3com.com>; Thu, 2 Jan 1997 09:59:56 -0800 (PST)
Received: from janus.3com.com (janus.3com.com [129.213.157.10]) by new-york.3com.com (8.8.2/8.8.2) with ESMTP id JAA08999 for <ptopo@nsd.3com.com>; Thu, 2 Jan 1997 09:53:37 -0800 (PST)
Received: from fedex.engwest.baynetworks.com.engwest.baynetworks.com (fedex.engwest.baynetworks.com [134.177.110.46]) by janus.3com.com (8.8.2/8.8.2) with SMTP id KAA16680 for <ptopo@nsd.3Com.com>; Thu, 2 Jan 1997 10:06:14 -0800 (PST)
Received: from raphael.engwest (raphael.engwest.baynetworks.com) by fedex.engwest.baynetworks.com.engwest.baynetworks.com (4.1/SMI-4.1)
	id AA25555; Thu, 2 Jan 97 10:05:21 PST
Received: by raphael.engwest (5.x/SMI-SVR4)
	id AA04674; Thu, 2 Jan 1997 10:05:42 -0800
Date: Thu, 2 Jan 1997 10:05:42 -0800
From: Ken Jones <kjones@baynetworks.com>
Message-Id: <9701021805.AA04674@raphael.engwest>
To: ptopo@nsd.3com.com, murugan@utopia.hclt.com
Subject: Re: Why is it so silent?
X-Sun-Charset: US-ASCII

Murugan, the PTOPO WG met for the first time in December in San Jose - about 60
people participated in the sessions.  We reviewed 3 MIB proposals at the meeting
and there are one or two more being prepared as we speak.  The editor for the
WG is working on a terminology document, and we also have some work ongoing
to evaluate use of the Entity MIB and also to define a set of requirements
for the ptopo MIB and topology mechanisms.  The minutes from San Jose will be
out by Monday, which will discuss some key issues brought up during the meeting.

We've had some administrative problems with our archive FTP server so the MIB
documents discussed at San Jose are not yet generally available.  I am trying to
resolve this and will document access to this info in the minutes.

I agree with you that so far we've had more interest than involvement.  I
expect that to change over the next several months.  Stay tuned.

   - ken 


> From listmaster@3com.com Thu Jan  2 04:33 PST 1997
> Posted-Date: Thu, 2 Jan 1997 04:29:19 -0800 (PST)
> Subject: Why is it so silent?
> To: ptopo@nsd.3Com.com
> Date: Thu, 2 Jan 1997 17:46:00 +0530 (IST)
> From: "Murugan R." <murugan@utopia.hclt.com>
> X-Mailer: ELM [version 2.4 PL25]
> Mime-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain; charset="US-ASCII"
> Content-Length: 302
> 
> 
> Hello,
> 
> Right from the time I registered to this mailing-list, I didn't
> receive even a single mail about any discussion (if at all anything
> took place).  What is the plan for this group?  Any info. on future
> work is appreciated.
> 
> Please reply.
> 
> ---
> Murugan Rajagopal,
> HCL Technologies Limited,
> India.


Received: from cnri by ietf.org id aa14236; 2 Jan 97 17:40 EST
Received: from janus.3com.com by CNRI.Reston.VA.US id aa21114;
          2 Jan 97 17:40 EST
Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.2) with ESMTP id OAA26828; Thu, 2 Jan 1997 14:27:03 -0800 (PST)
Received: from janus.3com.com (janus.3com.com [129.213.157.10]) by new-york.3com.com (8.8.2/8.8.2) with ESMTP id OAA19265 for <ptopo@3com.com>; Thu, 2 Jan 1997 14:14:16 -0800 (PST)
Received: from fedex.engwest.baynetworks.com.engwest.baynetworks.com (fedex.engwest.baynetworks.com [134.177.110.46]) by janus.3com.com (8.8.2/8.8.2) with SMTP id OAA26819 for <ptopo@3com.com>; Thu, 2 Jan 1997 14:26:56 -0800 (PST)
Received: from raphael.engwest (raphael.engwest.baynetworks.com) by fedex.engwest.baynetworks.com.engwest.baynetworks.com (4.1/SMI-4.1)
	id AA27707; Thu, 2 Jan 97 14:26:54 PST
Received: by raphael.engwest (5.x/SMI-SVR4)
	id AA04830; Thu, 2 Jan 1997 14:27:16 -0800
Date: Thu, 2 Jan 1997 14:27:16 -0800
From: Ken Jones <kjones@baynetworks.com>
Message-Id: <9701022227.AA04830@raphael.engwest>
To: ptopo@3com.com
Subject: minutes of San Jose WG meetings
X-Sun-Charset: US-ASCII

Meeting Minutes -- 37th IETF; Los Angeles, CA
Area:  Network Management
Working Group:  ptopomib
Date:  December 9 & 10, 1996

WG Chair:
	Ken Jones          <kjones@baynetworks.com>
WG Editor:
        Yoni Malachi       <yoni@isd.3com.com>
Area Advisor:
	Andy Bierman       <abierman@cisco.com>
-------------------------

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.


Received: from cnri by ietf.org id aa04265; 8 Jan 97 8:09 EST
Received: from janus.3com.com by CNRI.Reston.VA.US id aa08813; 8 Jan 97 8:09 EST
Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.2) with ESMTP id FAA21294; Wed, 8 Jan 1997 05:01:14 -0800 (PST)
Received: from janus.3com.com (janus.3com.com [129.213.157.10]) by new-york.3com.com (8.8.2/8.8.2) with ESMTP id EAA16526 for <ptopo@3com.com>; Wed, 8 Jan 1997 04:46:39 -0800 (PST)
Received: from mail.madge.com (mail.madge.com [205.184.45.3]) by janus.3com.com (8.8.2/8.8.2) with SMTP id FAA21262 for <ptopo@3com.com>; Wed, 8 Jan 1997 05:00:14 -0800 (PST)
Received: from Connect2 Message Router by mail.madge.com
	via Connect2-SMTP 4.00; Wed, 8 Jan 97 05:19:49 -0800
Message-ID: <21A8D33201660C00@mail.madge.com>
In-Reply-To: <F4DFCC3201660C00>
Date: Wed, 8 Jan 97 14:52:44 +0200
From: Dan Romascano LAN-Tel <dromasca@madge.com>
Sender: Dan Romascano LAN-Tel <dromasca@madge.com>
Organization: Madge Networks
To: ptopo@3com.com, Ken Jones <kjones@baynetworks.com>
Subject: Re: minutes of San Jose WG meetings
X-mailer: Connect2-SMTP 4.00 MHS to SMTP Gateway

from the minutes of the San Jose meeting (which unfortunately, I could 
not attend):

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

What is a port?
We do have a clear definition for a port in the Repeater MIB, but there 
is no other accepted definition of a port beyound specific devices like 
repeaters or bridges, and here differences might appear (e.g. an 
out-of-band setup connection of a bridge is not a 802.1 port. Is it a 
ptopo-wise port?). As I am struggling with this matter in another WG as 
well, I would be interested wether the matter was raised, or if people 
have opinions on this.

Dan Romascanu,
Systems Architecture Team Manager,
LAN Bussiness Unit,
Madge Networks (Israel) Ltd.,
Voice: 972-3-645-8414, e-mail: dromasca@madge.com

--------------------------------------------------------------------------
----


Received: from cnri by ietf.org id aa18345; 8 Jan 97 12:59 EST
Received: from janus.3com.com by CNRI.Reston.VA.US id aa16026;
          8 Jan 97 12:59 EST
Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.2) with ESMTP id JAA03829; Wed, 8 Jan 1997 09:49:35 -0800 (PST)
Received: from janus.3com.com (janus.3com.com [129.213.157.10]) by new-york.3com.com (8.8.2/8.8.2) with ESMTP id JAA29136 for <ptopo@3com.com>; Wed, 8 Jan 1997 09:35:44 -0800 (PST)
Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by janus.3com.com (8.8.2/8.8.2) with SMTP id JAA03816 for <ptopo@3com.com>; Wed, 8 Jan 1997 09:49:21 -0800 (PST)
Received: from abierman.cisco.com (sl-chattel-12.cisco.com [171.69.126.182]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with SMTP id JAA07062; Wed, 8 Jan 1997 09:49:18 -0800
Message-ID: <32D3DDEB.4CE@cisco.com>
Date: Wed, 08 Jan 1997 09:48:27 -0800
From: Andy Bierman <abierman@cisco.com>
Organization: Cisco Systems, Inc.
X-Mailer: Mozilla 3.0 (Win95; I)
MIME-Version: 1.0
To: Dan Romascano LAN-Tel <dromasca@madge.com>
CC: ptopo@3com.com, Ken Jones <kjones@baynetworks.com>
Subject: Re: minutes of San Jose WG meetings
References: <21A8D33201660C00@mail.madge.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Dan,

>...
> > Other MIBs, such as the Repeater MIB or Entity MIB can be
> > used to understand the internal connectivity.  
> > Physical topology shoul simply be the interconnection between 
> > ports on one device to ports on a different device.
> 
> What is a port?

From the PTOPO MIB's point of view, a port may simply be any physical
entity for which the associated instance of entPhysicalClass ==
'port(10)'.
(This forces the agent implementing the Entity MIB to decide ;-)

> We do have a clear definition for a port in the Repeater MIB, but there
> is no other accepted definition of a port beyound specific devices like
> repeaters or bridges, and here differences might appear (e.g. an
> out-of-band setup connection of a bridge is not a 802.1 port. Is it a
> ptopo-wise port?). As I am struggling with this matter in another WG as
> well, I would be interested wether the matter was raised, or if people
> have opinions on this.
> 

The WG needs to specify expectations of the 'modelling-scope' for a
PTOPO implementation, but in the end, each vendor will decide how
much detail to include. I think out-of-band mgmt ports/networks will be
modelled in some cases. The MIB must allow multiple disconnected
networks to be represented by a single agent.

Andy


> Dan Romascanu,
> Systems Architecture Team Manager,
> LAN Bussiness Unit,
> Madge Networks (Israel) Ltd.,
> Voice: 972-3-645-8414, e-mail: dromasca@madge.com
> 
> --------------------------------------------------------------------------
> ----


Received: from cnri by ietf.org id aa19355; 8 Jan 97 13:23 EST
Received: from janus.3com.com by CNRI.Reston.VA.US id aa16609;
          8 Jan 97 13:23 EST
Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.2) with ESMTP id KAA04888; Wed, 8 Jan 1997 10:07:59 -0800 (PST)
Received: from janus.3com.com (janus.3com.com [129.213.157.10]) by new-york.3com.com (8.8.2/8.8.2) with ESMTP id JAA00234 for <ptopo@3com.com>; Wed, 8 Jan 1997 09:54:19 -0800 (PST)
Received: from skipper.netsuite.com (skipper.netsuite.com [204.243.98.2]) by janus.3com.com (8.8.2/8.8.2) with SMTP id KAA04880 for <ptopo@3com.com>; Wed, 8 Jan 1997 10:07:54 -0800 (PST)
Received: from WT_GX (WT_GX [204.243.98.22]) by skipper.netsuite.com (NTMail 3.02.10) with ESMTP id oa280320 for <ptopo@3com.com>; Wed, 8 Jan 1997 13:06:30 -0500
Message-Id: <3.0.32.19970108130505.00a2caf0@skipper.netsuite.com>
X-Sender: waynet@skipper.netsuite.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 08 Jan 1997 13:05:06 -0500
To: Dan Romascano LAN-Tel <dromasca@madge.com>, ptopo@3com.com
From: "Wayne F. Tackabury" <waynet@netsuite.com>
Subject: Re: minutes of San Jose WG meetings
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 02:52 PM 1/8/97 +0200, Dan Romascano LAN-Tel wrote:
>
>What is a port?
>We do have a clear definition for a port in the Repeater MIB, but there 
>is no other accepted definition of a port beyound specific devices like 
>repeaters or bridges, and here differences might appear (e.g. an 
>out-of-band setup connection of a bridge is not a 802.1 port. Is it a 
>ptopo-wise port?). 

I'll give you my .02...the answer is yes.  ptopo can't presume the
application perspective on the significance of an interface from the
context of the MIB the way other MIBs can (the 802.1 example is a good
one--where we're presuming to be primarily interested in interfaces which
participate in the Spanning Tree sweepstakes).  I may very well be
collecting topology data to do a reduction on the application end and
search for single points of failure on managment paths to gateway devices,
in which case the appearance of that console/oob interface is essential.

In the interests of conceptual formalization, I'd open the definition of
"port" up to being anything which corresponds to a *physical* receptacle
over which data can be encoded.  The only thing that precludes is the kind
of "virtual" software-centric port that some implementors represent in
other agents (tendency for representing alternative framing types from
Netware servers/IPX routers as separate interfaces is a classic example).
And I think those should be precluded in the interests of adhering to the
physical realm.

Thanks to Dan for kicking out a good question.

Wayne

--------

rattlesnakes 'n' strychnin' prayer     -- John Cale

Wayne F. Tackabury		  Internet: waynet@netsuite.com
Netsuite Development, L.P.	  CIS: 73207,3650
321 Commonwealth Rd., Ste. 300	  Phone: (508) 647-3114
Wayland, MA  01778		  FAX: (508) 647-3112


Received: from cnri by ietf.org id aa23430; 8 Jan 97 14:34 EST
Received: from janus.3com.com by CNRI.Reston.VA.US id aa18316;
          8 Jan 97 14:34 EST
Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.2) with ESMTP id LAA09284; Wed, 8 Jan 1997 11:23:46 -0800 (PST)
Received: from janus.3com.com (janus.3com.com [129.213.157.10]) by new-york.3com.com (8.8.2/8.8.2) with ESMTP id LAA04704 for <ptopo@3com.com>; Wed, 8 Jan 1997 11:09:55 -0800 (PST)
Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by janus.3com.com (8.8.2/8.8.2) with SMTP id LAA09264 for <ptopo@3com.com>; Wed, 8 Jan 1997 11:23:32 -0800 (PST)
Received: from abierman.cisco.com (sl-chattel-12.cisco.com [171.69.126.182]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with SMTP id LAA11685; Wed, 8 Jan 1997 11:23:26 -0800
Message-ID: <32D3F3FD.3700@cisco.com>
Date: Wed, 08 Jan 1997 11:22:37 -0800
From: Andy Bierman <abierman@cisco.com>
Organization: Cisco Systems, Inc.
X-Mailer: Mozilla 3.0 (Win95; I)
MIME-Version: 1.0
To: "Wayne F. Tackabury" <waynet@netsuite.com>
CC: Dan Romascano LAN-Tel <dromasca@madge.com>, ptopo@3com.com
Subject: Re: minutes of San Jose WG meetings
References: <3.0.32.19970108130505.00a2caf0@skipper.netsuite.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

>...
> 
> In the interests of conceptual formalization, I'd open the definition of
> "port" up to being anything which corresponds to a *physical* receptacle
> over which data can be encoded.  

I think this is too general a definition -- PTOPO should be limited
to 'network' ports only. (I suppose the SCSI cable connecting the
DAT backup drive to the file-server is interesting to model, but I think
it's outside the scope of this MIB :-)

Your definition stresses an external port or interface -- something
with a connector present. I agree that only connections between
devices should be modelled. I'm concerned we will enter a big rathole
if we try to model the internal connection of a port to 1-of-N
(real or virtual) backplanes, or port-to-switch fabric, or
port-to-internal
bridge, etc.

> Wayne

Andy


Received: from cnri by ietf.org id aa01299; 9 Jan 97 1:37 EST
Received: from janus.3com.com by CNRI.Reston.VA.US id aa02756; 9 Jan 97 1:37 EST
Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.2) with ESMTP id WAA04798; Wed, 8 Jan 1997 22:27:25 -0800 (PST)
Received: from janus.3com.com (janus.3com.com [129.213.157.10]) by new-york.3com.com (8.8.2/8.8.2) with ESMTP id WAA00603 for <ptopo@3com.com>; Wed, 8 Jan 1997 22:13:22 -0800 (PST)
Received: from mail.madge.com (mail.madge.com [205.184.45.3]) by janus.3com.com (8.8.2/8.8.2) with SMTP id WAA04784 for <ptopo@3com.com>; Wed, 8 Jan 1997 22:27:05 -0800 (PST)
Received: from Connect2 Message Router by mail.madge.com
	via Connect2-SMTP 4.00; Wed, 8 Jan 97 22:46:48 -0800
Message-ID: <5395D43201660C00@mail.madge.com>
In-Reply-To: <1E1BD43201660C00>
Date: Thu, 9 Jan 97 8:22:36 +0200
From: Dan Romascano LAN-Tel <dromasca@madge.com>
Sender: Dan Romascano LAN-Tel <dromasca@madge.com>
Organization: Madge Networks
To: "Wayne F. Tackabury" <waynet@netsuite.com>, 
    Andy Bierman <abierman@cisco.com>
Cc: ptopo@3com.com
Subject: Re: minutes of San Jose WG meetings
X-mailer: Connect2-SMTP 4.00 MHS to SMTP Gateway


>> In the interests of conceptual formalization, I'd open the definition 
of
>> "port" up to being anything which corresponds to a *physical* 
receptacle
>> over which data can be encoded.  
> 
> I think this is too general a definition -- PTOPO should be limited
> to 'network' ports only. (I suppose the SCSI cable connecting the
> DAT backup drive to the file-server is interesting to model, but I 
think
> it's outside the scope of this MIB :-)
> 
> Your definition stresses an external port or interface -- something
> with a connector present. I agree that only connections between
> devices should be modelled. I'm concerned we will enter a big rathole
> if we try to model the internal connection of a port to 1-of-N
> (real or virtual) backplanes, or port-to-switch fabric,
> or
> port-to-internal
> bridge, etc.

To be clear, if I am to write a application, I would probably take Andy's 
view and look only at what he calls 'network' ports. I am however 
concerned by the lack of a consistent definition. Even the Entity MIB is 
too weak in the way it defines a port, because it relies on the 
implemetors selection of the physical entity falling into one category or 
another, without a formal delimitation of the classes. Even the 
delimitation between 'physical' and 'logical' topology is unclear to me, 
as we seem to intent to intent to deal with LAN and WAN environments, 
data and signaling channels, permanent and temporary links.

Anyway, it is probably the goal of the Terminology document to be written 
by Yoni, to clarify part of the aspects and surely trigger more debate.   


Dan Romascanu,
Systems Architecture Team Manager,
LAN Bussiness Unit,
Madge Networks (Israel) Ltd.,
Voice: 972-3-645-8414, e-mail: dromasca@madge.com

--------------------------------------------------------------------------
----