[Rstplib-users] RE: Question: indirect link fail in 802.1w

[Mick S. <mic...@ie...>]

This certainly works (subject to accuracies of representation in the spec of
what "this" is) without such a handshake (see you closing statement below),
and as the handshake is critically timer dependent it is against the spirit
of .1w. I was aware of the handshake mechanism well before deisgning .1w.

Mick

-----Original Message-----
From: Mick Seaman [mailto:mic...@ie...]
Sent: Tuesday, November 20, 2001 5:14 PM
To: 'Ar...@op...'; 'std...@ie...';
'rst...@li...'; 'bri...@ie...'
Subject: RE: Question: indirect link fail in 802.1w


Alex,

I suggest you test this out using the RSTP Visio simulation.

The only case in which any of these ports could be Backup is a deficiency in
the spec or the interpretation of the spec, so extra protocol is not
required.

Mick

-----Original Message-----
From: own...@ma...
[mailto:own...@ma...]On Behalf Of Alex Ruzin
Sent: Tuesday, November 20, 2001 6:09 AM
To: std...@ie...; rst...@li...;
bri...@ie...
Subject: Question: indirect link fail in 802.1w




Question: indirect link fail in 802.1w

Initial configuration:3 Bridges (A, B, C) are
connected as a triangle.
Let's say, Bridge A is a Root Bridge and has
2 designated ports A1 and A2.
Bridge B has root port B1 (connected with port
A1) and designated port B2, connected with
port C2. Bridge C has root port C1 (connected
with port A2) and Alternate port C2 (connected
with port B2).

Now the link between B1 and A1 fails :(
Bridge B immediately detects the failure and
assumes it is Root Bridge ( while it doesn't
have any Alternate port) and starts to advertise
via port B2 its own Priority Vector.

The problem is on the Bridge C. It receives on
Alternate port C2 SuperiorDesignate Msg BPDU.
It is because 17.19.8:"Designated Bridge and
Designated Port components of the received message
priority vector are the same as those of the port
priority vector and the message priority vector as
a whole or any of the received timer parameter
values (msgTimes -see 17.18.12) differ from
those already held in port-Times (17.18.18).

As a result port C2 goes to have Backup role.

Then, switch B continues to send its BPDU, but
for C these BPDU are "Inferior" or, in terms of
PIM, the function rcbBpdu returns OtherMsg. This
messages are discarded by PIM and there are 3
such messages (6 seconds !).

Only after that the rcvdInfoWhile timer expires,
port C2 is aged, becomes Designated, makes
'handshake' with port B2 (which becomes Root for
the bridge B), and everything is OK.

During about 6 seconds LAN, connected to C was
disconnected from LAN, connected to B ! (Yes, I
know, that in legacy STP such situation causes
a delay 50 seconds: MaxAge + 2 * ForwardDelay).

IMHO, there may take place an optimization, The
idea: don't discard BPDU when 'OtherMsg', but
to start some "upstream' handshake (in addition
to RSTP 'downstream' handshake for rapid
transition Designating port to Forwarding state).
Such 'upstream' handshake may be started, when
SuperiorDesignate message was recognized by
another Times and message Priority Vector is worse
than a stored one.

This idea is similar to "Spanning-Tree Protocol's
Backbone Fast Feature" of CISCO
(see http://www.cisco.com/warp/public/473/18.html)

What do you think about it ? Does this idea break
the concept of 802.1w ? Is it in the plans of the
society ?
What if I start to design such 'handshake' ?

Best regards, Alex