[Bridge-mib] topologyChange TRAP-TYPE

hans.de_vleeschouwer@alcatel.be Wed, 31 March 2004 10:55 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13647 for <bridge-archive@odin.ietf.org>; Wed, 31 Mar 2004 05:55:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8dN8-00040f-Eo for bridge-archive@odin.ietf.org; Wed, 31 Mar 2004 05:55:02 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VAt2mi015413 for bridge-archive@odin.ietf.org; Wed, 31 Mar 2004 05:55:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8dN6-0003zs-Qx; Wed, 31 Mar 2004 05:55:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8dMW-0003y8-Jc for bridge-mib@optimus.ietf.org; Wed, 31 Mar 2004 05:54:24 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13575 for <bridge-mib@ietf.org>; Wed, 31 Mar 2004 05:54:20 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8dMT-0002u3-00 for bridge-mib@ietf.org; Wed, 31 Mar 2004 05:54:21 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8dLT-0002lP-00 for bridge-mib@ietf.org; Wed, 31 Mar 2004 05:53:19 -0500
Received: from colt-na165.alcatel.fr ([62.23.212.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1B8dKp-0002fX-00 for bridge-mib@ietf.org; Wed, 31 Mar 2004 05:52:39 -0500
Received: from bemail06.netfr.alcatel.fr (bemail06.netfr.alcatel.fr [155.132.251.30]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i2VAqdIe001856 for <bridge-mib@ietf.org>; Wed, 31 Mar 2004 12:52:39 +0200
Received: from alcatel.be ([138.203.191.85]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004033112523712:2927 ; Wed, 31 Mar 2004 12:52:37 +0200
Message-ID: <406AA2F5.3020102@alcatel.be>
Date: Wed, 31 Mar 2004 12:52:37 +0200
From: hans.de_vleeschouwer@alcatel.be
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: bridge-mib@ietf.org
X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 03/31/2004 12:52:37, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 03/31/2004 12:52:38, Serialize complete at 03/31/2004 12:52:38
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
X-Alcanet-MTA-scanned-and-authorized: yes
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [Bridge-mib] topologyChange TRAP-TYPE
Sender: bridge-mib-admin@ietf.org
Errors-To: bridge-mib-admin@ietf.org
X-BeenThere: bridge-mib@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/bridge-mib>, <mailto:bridge-mib-request@ietf.org?subject=unsubscribe>
List-Id: <bridge-mib.ietf.org>
List-Post: <mailto:bridge-mib@ietf.org>
List-Help: <mailto:bridge-mib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/bridge-mib>, <mailto:bridge-mib-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi,

I am new to this group, so plse forgive me if my questions have been 
asked  before...

I have 2 questions on how to handle the topologyChange TRAP-TYPE in RSTP.
The description states that:

            "A topologyChange trap is sent by a bridge when
            any of its configured ports transitions from the
            Learning state to the Forwarding state, or from
            the Forwarding state to the Blocking state.

1) During  the RSTP syncing phase there are temporary transitions
   to and from the forwarding state (the moving cut). 

   With the above definition every single of those transitions will
   cause a trap although they do not imply any topology change.

   Is this realy the intented behavior in RSTP for this trap?  

2) I assume that the state 'Blocking' must be read in RSTP 
   (ref table 17.1 in IEE802.1w-2001) as
   '(port-state == Discarding) + (port-role == Alternate or Backup)'

  This means that  if the MAC  goes operationally down causing the
  link to leave the forwarding state this will not be reported via
  a TRAP. It is unclear for me why this is so, because to me it
  appears that this a real topology changing event.


Thanks,
Hans.
the transition from Forwarding  to


_______________________________________________
Bridge-mib mailing list
Bridge-mib@ietf.org
https://www1.ietf.org/mailman/listinfo/bridge-mib