Subject: [Bridge-mib] RE: Question: indirect link fail in 802.1w

From: "Mick Seaman" <[email-masked]>
Date: Tue, 20 Nov 2001 18:06:10 -0800

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:[email-masked]]
Sent: Tuesday, November 20, 2001 5:14 PM
To: [email-masked]'; [email-masked]';
[email-masked]'; [email-masked]'
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: [email-masked]
[mailto:[email-masked]]On Behalf Of Alex Ruzin
Sent: Tuesday, November 20, 2001 6:09 AM
To: [email-masked]; [email-masked];
[email-masked]
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

_______________________________________________
Bridge-mib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bridge-mib

---

From: [email-masked] (Alex Ruzin)
Date: Wed, 21 Nov 2001 08:53:43 +0200

Mick,

I don't understand you: what do you mean under "this certainly
works". Yes, in .1w the topology becomes stable, fully and simply connected,
but after only about 6 seconds.

[Apropos, it seems to me, that the same problem is an explanation
for case of http://www.ieee802.org/1/private/email/msg00348.html]

My proposition is devoted to decrease this time.

Why such handshake is critically timer dependent ? Why it is worse
than the handshake, described in the second half of 17.19 and
using variables like 'proposing', 'propose', 'sync', 'synced' and 'agreed' ?

I propose *in addition* to introduce new and similar variables and to
use new bits in the field "Flags" of RSTP BPDU.

Your reply will be accepted with gratitude.

With respect, Alex

> Sent: Wednesday, November 21, 2001 4:06 AM
> To: 'Mick Seaman'; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]

---

From: [email-masked] (Alex Ruzin)
Date: Wed, 21 Nov 2001 11:16:55 +0200

On Sent: Wednesday, November 21, 2001 9:54 AM Mick Seaman wrote:

Mick > Re: your question on why the  .1w handshake is better than 
Mick > the handshake in
Mick > backbone fast.

I didn't ask it at all (oh, my poor English !) !
I propose to extend this (finest and rapidest !) handshake of .1w in
'upstream' direction. I would like to use the same spirit, logic, speed and
timers independence as .1w handshake !

Nevertheless, it look after Mick's postings, that we needn't do it, because
there is no the problem with "indirect link fail" in 802.1w.
Let us return to this discussion after this question resolving.

Best wishes, Alex

> Sent: Wednesday, November 21, 2001 9:54 AM
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: 802.1w and timer dependencies
> 
> 
> 
> Alex,
> 
> Re: your question on why the  .1w handshake is better than 
> the handshake in
> backbone fast.
> 
> In .1w timers are only used to recover from lost mesages on 
> point to point
> links to bridges/bridge ports that are functioning, in other 
> words the speed
> of recovery does not depend on the timers (except in cases 
> where the maximum
> message transmit limit kicks in). In back bone fast there are 
> messages to
> test if a bridge is "still there", which means that some (not all)
> recoveries have to wait a time for non-response before taking 
> appropriate
> action. This introduces a timer which in its normal case of 
> operation can be
> "tweaked" to improve user performance - which opens the door 
> to overzealous
> tweakers.
> 
> All timers are evil, but some are more evil than others.
> 
> Mick
> 
> From: Alex Ruzin [mailto:[email-masked]]
> Sent: Tuesday, November 20, 2001 10:54 PM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: Question: 'upstream' handshake in 802.1w
> 
> 
> Mick,
>

---

From: "Mick Seaman" <[email-masked]>
Date: Tue, 20 Nov 2001 23:53:53 -0800

Alex,

Re: your question on why the  .1w handshake is better than the handshake in
backbone fast.

In .1w timers are only used to recover from lost mesages on point to point
links to bridges/bridge ports that are functioning, in other words the speed
of recovery does not depend on the timers (except in cases where the maximum
message transmit limit kicks in). In back bone fast there are messages to
test if a bridge is "still there", which means that some (not all)
recoveries have to wait a time for non-response before taking appropriate
action. This introduces a timer which in its normal case of operation can be
"tweaked" to improve user performance - which opens the door to overzealous
tweakers.

Mick

-----Original Message-----
From: Alex Ruzin [mailto:[email-masked]]
Sent: Tuesday, November 20, 2001 10:54 PM
To: [email-masked]; [email-masked];

Mick,

With respect, Alex