[Rstplib-users] RE: RSTP questions and one 802.1y/D2 issue

[<rob...@ya...>]

Mick (or anyone),
Where may I get this "betterorsame" procedure ?
Thanks, Robert

 --- Mick Seaman <mic...@ie...> wrote: > 
> Les,
> 
> "betterorsame" fully covers the case "(msgPriority
> != portPriority)that you
> suggested, and further it means that cust don't get
> propagated continually
> and unnecessarily as information gets better.
> 
> To Brandon's point, we don't need the enter
> ROOT_PROPOSED and cause a resync
> if the Root POrt already has agree set (agreed in
> .1w).
> 
> This is the mechanism in .1s that stops needless
> cuts getting out of a
> region, it works equally well in .1w to not have
> information (which tends to
> get better in stages after a reconfig when all prior
> root information is
> lost) causing repeated resynchronizations together
> with repeated flushes.
> 
> Mick
> 
> -----Original Message-----
> From: own...@ma...
> [mailto:own...@ma...]On
> Behalf Of Les Bell
> Sent: Friday, February 01, 2002 1:56 AM
> To: mic...@ie...
> Cc: std...@ie...
> Subject: RE: RSTP questions and one 802.1y/D2 issue
> 
> 
> 
> 
> 
> Hi Mick,
> 
> When a legacy STP v0 Bridge sends a TC-ACK, the
> hold_timer ensures that at
> least
> 1 tick has expired since the last BPDU before it can
> send the BPDU with this
> TC-ACK.  Also, message_age_timer is incremented
> every tick.  This ensures
> the
> msgTimes in the BPDU carrying the TC-ACK differ from
> those previously sent
> (unless this is the Root Bridge, or if HelloTime==1
> and this Bridge has
> received
> another BPDU on its own Root Port, to reset
> message_age_timer).  The
> msgPriority
> in the BPDU with the TC-ACK will be the same as
> previously sent, unless
> other
> changes in the network have been detected.
> 
> If the msgPriority is the same as the portPriority,
> then the only reason you
> would enter the PIM:SUPERIOR state is because the
> msgTimes differs from
> portTimes.  This is the case described above.  If
> you clear Agreed and
> synced,
> it will cause the PRT:ROOT_AGREED state to set
> newInfo, which in turn forces
> the
> transition to the PTX:TRANSMIT_TCN to send another
> TCN BPDU.  This causes
> the
> legacy STP v0 Bridge to send another TC ACK, which
> will have a different
> value
> in msgTimes (unless HelloTime==1) hence continually
> repeating the cycle of
> TCN/TC-ACK BPDUs.
> 
> So you should not clear synced and agreed if
> msgPriority and portPriority
> are
> the same.
> 
> I recommend the following, in the PIM:SUPERIOR
> state:
> 
> agreed = agreed && (msgPriority != portPriority);
> synced = synced && agreed;
> 
> A similar change should be applied to 802.1s.
> 
> Les...
> 
> 
> 
> 
> 
> "Mick Seaman" <mic...@ie...> on 01/02/2002
> 07:14:46
> 
> Please respond to mic...@ie...
> 
> Sent by:  "Mick Seaman" <mic...@ie...>
> 
> 
> To:   "'Tony Jeffree'" <to...@je...>,
> std...@ie...
> cc:    (Les Bell/GB/3Com)
> Subject:  RE: RSTP questions and one 802.1y/D2 issue
> 
> 
> 
> 
> 
> 
> 802.1y/D2 contains a partial implementation of
> changes suggested to fix a
> problem that Les Bell raised (see Brandon's first
> point below). What y/D2
> should have said is that PIM:SUPERIOR is changed so
> that agreed and synced
> are conditionally set FALSE (i.e. not changed from
> always set FALSE is this
> state to never set FALSE.
> 
> The correct treatment of agreed and synced in this
> state is specified in
> .1sD11. The comparison is a little confusing since
> .1s introduces the
> variable agree to get around the overloading of the
> agreed variable that
> takes place in .1w. The easiest way to keep our
> sanity going forward is, I
> believe to add the agree variable to .1y/D2, then
> the .1w text can strictly
> follow that of .1s. If we don't do this then
> PIM:SUPERIOR in .1y should have
> the lines:
> 
> agreed = agreed && betterorsameInfo();
> synced = synced && agreed;
> 
> added, and the procedure defined analagous to .1s.
> 
> Mick
> 
> 
> 
> -----Original Message-----
> From: own...@ma...
> [mailto:own...@ma...]On
> Behalf Of Tony Jeffree
> Sent: Thursday, January 31, 2002 8:32 AM
> To: std...@ie...
> Subject: Fwd: RSTP questions and one 802.1y/D2 issue
> 
> 
> 
> 
> >Envelope-to: to...@je...
> >X-Authentication-Warning: io.iol.unh.edu: bbarry
> owned process doing -bs
> >Date: Fri, 4 Jan 2002 10:29:14 -0500 (EST)
> >From: "Brandon W. Barry" <bb...@io...>
> >To: to...@je...
> >Subject: RSTP questions and one 802.1y/D2 issue
> >
> >Tony,
> >
> >It appears to me that The PIM: SUPERIOR state
> optimization proposed in
> >802.1y/D2 could in some cases prevent Designated
> Ports from receiving the
> >confirmation needed in order to transition rapidly
> into the Forwarding
> >Port State.
> >
> >Suppose a Port receives an RST BPDU (indicating the
> Designated Port Role,
> >with the proposal flag set) containing a message
> priority vector better
> >than the port priority vector held for the Port. If
> synced is not set
> >False in the PIM: SUPERIOR state, and the receiving
> Port is both
> >forwarding and synced, the Port will not enter the
> PRT: ROOT_PROPOSED
> >state (assuming the information contained in the
> Superior Designated
> >Message causes the PRS machine to select the Root
> Port Role for said
> >Port).
> >
> >Consequently, the new Root Port would not run the
> setSyncBridge()
> >procedure, and none of the Designated Ports (which
> are no longer
> >synced after their transition through the PIM:
> UPDATE 
=== message truncated ===