Re: portDown/portUp

James Reeves <james_reeves@engtwomac.synoptics.com> Mon, 12 October 1992 20:47 UTC

Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa11391; 12 Oct 92 16:47 EDT
Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa11387; 12 Oct 92 16:47 EDT
Received: from CS.UTK.EDU by NRI.Reston.VA.US id aa25724; 12 Oct 92 16:47 EDT
Received: by CS.UTK.EDU (5.61++/2.8s-UTK) id AA00961; Mon, 12 Oct 92 15:58:02 -0400
Received: from mvis1.synoptics.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA00957; Mon, 12 Oct 92 15:57:59 -0400
Received: from engtwomac.synoptics.com by synoptics.com (4.1/SMI-4.1) id AA15501; Mon, 12 Oct 92 12:57:06 PDT
Message-Id: <9210121957.AA15501@synoptics.com>
Date: Fri, 09 Oct 1992 17:01:49 -0000
Sender: ietf-archive-request@IETF.NRI.Reston.VA.US
From: James Reeves <james_reeves@engtwomac.synoptics.com>
Subject: Re: portDown/portUp
To: fddi-mib@cs.utk.edu

         Reply to:   RE>portDown/portUp
>>From: Anil Rijsinghani
>   Hi,.
>
>    In FDDI concentrators, when a port goes down you can't send a
>    linkDown trap.  As a result there's no asynchronous notification
>    to the manager of a breakdown in the network.  Multiple customers
>    have reported that polling is not timely enough in this case,
>    and we have ended up defining enterprise-specific traps for
>    this purpose.

We also have enterprise specific traps. I believe the right thing to pursue 
is to develop a more general trap scheme that can handle ring level events. 
A port going down also causes a logical topology change. This information is as
useful,
or more useful than knowing that a port has isolated. However, the traps
should not be sent by every station on the ring. There are too many traps that
could be
generated by a large FDDI concentrator which would bog down intermediate links
with usually redundent information.

Is there any interest in pursuing a proxy based approach to this problem?

James Reeves
SynOptics Communications