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