rstplib-users

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

[<al...@nb...>]

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

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

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

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

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

[<al...@nb...>]

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

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

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

[<al...@nb...>]

Mick,

[First of all, thank you for the quick reply].
Now, it seems to me, that my analysis is wrong "due" to my invalid
spec. understanding and, hence, invalid implementation.
So would you like to answer on follow questions:

1. Question about rcvBpdu and PIM.
You wrote:
Mick> This will cause C2 to accept the message (because B2 was 
Mick> Designated) and
Mick> immediately override it (because C has information from C1-A1 
Mick> that A is the
Mick> Root), causing C2 to go from  Alternate straight to 
Mick> Designated.

As far as I see, C2 ignores this message: function rcvBpdu returns
'OtherMsg' because, as you correctly wrote, C has information
from C1-A1 that A is the {better} Root). Now PIM simply jumps
to CURRENT and updtRolesBridge() is not invoked.
If it is correct, why C2 goes from  Alternate straight to Designated ?
If it is incorrect, where is my mistake ?

2. Question about SuperiorDesignatedMsg in rcvBpdu.

Actually, In my implementation, rcvBpdu returns SuperiorDesignatedMsg,
because 17.19.8:
"Returns SuperiorDesignatedMsg if the received BPDU is an
RSTP BPDU with a Designated Port Role, or a
Config BPDU, and either the received message priority
vector (see 17.4.2.2) is strictly better than the Port's
port priority vector, or the 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 portTmes (17.18.18)."

In our case we have:
a) it is 'RSTP BPDU with a Designated Port Role';
b) the same Designated Bridge and Designated Port;
c) different msgTimes & portTimes.
Where is my mistake here ?

3. Question about updtRolesBridge()
I've received your message with extract from draft text that
contributed to P802.1wD8
"RSTP Bug in updtBridgeRoles()". I would like to study it carefully;
let me comment/ask about it later.

For some [sad] reasons, I can't use your Visio Simulator. Instead it I use
the simulator from http://sourceforge.net/projects/rstplib/
It has an advantage, that it is OpenSource one and I (as anyone) may freely
trace and debug it :)
But is has disadvantage, that it is based on my own implementation of
'rstplib', with my own bugs and flaws :(

Again, thank you very much for the cooperation.
With great respect
Alex

> -----Original Message-----
> From: Mick Seaman [mailto:mic...@ie...]
> Sent: Wednesday, November 21, 2001 9:43 AM
> To: Ar...@op...; std...@ie...; 
> rst...@li...; bri...@ie...
> Subject: RE: Question: indirect link fail in 802.1w
> 
> 
> 
> 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
> 
> 

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

[<al...@nb...>]

Great & fine - it works !

The point was in Mick's important addition updtRolesBridge() :
"... we are missing the case 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..."

Conclusions:
1. My function rcvBpdu works (and worked) fine, at least till now.
It means, that in the relevant case it must recognize
"SuperiorDesignateMsg".

2. The function updtRolesBridge has been drastically changed and
I allow to myself to attach it (it may be useful to anyone).
Anyway, this change I have committed in
https://sourceforge.net/projects/rstplib/

3. The reconfiguration is really rapid now.

4. Now I'm analyzing another problem, but it will be a new thread
"Root port waits for 'slow' Designated Port in .1w "
and I hope to get a similar help :)

Again, thank to Mr. Mick Seaman very much !
I saw in 802.1y/D1 his proposition 'Z.11' is in <TBD> state. If I may
express
my opinion - it should be accepted ASAP.

With respect, Alex