rstplib-users — Discussions about fetures & bugs in the packege

[Rstplib-users] RE: [Bridge-mib] I-D ACTION:draft-ietf-bridge-bridgemib-smiv2-01.txt

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

Thank you for the explanations.
Next question: are you going to discuss the possibility to
support an object like dot1dStpPortAdminPathCost to allow automatic
selection of "Port Path Cost" as a function of the speed of the
attached LAN (IEEE 802.1t, Table 8-5) ?

I mean something like (instead of dot1dStpPortPathCost): 
:
          dot1dStpPortAdminPathCost OBJECT-TYPE
              SYNTAX  INTEGER (0..65535)
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                      "The administrative value of the Port Cost parameter.
                       The value 0 means, that Port Cost will be selected
                       automatically in correspondence with the speed of
                       the attached LAN (Table 8-5) and with the value
                       of dot1dStpPathCostDefault."
              REFERENCE
                      "IEEE 802.1w Section 8.5.5.3, 17.16.5, 17.28.2"
              ::= { dot1dStpExtPortEntry 6 }

          dot1dStpPortOperPathCost OBJECT-TYPE
              SYNTAX  INTEGER 
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The operational value of the Port Cost parameter.
                       The contribution of this port to the path cost of
                      paths towards the spanning tree root which include
                      this port.  802.1D-1990 recommends that the
                      default value of this parameter be in inverse
                      proportion to the speed of the attached LAN."
              REFERENCE
                      "IEEE 802.1w Section 8.5.5.3, 17.16.5, 17.28.2"
              ::= { dot1dStpExtPortEntry 7 }

Best regards, Alex

> -----Original Message-----
> From: own...@ma... 
> [mailto:own...@ma...]On Behalf Of Les Bell
> Sent: Monday, December 03, 2001 6:43 PM
> To: Ar...@op...
> Cc: bri...@ie...; std...@ie...; 
> rst...@li...
> Subject: Re: [Bridge-mib] I-D 
> ACTION:draft-ietf-bridge-bridgemib-smiv2-01.txt
> 
> 
> 
> 
> 
> I have just downloaded this draft from the URL:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-bridge-bridgemi
> b-smiv2-01.txt
> 
> It contains the following definitions:
> 
>     dot1dStpTimeSinceTopologyChange OBJECT-TYPE
>         SYNTAX      TimeTicks
>         MAX-ACCESS  read-only
>         STATUS      current
>         DESCRIPTION
>             "The time (in hundredths of a second) since the
>             last time a topology change was detected by the
>             bridge entity.
>             For RSTP, this reports the time since the tcWhile 
> timer for
>             any port on this Bridge was non-zero."
>         REFERENCE
>             " IEEE 802.1w clause 14.8.1.1."
>         ::= { dot1dStp 3 }
> 
>     dot1dStpTopChanges OBJECT-TYPE
>         SYNTAX      Counter32
>         MAX-ACCESS  read-only
>         STATUS      current
>         DESCRIPTION
>             "The total number of topology changes detected by
>             this bridge since the management entity was last
>             reset or initialized.
>             For RSTP, this reports the count of times that there have
>             been at least one non-zero tcWhile timer on this Bridge."
>         REFERENCE
>             " IEEE 802.1w clause 14.8.1.1."
>         ::= { dot1dStp 4 }
> 
> Also, in section 2.1, on page 5, you will find the following 
> explanation as to
> why certain STP parameters have not been included in the MIB. 
>  This is the same
> as in RFC 1493.
> 
>        SpanningTreeProtocolPort
>            .Uptime                     Same as ifLastChange (MIB II)
>            .PortIdentifier             Combination of dot1dStpPort
>                                        and dot1dStpPortPriority
>            .TopologyChangeAcknowledged Since this is transitory, it
>                                        is not considered useful.
>            .DiscardLackOfBuffers       Redundant
> 
> 
> I have included the Port Role (along with the legacy 
> neighbour and the received
> BPDU counts) in the list of issues to be discussed at the 
> IETF Bridge-MIB WG
> meeting in Salt Lake City next week.
> 
> Les...
> 
> 
> 
> 
> 
> al...@nb... (Alex Ruzin)@ietf.org on 02/12/2001 10:16:36
> 
> Please respond to <Ar...@Op...>
> 
> Sent by:  bri...@ie...
> 
> 
> To:   <Int...@ie...>, <bri...@ie...>, 
> <std...@ie...>,
>       <rst...@li...>
> cc:
> Subject:  Re: [Bridge-mib] I-D 
> ACTION:draft-ietf-bridge-bridgemib-smiv2-01.txt
> 
> 
> Hi,
> 
> I can't find in the draft (as far as in the legacy MIB):
> - In the "Bridge protocol parameters"  - "Topology Change" 
> (14.8.1.1.3.d);
> legacy STP RFC1493 had
>   only dot1dStpTimeSinceTopologyChange (reflects "Time Since Topology
> Change", 14.8.1.1.3.b)
>   and dot1dStpTopChanges ("Topology Change Count", 14.8.1.1.3.c)
> 
> - In "Port Parameters" - Uptime (18.8.2.1.3.a) and "Topology Change
> Acknowledge" (14.8.2.1.3.i)
> 
> Would you like to point me, which old or new MIB fields reflect these
> parameters ?
> Or: why they are not reflected ?
> 
> Are IETF & IEEE going to get as managed objects "Port Role" ?
> 
> Best regards, Alex
> 
> 
> _______________________________________________
> Bridge-mib mailing list
> Bri...@ie...
> https://www1.ietf.org/mailman/listinfo/bridge-mib
> 
> 
> 
> 

[Rstplib-users] Re: [Bridge-mib] I-D ACTION:draft-ietf-bridge-bridgemib-smiv2-01 .txt

[Les B. <Les...@eu...>]

I have just downloaded this draft from the URL:

http://www.ietf.org/internet-drafts/draft-ietf-bridge-bridgemib-smiv2-01.txt

It contains the following definitions:

    dot1dStpTimeSinceTopologyChange OBJECT-TYPE
        SYNTAX      TimeTicks
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "The time (in hundredths of a second) since the
            last time a topology change was detected by the
            bridge entity.
            For RSTP, this reports the time since the tcWhile timer for
            any port on this Bridge was non-zero."
        REFERENCE
            " IEEE 802.1w clause 14.8.1.1."
        ::= { dot1dStp 3 }

    dot1dStpTopChanges OBJECT-TYPE
        SYNTAX      Counter32
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "The total number of topology changes detected by
            this bridge since the management entity was last
            reset or initialized.
            For RSTP, this reports the count of times that there have
            been at least one non-zero tcWhile timer on this Bridge."
        REFERENCE
            " IEEE 802.1w clause 14.8.1.1."
        ::= { dot1dStp 4 }

Also, in section 2.1, on page 5, you will find the following explanation as to
why certain STP parameters have not been included in the MIB.  This is the same
as in RFC 1493.

       SpanningTreeProtocolPort
           .Uptime                     Same as ifLastChange (MIB II)
           .PortIdentifier             Combination of dot1dStpPort
                                       and dot1dStpPortPriority
           .TopologyChangeAcknowledged Since this is transitory, it
                                       is not considered useful.
           .DiscardLackOfBuffers       Redundant


I have included the Port Role (along with the legacy neighbour and the received
BPDU counts) in the list of issues to be discussed at the IETF Bridge-MIB WG
meeting in Salt Lake City next week.

Les...





al...@nb... (Alex Ruzin)@ietf.org on 02/12/2001 10:16:36

Please respond to <Ar...@Op...>

Sent by:  bri...@ie...


To:   <Int...@ie...>, <bri...@ie...>, <std...@ie...>,
      <rst...@li...>
cc:
Subject:  Re: [Bridge-mib] I-D ACTION:draft-ietf-bridge-bridgemib-smiv2-01.txt


Hi,

I can't find in the draft (as far as in the legacy MIB):
- In the "Bridge protocol parameters"  - "Topology Change" (14.8.1.1.3.d);
legacy STP RFC1493 had
  only dot1dStpTimeSinceTopologyChange (reflects "Time Since Topology
Change", 14.8.1.1.3.b)
  and dot1dStpTopChanges ("Topology Change Count", 14.8.1.1.3.c)

- In "Port Parameters" - Uptime (18.8.2.1.3.a) and "Topology Change
Acknowledge" (14.8.2.1.3.i)

Would you like to point me, which old or new MIB fields reflect these
parameters ?
Or: why they are not reflected ?

Are IETF & IEEE going to get as managed objects "Port Role" ?

Best regards, Alex


_______________________________________________
Bridge-mib mailing list
Bri...@ie...
https://www1.ietf.org/mailman/listinfo/bridge-mib

[Rstplib-users] Re: [Bridge-mib] I-D ACTION:draft-ietf-bridge-bridgemib-smiv2-01.txt

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

Hi,

I can't find in the draft (as far as in the legacy MIB):
- In the "Bridge protocol parameters"  - "Topology Change" (14.8.1.1.3.d);
legacy STP RFC1493 had
  only dot1dStpTimeSinceTopologyChange (reflects "Time Since Topology
Change", 14.8.1.1.3.b)
  and dot1dStpTopChanges ("Topology Change Count", 14.8.1.1.3.c)

- In "Port Parameters" - Uptime (18.8.2.1.3.a) and "Topology Change
Acknowledge" (14.8.2.1.3.i)

Would you like to point me, which old or new MIB fields reflect these
parameters ?
Or: why they are not reflected ?

Are IETF & IEEE going to get as managed objects "Port Role" ?

Best regards, Alex

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

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

The Visio will let you see all the state variables on each port, so you can
construct a scenario and match an implementation step by step against it.

-----Original Message-----
From: own...@ma...
[mailto:own...@ma...]On Behalf Of Alex Ruzin
Sent: Tuesday, November 27, 2001 1:50 AM
To: mic...@ie...; std...@ie...;
rst...@li...
Subject: RE: [Rstplib-users] RE: Root port waits for 'slow' Designated Port
in .1w ?



Dear Mr. Seaman,

On Tuesday, November 27, 2001 9:48 AM you wrote:

Mick> I really do suggest you get your management to buy you a PC
Mick> and a copy of Visio so you can test this and all the other cases
Mick> you will find while debugging your code with a tool (the simulation
Mick> avaible on the .1 website)
Mick> that a significant number of others have already debugged.

I have just checked the Visio. It helps to see, *what must* be,
but doesn't help to understand *why* & *how* and why my (or any
other) implementation doesn't work properly. It could help here if the
sources is open, but they are not :(
You don't want to public the sources as 'procedural model',
like 8.9 in 802.1d, do you ?

Anyway, I will use Visio to verify my implementation.

From other side I tried to make my state machines implementation
as formal as possible. And my questions (I hope so) are related to
the .1w, not to the implementation and bugs in it.
[For example, the result of our previous discussion "indirect link
fail in 802.1w" was, that I implemented some your important change
in the official edition of .1w]

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

Would you like to point me to the place in the .1w ?

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

You are completely right, in the case port  C1 has to hop to
DESIGNATED LISTEN and all will be OK!
So, after this your mail it works fine.

Thank you very much, Alex

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

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

Dear Mr. Seaman,

On Tuesday, November 27, 2001 9:48 AM you wrote:

Mick> I really do suggest you get your management to buy you a PC 
Mick> and a copy of Visio so you can test this and all the other cases
Mick> you will find while debugging your code with a tool (the simulation
Mick> avaible on the .1 website)
Mick> that a significant number of others have already debugged. 

I have just checked the Visio. It helps to see, *what must* be,
but doesn't help to understand *why* & *how* and why my (or any
other) implementation doesn't work properly. It could help here if the
sources is open, but they are not :(
You don't want to public the sources as 'procedural model',
like 8.9 in 802.1d, do you ?

Anyway, I will use Visio to verify my implementation.

From other side I tried to make my state machines implementation
as formal as possible. And my questions (I hope so) are related to
the .1w, not to the implementation and bugs in it.
[For example, the result of our previous discussion "indirect link
fail in 802.1w" was, that I implemented some your important change
in the official edition of .1w]

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

Would you like to point me to the place in the .1w ? 

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

You are completely right, in the case port  C1 has to hop to
DESIGNATED LISTEN and all will be OK! 
So, after this your mail it works fine.

Thank you very much, Alex

[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

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

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

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

[Rstplib-users] (no subject)

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

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

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

[Rstplib-users] RE: 802.1w and timer dependencies

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

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


> -----Original Message-----
> From: Mick Seaman [mailto:mic...@ie...]
> Sent: Wednesday, November 21, 2001 9:54 AM
> To: Ar...@op...; std...@ie...; 
> rst...@li...; bri...@ie...
> 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
> 
> -----Original Message-----
> From: Alex Ruzin [mailto:al...@nb...]
> Sent: Tuesday, November 20, 2001 10:54 PM
> To: mic...@ie...; std...@ie...;
> rst...@li...; bri...@ie...
> Subject: RE: Question: 'upstream' handshake in 802.1w
> 
> 
> 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
> 
> > -----Original Message-----
> > From: Mick Seaman [mailto:mic...@ie...]
> > Sent: Wednesday, November 21, 2001 4:06 AM
> > To: 'Mick Seaman'; Ar...@op...;
> > std...@ie...; rst...@li...;
> > bri...@ie...
> > Subject: RE: Question: indirect link fail in 802.1w
> >
> >
> >
> > 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:mic...@ie...]
> > Sent: Tuesday, November 20, 2001 5:14 PM
> > 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
> >
> 

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

[Rstplib-users] 802.1w and timer dependencies

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

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

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


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

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

[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: 'upstream' handshake in 802.1w

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

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

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

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

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:mic...@ie...]
Sent: Tuesday, November 20, 2001 5:14 PM
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...>]

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] 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: Open Source 802.1w Library & Simulator

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

On Thursday, November 15, 2001 1:07 AM Vipin Jain wrote:

Vipin > Alex, how do I download the executable /dll?

Currently I don't distribute executable /dll (and I don't think I will).
You should download source codes & the Makefile and compile
the project. If your have another platform (not Linux RedHat), you
may want to write your own Makefile or/and to use another tools
instead of libcli.a & libuid.a
Anyway, the main library librstp.a is an system independent one,
sure on the source code level.


Rest regards, Alex

[Rstplib-users] RE: Open Source 802.1w Library & Simulator

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

The new release of <subj> has been committed today.
(see https://sourceforge.net/projects/rstplib/)

The changes are:

- All per Port variables have been moved from the State
  Machines into the Port instance (it made the state
  machines much more clear)

- In libcli.a instead of stupid fgets() function we use
  now readline (thanks to Michael Roshavsky)

- 'mcheck' support

- 'nonStp' support (I know, that it is out the standard,
  but it seems to be useful (see a discussion on
http://www1.ietf.org/mail-archive/working-groups/bridge/current/msg00038.htm
l)
  and our customers demand it

- The function rolesel.c has been drastically fixed, IMHO
  closer to the standard

- Nicer output

You are welcome to download & enjoy
Rest regards, Alex

[Rstplib-users] RE: Rapid Spanning Tree 802.1w Simulator

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

Dear Michael,
[My congratulations: you are the first poster in the mailing list !]

I passed the same stages as you: I've developed 802.1D before 5 years
and now I has been confused, that 802.1w doesn't have a procedural model.
So, I had to implement it "from scratch".

Yes, I have more information about the implementation; below I'll try to
answer
on your questions. From other side, the most relevant information
you may find in the project itself - it is open source project. Download
it, try to compile and run, and see the code.

> 1. what [do] you want to do ?
The good idea: in the nearest future I'll commit TODO file.
Briefly:
On the first stage I am going to debug it (and I hope to get help from
Source Forge like you) and take approval from IEEE. Among other, I have to
support
all management from 14.8 (now I missed, at least, 'mcheck').

Next: to implement multiple RSTP per VLAN. Actually, I have implemented the
case,
when for one VLAN there is one RSTP instance. Next will be one RSTP instance
for
list of VLANs, and after that it will be full 802.1s (MSTP) implementation.

Next, may be, optimizations for a ring case.

> 2. how the software should work, targets to run and so on.

As you may see from the sources, the project has system independent RSTP
library.
This library may (and should) be linked in any real environment. In the
project it
is linked with simple simulating program 'bridge', which gets/sends BPDUs as
messages via UDP socket.

Actually, this project is an open source part of our real (commercial)
products
and due the reasonable Source Forge agreements I can't do advertisement,
but if you want - find our internet site and see there the product list.

The "state machines engine" takes a separate place in the project. It allows
to implement
all complicated 802 standards almost in formal way.

I look forward to working with you in the frame of the project as this
technology evolves.

Best wishes. Alex

> -----Original Message-----
> From: nobody [mailto:no...@so...]On Behalf Of Michael
> Koestner
> Sent: Tuesday, November 13, 2001 11:28 AM
> To: al...@nb...
> Subject: Rapid Spanning Tree 802.1w Simulator
>
>
> Hi Alex,
>
> your project is very interesting for me. I have had already
>
> long time scope on the project IEEE802.1w. But there so few
>
> information in the draft. I miss example code like you can
>
> found in 802.1D for spanning tree cap. 8. Have you more
>
> information about implementation ? Can you give me more
>
> background of your project, like what you want to do, how
>
> the software should work, tragets to run and so on.
>
> I am a software developer at siemens and responsible for
>
> network components. I have made this job for 5 years and
>
> helped to developed a propritary redundancy algorithem for
>
> a simple ring topologie.
>
> So I hope you can give me quit more infromations:-)
>
> Regards
>
> Michael
>

[Rstplib-users] "Slow" reconfiguration in 802.1w when Bridge Priority is changed by management

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

It looks like the reconfiguration of the RSTP domain works
too slow when the Bridge priority is changed by management.

Consider the simplest case: two Bridges are connected with one
connection.

Now on the Bridge, that is not currently RootBridge, let us
decrease the Priority so, that it becomes RootBridge.

I see, that the domain becomes stable only after 4 seconds;
the previous designated port becomes a Backup, after that - Root.

Here is a trace (sorry):

16:47:45 B8322 > get-st-pcfg
 BridgeId: 8000-008220000001  RootId: 8000-008120000001
     p01 8001 Fwd  8000-008120000001 8000-008120000001 8001 R
 E   p02 8002 Dis  8000-008120000001 8000-008220000001 8002
 E   p03 8003 Dis  8000-008120000001 8000-008220000001 8003
 E   p04 8004 Dis  8000-008120000001 8000-008220000001 8004
16:48:06 B8322 > set-br-prio 0x4000
Changed rstp bridge priority
16:48:27 B8322 >
16:48:27:brige B8322 became root - bpdu
16:48:27:rec(B8322-p01) => Backup
16:48:27:roletrns(B8322-p01): ROOT_PORT=>BLOCK_PORT
16:48:27:topoch  (B8322-p01): TCACTIVE=>INIT
16:48:27:topoch  (B8322-p01): INIT=>INACTIVE
16:48:27:sttrans (B8322-p01): FORWARDING=>DISCARDING
16:48:27:roletrns(B8322-p01): BLOCK_PORT=>BLOCKED_PORT
16:48:27:roletrns(B8322-p01): BLOCKED_PORT=>BACKUP_PORT
16:48:27:roletrns(B8322-p01): BACKUP_PORT=>BLOCKED_PORT
16:48:28:roletrns(B8322-p01): BLOCKED_PORT=>BACKUP_PORT
16:48:28:roletrns(B8322-p01): BACKUP_PORT=>BLOCKED_PORT
16:48:29:roletrns(B8322-p01): BLOCKED_PORT=>BACKUP_PORT
16:48:29:roletrns(B8322-p01): BACKUP_PORT=>BLOCKED_PORT
16:48:30:roletrns(B8322-p01): BLOCKED_PORT=>BACKUP_PORT
16:48:30:roletrns(B8322-p01): BACKUP_PORT=>BLOCKED_PORT
16:48:31:roletrns(B8322-p01): BLOCKED_PORT=>BACKUP_PORT
16:48:31:roletrns(B8322-p01): BACKUP_PORT=>BLOCKED_PORT
16:48:31:Age(B8322-p01) => Designated
16:48:31:roletrns(B8322-p01): BLOCKED_PORT=>DESIGNATED_PORT
16:48:31:roletrns(B8322-p01): DESIGNATED_PORT=>DESIGNATED_PROPOSE
16:48:31:roletrns(B8322-p01): DESIGNATED_PROPOSE=>DESIGNATED_PORT
16:48:31:roletrns(B8322-p01): DESIGNATED_PORT=>DESIGNATED_SYNCED
16:48:31:roletrns(B8322-p01): DESIGNATED_SYNCED=>DESIGNATED_PORT
16:48:31:topoch  (B8322-p01): INACTIVE=>TCACTIVE
16:48:31:(B8322-p01) rx AGREEMENT flag !
16:48:31:roletrns(B8322-p01): DESIGNATED_PORT=>DESIGNATED_LEARN
16:48:31:roletrns(B8322-p01): DESIGNATED_LEARN=>DESIGNATED_PORT
16:48:31:roletrns(B8322-p01): DESIGNATED_PORT=>DESIGNATED_FORWARD
16:48:31:roletrns(B8322-p01): DESIGNATED_FORWARD=>DESIGNATED_PORT
16:48:31:sttrans (B8322-p01): DISCARDING=>LEARNING
16:48:31:sttrans (B8322-p01): LEARNING=>FORWARDING
16:48:31:topoch  (B8322-p01): TCACTIVE=>DETECTED
16:48:31:clearFDB (p01, B8322, other ports, 'DETECTED')
16:48:31:topoch  (B8322-p01): DETECTED=>TCACTIVE

When these 3 Bridges are connected "as a triangle", the problem is harder.

I am working 2 days to analyze it, but may be you can help me ?

The questions are:
Is this a bug in my implementation, or flow in the algorithm, or
appropriative  behavior ?
Do another implementations have the same problem ?

Best regards, Alex