RE: [Bridge-mib] New trap

["David B Harrington" <[e-mail]>]

Hi,

Maintenance of the Bridge Mib modules has been taken over by the IEEE
802.1 WG.

As a result, this proposal is out of scope for the Bridge MIB WG
mailing list.
   The appropriate mailing list for IEEE 802.1 MIB module discussion
   is [e-mail].
   To subscribe to the STDS-802-1-L list, go to
   http://www.ieee802.org/1/email-pages/
   To see the general information about 802,1, including how they
   work and how to participate, go to http://www.ieee802.org/1/
   To see presentations on the technology, go to
   http://www.ieee802.org/1/files/public/ and look in the docs2004,
   docs2005, and docs2006 directories. 

David Harrington
[e-mail] 
[e-mail]
[e-mail]
co-chair, Bridge-MIB WG 


> -----Original Message-----
> From: ravikumarb [mailto:[e-mail]] 
> Sent: Monday, July 17, 2006 8:55 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [Bridge-mib] New trap
> 
> 
> Hi,
> 
> We would like to porpose a new trap for bridges so that they 
> can detect malfunctioning neighbour bridges. Lets call it as 
> "neighbourUnreachable". This trap will be generated by the 
> bridge if it doesn't receive 5 consecutive Hello BPDUs from a 
> port, which was receiving these messages earlier. This trap 
> will be useful to detect cases where the bridge and its ports 
> were functioning properly for some time and suddenly started 
> malfunctioning due to a hardware glitch or a software bug. 
> Note that link failure (down) trap won't be raised as the 
> link is UP from the PHY point of view. This is analogous to 
> Hello messages used by Routing Protocols to detect routing 
> peers. This trap will be very useful for the NMS to take 
> appropriate actions. Note that this is very different from 
> "topologyChange" trap, which just tells that the port has 
> transitioned to Blocking State from Forwarding State. This 
> trap tells that the bridge is not functioning properly at all 
> from the port's point of view. It has a specific meaning and 
> is detected fast. Following would be its structure:
> 
> neighbourUnreachable NOTIFICATION-TYPE
>     OBJECTS     { dot1dBaseBridgeAddress dot1dBasePort 
> dot1dBasePortIfIndex }
>     STATUS      current
>     DESCRIPTION
>         "A neighbourUnreachable trap is sent by a bridge when it
>         doesn't receive 5 consecutive Hello BPDUs. This will
>         allow a bridge to detect malfunctions of the neighbour
>         bridge even when the link state to the neighbour bridge
>         is UP. It is analogous to Hello messages used by Routing
>         Protocols to detect whether the neighbour router is
>         functional."
>     ::= { dot1dNotifications 3 }
> 
> Please let us know your thoughts regarding the proposed trap.
> 
> Thanks & Regards,
> Ravi
> 
> 
> 
> 
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION 
> intended solely for the use of the addressee(s). If you are 
> not the intended recipient, please notify the sender by 
> e-mail and delete the original message. Further, you are not 
> to copy, disclose, or distribute this e-mail or its contents 
> to any other person and any such actions are unlawful. This 
> e-mail may contain viruses. Infosys has taken every 
> reasonable precaution to minimize this risk, but is not 
> liable for any damage you may sustain as a result of any 
> virus in this e-mail. You should carry out your own virus 
> checks before opening the e-mail or attachment. Infosys 
> reserves the right to monitor and review the content of all 
> messages sent to or from this e-mail address. Messages sent 
> to or from this e-mail address may be stored on the Infosys 
> e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
> 
> _______________________________________________
> Bridge-mib mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/bridge-mib
> 


_______________________________________________
Bridge-mib mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/bridge-mib