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

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

I've read "backbone fast" and it doesn't apeared to have changed since I
read it several years ago. However that is not much to the point.


If C2 was not previously Designated it will receive a message from the prior
Designated Bridge for the B2-C2 claiming worse information for this link.
This will cause C2 to accept the message (because B2 was Designated) and
immediately override it (because C has information from C1-A1 that A is the
Root), causng C2 to go from  Alternate straight to Designated. Then C2 spits
out a message with a Designated port that is not yet Forwarding, B gets this
and accepts A as the Root and replies, C on receiving the reply goes
Forwarding.


Time to recover =

Time for B to notice link down +
Time for B to formulate and transmit message to C +
Time for C to receive message from B +
Time for C to formulate and send message to B +
Time for B to receive mesage from C +
Time for B to formulate and transmit message to C +
Time for C to receive message from B +
Time for C to change Port State to Forwarding

Theoretical limit around about 4 * link/speed of light (includes original
link failure) , practical limit set by process scheduling in B and C,
between 4 and 8 scheduling times depending on the software architecture, but
most importantly timer independent recovery.

What we need to diagnose is why you believe C goes to Backup not Designated.
I think this may be because of an ommission we have recognized in
upftBridgeRoles() where an entire case was missed in the editing - where
infoIs == Received but the designated priority is better than the port
priority. In that case selectedRole should be set to DesignatedPort and
updtInfo SET.

Unfortunately the authors of implementations to date were just too familiar
with what should happen in such a case, and the simulation used the
pseudo-code used to derive the English in the standard - but without the
case ommission.

I recommend the use of the simulation to test out these and similar cases.

Mick

-----Original Message-----
From: Alex Ruzin [mailto:al...@nb...]
Sent: Tuesday, November 20, 2001 10:21 PM
To: mic...@ie...; std...@ie...;
rst...@li...; bri...@ie...
Subject: RE: Question: indirect link fail in 802.1w


Mick,

The problem is not in hop to the Backup role, but in "late" hop to
Designated role: only when rcvdInfoWhile timer expires, while we
discard information, that may help in it. I again ask to read
http://www.cisco.com/warp/public/473/18.html, where the explanation
(for 1d) is more detail and clear.

Thanks for the cooperation, Alex


> -----Original Message-----
> From: Mick Seaman [mailto:mic...@ie...]
> Sent: Wednesday, November 21, 2001 3:14 AM
> 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
>
>