[Rstplib-users] RE: Root port waits for 'slow' Designated Port in .1w ?

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

I really do suggest you get your management to buy you a PC and a copy of
Visio so you can test this and all the other cases you will find while
debugging your code with a tool (the simulation avaible on the .1 website)
that a significant number of others have already debugged. My travel
schedule next month could leave you waiting for answers for weeks.

It is true that a Designated Port with a point to point link to an Alternate
Port does not transition to Forwarding quickly. To do so would violate some
of the (current at least) assumptions that underlie the proof that Root
Ports can be transitioned without permission from their neighbour without
causing loops. Fortunately since the Designated Port only leads to the
Alternate Port and to no (other) end stations there is no denial of service.

It is not clear from your description where the "problem" of
non-communication is. However I would sugest that rrWhile should be cleared
as soon as all prior root ports are no longer listening or learning (and
that this is already specified in the standard) so there is little (read as
short as an individual bridge  implementation can manage it) delay for C2 to
become Forwarding once it is Root Port. You seem to be missing the code that
causes ports that have rrWhile not cleared to revert to Listening once
reRoot is set by another port.

Mick

-----Original Message-----
From: own...@ma...
[mailto:own...@ma...]On Behalf Of Alex Ruzin
Sent: Sunday, November 25, 2001 7:16 AM
To: mic...@ie...; std...@ie...;
rst...@li...
Subject: Q: Root port waits for 'slow' Designated Port in .1w ?



Let's consider the following initial configuration: we
have 3 Bridges (A, B, C) ,
Bridge A has a Designated Port A2, connected to Root Port B1 of
Bridge B. Bridge B is connected to Port C1 of Bridge C via Designated
Port B2.
Bridge A has the "best" Bridge priority and always will be Root Bridge.
Bridge C has Bridge priority "better" then Bridge B and worse then Bridge A.

Now we will close the ring: connect Port C2 to A1.
Port C2 becomes Root Port of the C, Port C1 changes its role from
Root to Designated; on Bridge B Port B2 changes its role from Designated to
Alternate and becomes Discarding.

The problem is that Port C2 becomes Forwarding not immediately but
after FdDelay ("slow" hop)

Explanation.
Actually, the problem seems to be between C1 & B2. Port C1 goes
from Root to Designating, however since it was in Forwarding state and PRT
(17.23.2) doesn't go to DESIGNATED_PROPOSE, it waits for rrWhile
expiration (15 seconds). During this time Port C2 reRooted is equal False
due to rrWhile on port C1.

The question:
What is wrong ? Or: is it an appropriative behavior ?

Another related question:
I see, that when a Designated Port wants to change to Forwarding state,
but its partner is an Alternate port,
it waits for 'agreed' flag and makes *slow* state transition too.
I think, it is not a "big deal", since anyway the active topology doesn't
contain this connection. Am I right ?

Thanks for your help,
Alex