Re: portDown/portUp

Anil Rijsinghani <anil@levers.enet.dec.com> Mon, 12 October 1992 23:16 UTC

Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa11886; 12 Oct 92 19:16 EDT
Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa11882; 12 Oct 92 19:16 EDT
Received: from CS.UTK.EDU by NRI.Reston.VA.US id aa28788; 12 Oct 92 19:17 EDT
Received: by CS.UTK.EDU (5.61++/2.8s-UTK) id AA04089; Mon, 12 Oct 92 18:51:32 -0400
Received: from inet-gw-2.pa.dec.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA04085; Mon, 12 Oct 92 18:51:28 -0400
Received: by inet-gw-2.pa.dec.com; id AA22533; Mon, 12 Oct 92 15:51:22 -0700
Received: by us1rmc.bb.dec.com; id AA26909; Mon, 12 Oct 92 18:48:39 -0400
Message-Id: <9210122248.AA26909@us1rmc.bb.dec.com>
Received: from levers.enet; by us1rmc.enet; Mon, 12 Oct 92 18:48:50 EDT
Date: Mon, 12 Oct 1992 18:48:50 -0400
Sender: ietf-archive-request@IETF.NRI.Reston.VA.US
From: Anil Rijsinghani <anil@levers.enet.dec.com>
To: james_reeves@engtwomac.synoptics.com
Cc: fddi-mib@cs.utk.edu
Apparently-To: fddi-mib@cs.utk.edu, james_reeves@engtwomac.synoptics.com
Subject: Re: portDown/portUp

    James,

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

    Good, this indicates that a trap in the FDDI MIB would help.

> I believe the right thing to pursue 
> is to develop a more general trap scheme that can handle ring level events.

    This seems to imply a more complex implementation, but I'll keep
    reading..

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

    So far I'm with you.  (just a comment - if one indicates the other,
    then the one should be useful by itself as well.. in addition, it
    appears to me that topology changes should be derived by the
    application, based on more primitive information like portDown traps)

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

    Here I'm a bit confused.  A portDown would be generated only once
    for each port that goes down, and typically you shouldn't get a large
    number of ports going down.  Unless the whole ring went down, in which
    case none of the portDown traps will be sent anyway.  This is analogous
    to the linkDown situation.  In the case of a concentrator with a large
    number of ports powering up, I agree that a large number of port*Ups*
    would be sent.  I guess we could talk about how useful portUp is
    as compared to portDown.. in the latter, the manager wants to know as
    soon as the network is broken so that he can get to work on it right
    away; in the former, the manager wants to get the status on
    his screen corrected.

    In general it appears that parallels can be drawn for portDown and
    portUp to linkDown and linkUp.

    Anil