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

[Rstplib-users] RE: 802.1w: 3 questions about flushing

[Imagine T. <ter...@ya...>]

Benny,
Did you see a proposition of Les in
http://www.ieee802.org/1/private/email/msg00564.html ?
He proposes to use TC-ACK bit (like in legacy 802.1d) 
to avoid this effect. What do you think about it ?
Best regards, Imagine

Benny Thottakkarawrote:
> On Monday, January 07, 2002 Albina Krigma-Lee wrote:
> 
> Albina > Question 1. tcWhile decrementing.
> Albina > When Topology Change is DETECTED, the timer
> tcWhile
> Albina > accepts a value 4 (twice HelloTime). Then,
> the PTM binds
> Albina > "topology change flag" in BPDU. While in
> pure RSTP
> Albina > LAN there are no "topology change
> acknowledgements",
> Albina > this timer is decremented until 0 "by
> natural".
> Albina > So, there are 2 outgoing BPDU with
> "topology change
> Albina > flag": the Albina > first – when tcWhile=4;
> the second
> Albina > – when tcWhile=2.
> Albina > If the considerations above are right, it
> seems, that Alex is
> Albina > optimist: it will be "triple" flushing, not
> double!
> 
> Alex>I would like to believe, that txHoldTimer will
> prevent it
> 
> Benny: I think what Alex says is  wrong. There is a
> triple flushing
> happening in this case  if we strictly implement the
> standrad. txholdCount only helps to rate the RST
> BPDUs (config BPDUs or
> TCNs) when the hello timer is active.
> When the Hello timer expires , txHoldCount is again
> set to 0. correspoding
> to each tcwhile timer expiry , there are
> two hello timer expiries. So a TC information is
> propagated (RST BPDU with
> TC flag set) atleast thrice.
> 


__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/

[Rstplib-users] (no subject)

[Elisabeth G. <gre...@ho...>]

Mick,

Could you be more condescending and tolerant, please?
Would you like to refer to exact statement[s] in
Clause 17.10 and explain: while cannot WG to insert
in .1y "TC-ACK in a RSTP BPDU" as Les proposes?

regards, Beth


>-----Original Message-----
>From: own...@ma... 
>[mailto:own...@ma...]On Behalf Of Mick Seaman
>Sent: Wednesday, March 06, 2002 9:13 AM
>To: Ar...@op...; std...@ie...
>Subject: RE: RSTP TC propagation in large networks
>
>
>
>
>Just read .1w
>
>-----Original Message-----
>From: Alex Ruzin [mailto:al...@nb...]
>Sent: Tuesday, March 05, 2002 10:58 PM
>To: mic...@ie...; 'Les Bell'; std...@ie...
>Subject: RE: RSTP TC propagation in large networks
>
>
>On Wednesday, March 06, 2002 1:49 AM Mick Seaman replied:
>Mick> [snipped]
>Mick> Moreover the prior ack scheme only works
>Mick> if the entire network gets flushed wherever the change occurs, see 
>the
>Mick> material in .1w Clause 17.10.
>
>Would you like to explain: why "ack scheme" will prevent "entire network
>gets flushed"?
>It seems to me, that entire network would be flushed, but only once.
>What is bad in this?
>Les's proposition seems to be obvious, simple and effective.
>
>Mick> Let's talk at the meeting next week.
>
>And what about "simple people", that will no take participation in the
>meeting.
>Would you provide the discussion (or at least, conclusion) in the mailing
>list, please.
>
>With respect, Alex


_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

[Rstplib-users] RE: RSTP TC propagation in large networks

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

On Wednesday, March 06, 2002 1:49 AM Mick Seaman replied:
Mick> [snipped]
Mick> Moreover the prior ack scheme only works
Mick> if the entire network gets flushed wherever the change occurs, see the
Mick> material in .1w Clause 17.10.

Would you like to explain: why "ack scheme" will prevent "entire network
gets flushed"?
It seems to me, that entire network would be flushed, but only once.
What is bad in this?
Les's proposition seems to be obvious, simple and effective.

Mick> Let's talk at the meeting next week.

And what about "simple people", that will no take participation in the
meeting.
Would you provide the discussion (or at least, conclusion) in the mailing
list, please.

With respect, Alex
---------------------
Open Source RSTP  http://rstplib.sourceforge.net
Optical Access Ltd. http://www.opticalaccess.com

>> On Tuesday, March 05, 2002 7:11 AM Les Bell wrote
>Les> When a RSTP Bridge, Bridge 1, detects a topology change, it
>Les> propagates it to
>Les> all
>Les> other ports for 4 seconds (2*HelloTime).
>Les>
>Les> When a RSTP Bridge, Bridge 2, receives a TC indication in a BPDU, it
>Les> propagates
>Les> it for 4 seconds on all other ports.  This will begin as soon
>Les> as it receives
>Les> the
>Les> first TC from Bridge 1, and the propagation period will begin
>Les> again after it
>Les> receives the next BPDU with a TC indication from Bridge 1.
>Les> As a result,
>Les> Bridge
>Les> 2 will propagate the TC for a period of up to 8 seconds (i.e.
>Les> from the time
>Les> it
>Les> receives the first TC, until 4 seconds after it receives the
>Les> last TC from
>Les> Bridge
>Les> 1).
>Les>
>Les> Bridge 3 will receive a TC from Bridge 2 and begin
>Les> propagating it.  This
>Les> will
>Les> continue until 4 seconds after it has received the last TC
>Les> indication from
>Les> Bridge 2, giving a total period of up to 12 seconds for TC
>Les> propagation from
>Les> Bridge 3.
>Les>
>Les> And so on...
>Les>
>Les> In a large network, it can be seen that a topology change at
>Les> one end of the
>Les> network can cause repeated flushing at the other end of the
>Les> network for a
>Les> considerable period.
>Les>
>Les> If a RSTP Bridge receives a TC-ACK from a legacy STP Bridge,
>Les> it cancels the
>Les> tcWhile timer, thus stopping further propagation of the TC on
>Les> that port.
>Les>
>Les> So why is TC-ACK never set in a RSTP BPDU?
>Les>
>Les> If we set TC-ACK in a RSTP BPDU, it would stop the unnecessary TC
>Les> propagation
>Les> and prevent the period of flushing the ports from increasing as the TC
>Les> propagates to the other end of the network.
>Les>
>Les> Les...

[Rstplib-users] RE: RSTP TC propagation in large networks

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

Les,
It seems to be the continuation of the former discussion
(see the thread "802.1w: double flushing in simplest case ?"
from http://www.ieee802.org/1/private/email/msg00421.html and 
http://www.ieee802.org/1/private/email/msg00438.html)
We are very interesting in its results.
Alex

> -----Original Message-----
> From: own...@ma... 
> [mailto:own...@ma...]On Behalf Of Les Bell
> Sent: Tuesday, March 05, 2002 5:11 PM
> To: std...@ie...
> Subject: RSTP TC propagation in large networks
> 
> 
> 
> 
> 
> 
> When a RSTP Bridge, Bridge 1, detects a topology change, it 
> propagates it to all
> other ports for 4 seconds (2*HelloTime).
> 
> When a RSTP Bridge, Bridge 2, receives a TC indication in a 
> BPDU, it propagates
> it for 4 seconds on all other ports.  This will begin as soon 
> as it receives the
> first TC from Bridge 1, and the propagation period will begin 
> again after it
> receives the next BPDU with a TC indication from Bridge 1.  
> As a result, Bridge
> 2 will propagate the TC for a period of up to 8 seconds (i.e. 
> from the time it
> receives the first TC, until 4 seconds after it receives the 
> last TC from Bridge
> 1).
> 
> Bridge 3 will receive a TC from Bridge 2 and begin 
> propagating it.  This will
> continue until 4 seconds after it has received the last TC 
> indication from
> Bridge 2, giving a total period of up to 12 seconds for TC 
> propagation from
> Bridge 3.
> 
> And so on...
> 
> In a large network, it can be seen that a topology change at 
> one end of the
> network can cause repeated flushing at the other end of the 
> network for a
> considerable period.
> 
> If a RSTP Bridge receives a TC-ACK from a legacy STP Bridge, 
> it cancels the
> tcWhile timer, thus stopping further propagation of the TC on 
> that port.
> 
> So why is TC-ACK never set in a RSTP BPDU?
> 
> If we set TC-ACK in a RSTP BPDU, it would stop the 
> unnecessary TC propagation
> and prevent the period of flushing the ports from increasing as the TC
> propagates to the other end of the network.
> 
> Les...
> 
> 

[Rstplib-users] RSTP compatibility

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

Dear Mr. Goubert,

I came to conclusion to warn you, that the patch to Ethereal I sent
has been designed/checked for our
RSTP product and RSTPLib only and may be incompatible with IEEE 802.w
(while I hope, that it is compatible).
We are very interesting to verify it onto another products.
Let us  know your tests results, please.

Another question: do you plan to use Open Source  RSTPLib
on http://rstplib.sourceforge.net/ for your purposes? We will consider it as
a great honor.
[please, reply to me and to rst...@li...]

Best regards, Alex
---------------------
Open Source RSTP  http://sourceforge.net/projects/rstplib/
Optical Access Ltd. http://www.opticalaccess.com

[Rstplib-users] RE: RST BPDU in Ethereal

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

On Thursday, February 28, 2002 5:13 PM Gerard Goubert wrote:
> Alex,
>
> Ahhh! I am using ethereal for windows not linux that explains the
> confusion.
> I see your other message with the attached c file. I need to
> compile it
> and then ??? put it in the Ethereal directory?
Yes, simply compile it instead of original packet-bpdu.c

>
> We are very interested in RSTP, in fact we have developed a full test
> suite to test different implementations. We are working on
> scripting/automating the testing right now.
>
> I work for the IOL (www.iol.unh.edu) and we test all sorts of
> networking
> related technologies for conformance and interoperability.
> My specific group is BFC (Bridge Functions Consortium) and
> can be found
> here:
> http://www.iol.unh.edu/consortiums/bfc/
>
>
> All of our test suites (for Bridge Functions) can be found here:
> http://www.iol.unh.edu/testsuites/bfc/
>
> Please take a look, we would be very interested in helping
> you test your
> implementation of RSTP.

Fine, would like to check my open source project home page
http://rstplib.sourceforge.net/ ?
Let me know your opinion about it and about options to test it by your
group, please.

Thank you for the cooperation, Alex
---------------------
Open Source RSTP  http://sourceforge.net/projects/rstplib/
Optical Access Ltd. http://www.opticalaccess.com

[Rstplib-users] RE: inferior message and disabling Root Port questions

[Benny T. <be...@fo...>]

Alex ,
here is the info you requested:

Dynamic changes  To be Supported
------------------------------------------------
a) changes in RSTP bridge Priority { bridge_id = bridge_prority:
Bridge_MAC_Address}
b) changes in port priority { port_id : port_pririty :port_number}

Special Processing  requirements in rcvBPdu() to Support dynamic Changes
----------------------------------------------------------------------------
--------------------------
when a port receives an Inferior BPDU (RST BPDU or Config BPDU which does
not strictly supercede the PortPriority Vector and
 neither a TCN nor a RST BPDU with TC flag set),
it should check  for only the Bridge_MAC_Address field of the received
Message (for evalutating designatedBridgeID)
and the Port_number field of the received message  ( for evalutating
designatedPortID) when
 executing the rcvBpdu() routine. If the Bridge_MAC_address  and the
port_number are the same  as the values
held in the port Priority Vector , the rcvBpdu routine must return
SUPERIOR_DESIGNATED_MESSAGE
if the conditions below are met

i) port should be connected on a point-to-point interface and the port role
should be same as the selectedRole and
the role should NOT be a DESIGNATED_PORT and selected variable should be
TRUE and updtInfo variable should be FALSE.
ii) rcvdInfoWhile should be running (should not be in the STOPPED state)

The rationale  for the constraints (i) and (ii) above specified
----------------------------------------------------------------------
 The above conditions are specified  to detect valid dynamic changes in the
message Vector from  a *previously*
Designated Port [Annex F , Page 101 , sub Para F.2.1 and clause (e) ].

The special processing is required only for inferior messages ( config BPDU
or RST BPDU but neither  TCN , nor RST BPDU with TC flag set)

a) if point-point  is not TRUE (port is connected on a shared media) we
might still have connectivity to the bridge
whose superior  message vector  was copied to our Port Vector.

b) If  condition (a) is met and if our port Role is Designated we need not
take any special  action on this
 BPDU (rcvBpdu must OTHER_MESSAGE )since ,
the  peer port connected to this designated port will either agree with our
port role assignment by sending a
 CONFIRMED_ROOT_MESSAGE .
 if  the BPDU the peer port sends  strictly supercedes us , it means a RSTP
role computation is pending from our side
 and new role will be assigned for this port. Since the BPDU strictly
supercedes us  rcvBpdu() must
return SUPERIOR_DESIGNATED_MESSAGE.

The other case is if this port *was* connected to an ALTERNATE PORT or a
BACKUP_PORT which now
assumes a Designated Port Role and transmits a BPDU , in this case the
 BridgeMACAddress and port_number checks will not be TRUE ( since for a
Designated port  ,portVector = designatedVector)
for his port. We can return OTHER_MESSAGE in this case if the BPDU does
not strictly supercedes this port's  portVector ,
SUPERIOR_DESIGNATED_MESSAGE other wise.

c) rcvdInfoWhile running , should be there , since this port's role
assignment *was* consistent with its peer port due to the superior
message which was received on this port and was copied to the portVector.
. So this port's role should be either ROOT_PORT , ALTERNATE PORT or
BACKUP_PORT.

d) the expression (selected && !updtInfo ) should be evaluated to TRUE to
indicate that no role
computation or updation is pending on this port.Also  this port must not
have a applicable valid
 transition in the PIM to the UPDATE state (selected && updtInfo must not be
TRUE ) which
in fact leaves room for fresh handshake with the peer port.

Rationale For the suggestions
----------------------------------------
a) All the 802.1d users extensively use the dynamic changes described above
( changes in  Bridge Priority and Port Priority.)
to  cause topology change events(changes in Root Bridge and Root Port etc)
in the existing 802.1d bridges

b) RSTP 802.1w implementation aims to achieve rapid convergence without
depending on any timer expiry if  conditions for
rapid convergence are met.

c) Annex F , Page 101 , sub para F.2.1 and clause (e) Of the  International
standard states that inferior message should be accepted for valid
processing .
This should be extended to support dynamic changes in Bridge Priority and
Port Priority.

Please let me know if you need any further clarification.
Regards,
Benny
============================================================================
=========
-----Original Message-----
From: Alex Ruzin [mailto:al...@nb...]
Sent: Thursday, February 28, 2002 12:17 AM
To: 'Benny Thottakkara'; rst...@li...
Cc: std...@ie...
Subject: RE: inferior message and disabling Root Port questions


On Wednesday, February 27, 2002 11:05 PM Mr. Thottakkara wrote:
Benny> Alex:  Please refer to my  previous email . I think it has a
Benny> suggestion to
Benny> your question in
Benny> http://www.ieee802.org/1/private/email/msg00348.html:
Benny> I have tested it and it works.
Benny>
Please repeat your suggestions: there were too many
conversations in this thread and I can't find them.
 [Note, if they are related to the implementation
  only, don't post to std...@ie..., please.
  Feel free to post to rst...@li... anyway]

Thanks, Alex
---------------------
Open Source RSTP  http://rstplib.sourceforge.net
Optical Access Ltd. http://www.opticalaccess.com

[Rstplib-users] RE: pui drag and drop.

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

On Wednesday, February 27, 2002 6:24 PM Kev Ryan wrote:
Kev > is there a drag and drop function for the picoscopic user interface.
Kev > thanks
I afraid, I never heard about "picoscopic" with or without user interface.
May you support more details about it and about its relation to RSTP ?
Best wishes, Alex

[Rstplib-users] RE: inferior message and disabling Root Port questions

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

On Wednesday, February 27, 2002 11:05 PM Mr. Thottakkara wrote:
Benny> Alex:  Please refer to my  previous email . I think it has a 
Benny> suggestion to
Benny> your question in
Benny> http://www.ieee802.org/1/private/email/msg00348.html:
Benny> I have tested it and it works.
Benny> 
Please repeat your suggestions: there were too many
conversations in this thread and I can't find them.
 [Note, if they are related to the implementation
  only, don't post to std...@ie..., please.
  Feel free to post to rst...@li... anyway]

Thanks, Alex
---------------------
Open Source RSTP  http://rstplib.sourceforge.net
Optical Access Ltd. http://www.opticalaccess.com

[Rstplib-users] RE: inferior message and disabling Root Port questions

[Benny T. <be...@fo...>]

Alex ,
Thank you for the answers & Sorry to have confused you
inferior Message = OTHER_MESSAGE but not a TCN

Alex:  Please refer to my  previous email . I think it has a suggestion to
your question in
http://www.ieee802.org/1/private/email/msg00348.html:
I have tested it and it works.

Thanks
Benny


Benny Thottakkara            | Tel: (408)941-7317
Foundry Networks, Inc.    | Fax: (408)586-1900
2100 Gold St.                       | email: be...@fo...
P.O. Box 649100                  | Web: www.foundrynet.com
San Jose, CA  95164
 ---------------------------------------------------------------------------


-----Original Message-----
From: Alex Ruzin [mailto:al...@nb...]
Sent: Tuesday, February 26, 2002 11:03 PM
To: 'Benny Thottakkara'; rst...@li...
Cc: std...@ie...
Subject: RE: inferior message and disabling Root Port questions


[ First - *please* don't mail me directly.
Keep discussions to the list, where others
can both learn and offer advice.  Thanks.  ]

On Tuesday, February 26, 2002 11:07 PM Benny Thottakkara wrote:
Benny > alex,
Benny > I was Implementing the 802.1w implementation . Your Linux
Benny > implementation was extremely useful.
Benny > could you please answer a few questions. I think they are flaws in
the
Benny > standard itself.
IMHO you are right: I believe these questions relate more with standard
itself.
So, I both try to reply and forward your questions to std...@ie....

Benny > a) why do we just keep quite when we receive an inferior message ?
What do you mean under "inferior message"?  IEEE 802.1w defines
only 4 possible values of rcvdMsg (17.18.22): SuperiorDesignatedMsg,
RepeatedDesignatedMsg, ConfirmedRootMsg, or OtherMsg.

Benny > b) what do we do when we receive a inferior message from a
Benny > bridge which *was* previously the root bridge of the system?
Actually, on OtherMsg - do nothing, irrelative of Port's role, see PIM,
17.21)

Benny > c) when  the current root port on a bridge becomes disabled
Benny > do we have to set reselect to TRUE on all the remaining ports
No, PIM (17.21) in the case jumps to DISABLED state, where, among others,
it sets reselect of the Port to TRUE; as a result PRSM (17.22) updates
roles of all Ports (17.19.21)

Best regards, Alex
---------------------
Open Source RSTP  http://rstplib.sourceforge.net
Optical Access Ltd. http://www.opticalaccess.com

[Rstplib-users] pui drag and drop.

[Kev R. <ry...@tc...>]

is there a drag and drop function for the picoscopic user interface.
thanks

[Rstplib-users] Re: [Ethereal-dev] RST BPDU in Ethereal

[Tony J. <to...@je...>]

At 02:03 27/02/2002 -0800, Guy Harris wrote:

>On Wed, Feb 27, 2002 at 11:26:07AM +0200, Alex Ruzin wrote:
> > I didn't see the option to browse RST BPDU (IEEE 802.1w) with ethereal
> > http://www.ethereal.com/ (I use the version 0.9.1).
> > Attached is the patch to ethereal, it may be useful for somebody.
>
>Checked in.

Please keep your offline discussions on implementations, patches, etc.. off 
the 802.1 exploder; the latter is for discussions relevant to 802.1's 
standards development activities only.

Thank you.

Regards,
Tony

[Rstplib-users] Re: [Ethereal-dev] RST BPDU in Ethereal

[Guy H. <gh...@so...>]

On Wed, Feb 27, 2002 at 11:26:07AM +0200, Alex Ruzin wrote:
> I didn't see the option to browse RST BPDU (IEEE 802.1w) with ethereal
> http://www.ethereal.com/ (I use the version 0.9.1).
> Attached is the patch to ethereal, it may be useful for somebody.

Checked in.

Re: [Rstplib-users] Re: 802.1w question

[Imagine T. <ter...@ya...>]

Albina,

About this effect Alex asked
in
http://www.ieee802.org/1/private/email/msg00348.html
I did not see an answer :(
I hope, now anyone from gurus of 802.1 WG will answer.

Bina

--- Albina Krigma-Lee <alb...@ya...> wrote:
> G'Day
> 
> Benny seems to be right:
> I simulated his configuration with
> RSTLib (http://rstplib.sourceforge.net/)
> and saw a long delay before the stabilisation
> (see attached traces, sorry).
> 
> It may be flaw in .1w or in rstplib.
> What does the community think ?
> 
> Bina
> 
> 
>  --- Benny Thottakkara <be...@fo...> wrote:
> >
> Mick,
> > Thank you :=) for your comprehensive reply to my
> > previous email.
> > 
> > I have Two  more questions
> > I) Please refer to the attachment for the topology
> > in question:(power point
> > document)
> > 
> > In the given topology if switch1 dynamically
> changes
> > its priority from 100
> > to 1000 , the  designated Ports of switch1 will
> > start transmitting with the following message
> vector
> > { root_id = 1000:MAC_SW1,  RPC=0x0, 
> > Designated_bridge_id = 1000:MAC_SW1,
> > INDIVIDUAL_ PORT_ID}.
> > 
> > Consider the processing of these BPDUS on the
> > Previous Root ports in switch2
> > and switch3.
> > These RST BPDUs when received on swicth3 and
> switch
> > 2 will return a type
> > OTHER_MESSAGE on execution of
> > rcvBpdu() routine[Basis:  processing to be done on
> > Port Info state
> > Machine/RECEIVE state , Page 60 IEEE standard
> 802_1w
> > 2001].
> > 
> > The condition for returning
> > SUPERIOR_DESIGNATED_MESSAGE is not met since the
> > Designated Bridge_ID in the received message
> vector
> > is already changed to the new value
> > [{MessageVector->Designated_bridge_id =
> > {pri=1000: MAC_address= MAC_SW1}. ].
> >  So a comparison of the  Designated BridgeID value
> > held in the portPriority
> > Vector  and bridge_id  received
> > in the new message Vector will  return FALSE.
> > [Basis: Section 17.19.8 Page 55 of the  IEEE
> > standard 802_1w 2001].
> > . And Port Information state machine does not have
> a
> > local or global
> > transition corresponding to this case.
> > (pages  60-61 of the international standard
> > indicates that   in this case we
> > re-enter the CURRENT state to do checks for the
> > applicable transitions  to AGED state and UPDATE
> > state). None of these
> > conditions are met since updtInfo is FALSE
> > on all the bridge ports and  rcvdInfoWhile timer
> has
> > not expired.
> > 
> > So we are left with option of  rcvdInfoWhile timer
> > expiry for an applicable
> > global transition which recomputes the
> > spanning Tree vectors [on execution of
> >  RoleSelectionStateMachine() ->updtRolesBridge()
> > routine].
> > 
> > Assuming  the default value of hello time of  2
> > seconds this will take 6
> > seconds . Is this the correct behavior?
> > 
> > [ Suggestion: We could have returned 
> > SUPERIOR_DESIGNATED_MESSAGE  for this
> > inferior message
> > if we were looking for   the  same value of MAC
> > address(MAC_SW1) of the
> > Bridge_ID component
> > of the received message Vector and the value held
> in
> > the
> >
> PortPriorityVector->DesignatedBridgeID->MAC_address.
> > Everything will work okay , since the reselect =
> > TRUE on this port  will
> > force the  recomputation ]
> > 
> > II) I have been going thru the 802.1y draft 2 .
> Our
> > Company likes to have
> > representation in this committe.
> > how do we obtain membership into this committe?
> > 
> > Your reply is greatly appreciated,
> > Benny
> > 
> > Benny Thottakkara            | Tel: (408)941-7317
> > Foundry Networks, Inc.    | Fax: (408)586-1900
> > 2100 Gold St.                       | email:
> > be...@fo...
> > P.O. Box 649100                  | Web:
> > www.foundrynet.com
> > San Jose, CA  95164
> > 
> >
>
---------------------------------------------------------------------------
> >
>
----------------------------------------------------------------
> > 
> > 
> > -----Original Message-----
> > From: Mick Seaman [mailto:mic...@ie...]
> > Sent: Tuesday, February 26, 2002 2:21 PM
> > To: 'Benny Thottakkara'
> > Cc: 'Raj Jalan'; 'Ivy Hsu'; std...@ie...
> > Subject: RE:
> > 
> > 
> > 
> > Benny,
> > You are asking this question in the right place,
> and
> > it is a good question.
> > 
> > In my original paper I identified the opportunity
> to
> > transition a Designated
> > port to forwarding rapidly even if it was attached
> > to a lan/point-to-point
> > link where the other Bridge's port was an
> Alternate
> > port.
> > 
> > When we got to the detail in the standards I found
> > that the correctness
> > proof I was most comfortable with did not support
> > this behavior, and we
> > settle for the situation you describe below where
> > the timer expiry (twice)
> > is required for such a Designated Port to
> transition
> > to forwarding. This is
> > not such a problem, since if the Alternate Port
> > becomes a Root Port, the
> > necessary exchanges will be kicked off to rapidly
> > transition the Designated
> > Port to forwarding. What is more in most cases of
> > structured networks the
> > network will have settled down for a while after
> its
> > initial power up, and
> > failures will be recovered from one by one, with
> > sufficient interval for the
> > Designated Ports you describe to become
> forwarding.
> > 
> > I now understand how to perform the necessary
> proof
> > that would allow the
> > Alternate Port to send an Agreement (and the
> > conditions under which it can
> > do so), but I strongly suggest that you stick to
> the
> > letter of the standard
> > in your implementation. There is always enough
> fine
> > detail, and surprises
> > and unintended consequences in detail, that it is
> > not worth trying to one
> > plus the standard until any improvement has
> received
> > extensive peer review.
> > Any suggestion for improvement that I would come
> up
> > with in future would
> > also be based on improvements currently being
> > considered as maintenance
> > items.
> > 
> > Mick
> > 
> > 
> > 
> > -----Original Message-----
> > From: Benny Thottakkara
> > [mailto:be...@fo...]
> > Sent: Tuesday, February 26, 2002 1:30 PM
> 
=== message truncated ===> 12:05:18 B28169 > show port
>  BridgeId: 0064-00096e000001  RootId:
> 0064-00096e000001
>      p01 8001 Fwd  0064-00096e000001
> 0064-00096e000001 8001 D
>      p02 8002 Fwd  0064-00096e000001
> 0064-00096e000001 8002 D
>      p03 8003 Fwd  0064-00096e000001
> 0064-00096e000001 8003 D
>      p04 8004 Fwd  0064-00096e000001
> 0064-00096e000001 8004 D
> 12:05:51 B28169 > bridge priority 1000
> Changed rstp bridge priority
> 12:06:20 B28169 > 12:06:24:
> brige B28169 new root port: p01
> 12:06:24:sttrans (B28169-p04):
> FORWARDING=>DISCARDING
> 12:06:24:sttrans (B28169-p03):
> FORWARDING=>DISCARDING
> 12:06:24:sttrans (B28169-p02):
> FORWARDING=>DISCARDING
> 12:06:25:
> brige B28169 new root port: p02
> 12:06:25:sttrans (B28169-p01):
> FORWARDING=>DISCARDING
> 12:06:25:sttrans (B28169-p02): DISCARDING=>LEARNING
> 12:06:25:sttrans (B28169-p02): LEARNING=>FORWARDING
> 12:06:27:sttrans (B28169-p03): DISCARDING=>LEARNING
> 12:06:27:sttrans (B28169-p03): LEARNING=>FORWARDING
> 12:06:27:sttrans (B28169-p01): DISCARDING=>LEARNING
> 12:06:27:sttrans (B28169-p01): LEARNING=>FORWARDING
> 12:06:27:sttrans (B28169-p04): DISCARDING=>LEARNING
> 12:06:27:sttrans (B28169-p04): LEARNING=>FORWARDING
> 12:06:34:sttrans (B28169-p04):
> FORWARDING=>DISCARDING
> 12:06:35:
> brige B28169 new root port: p04
> 12:06:35:sttrans (B28169-p02):
> FORWARDING=>DISCARDING
> 12:06:35:sttrans (B28169-p04): DISCARDING=>LEARNING
> 12:06:35:sttrans (B28169-p04): LEARNING=>FORWARDING
> 12:06:35:
> brige B28169 became root
> 12:06:36:
> brige B28169 new root port: p02
> 12:06:36:sttrans (B28169-p04):
> FORWARDING=>DISCARDING
> 12:06:36:sttrans (B28169-p02): DISCARDING=>LEARNING
> 12:06:36:sttrans (B28169-p02): LEARNING=>FORWARDING
> 12:06:36:
> brige B28169 new root port: p01
> 12:06:36:sttrans (B28169-p02):
> FORWARDING=>DISCARDING
> 12:06:36:sttrans (B28169-p03):
> FORWARDING=>DISCARDING
> 12:06:36:sttrans (B28169-p04): DISCARDING=>LEARNING
> 12:06:36:sttrans (B28169-p04): LEARNING=>FORWARDING
> 12:06:38:sttrans (B28169-p03): DISCARDING=>LEARNING
> 12:06:38:sttrans (B28169-p03): LEARNING=>FORWARDING
> 
> 12:06:50 B28169 > 
> 12:06:50 B28169 > 
> 12:06:51 B28169 > show port
>  BridgeId: 03E8-00096e000001  RootId:
> 00C8-000a6e000001
>      p01 8001 Fwd  00C8-000a6e000001
> 00C8-000a6e000001 8001 R
>      p02 8002 Blk  00C8-000a6e000001
> 00C8-000a6e000001 8002 A
>      p03 8003 Fwd  00C8-000a6e000001
> 03E8-00096e000001 8003 D
>      p04 8004 Fwd  00C8-000a6e000001
> 03E8-00096e000001 8004 D
> 12:06:55 B28169 > shutdown from manager :(
> 
> > 12:05:23 B28170 > 
> 12:05:23 B28170 > show port
>  BridgeId: 00C8-000a6e000001  RootId:
> 0064-00096e000001
>      p01 8001 Fwd  0064-00096e000001
> 0064-00096e000001 8001 R
>      p02 8002 Blk  0064-00096e000001
> 0064-00096e000001 8002 A
>      p03 8003 Fwd  0064-00096e000001
> 00C8-000a6e000001 8003 D
>      p04 8004 Fwd  0064-00096e000001
> 00C8-000a6e000001 8004 D
> 12:05:57 B28170 > 12:06:24:
> brige B28170 new root port: p02
> 12:06:24:sttrans (B28170-p01):
> FORWARDING=>DISCARDING
> 12:06:24:sttrans (B28170-p02): DISCARDING=>LEARNING
> 12:06:24:sttrans (B28170-p02): LEARNING=>FORWARDING
> 12:06:24:sttrans (B28170-p01): DISCARDING=>LEARNING
> 12:06:24:sttrans (B28170-p01): LEARNING=>FORWARDING
> 12:06:25:
> brige B28170 became root
> 12:06:25:
> brige B28170 new root port: p04
> 12:06:25:sttrans (B28170-p03):
> FORWARDING=>DISCARDING
> 12:06:25:sttrans (B28170-p02):
> FORWARDING=>DISCARDING
> 12:06:25:sttrans (B28170-p01):
> FORWARDING=>DISCARDING
> 12:06:25:
> brige B28170 became root
> 12:06:25:sttrans (B28170-p03): DISCARDING=>LEARNING
> 12:06:25:sttrans (B28170-p03): LEARNING=>FORWARDING
> 12:06:25:sttrans (B28170-p01): DISCARDING=>LEARNING
> 12:06:25:sttrans (B28170-p01): LEARNING=>FORWARDING
> 12:06:25:
> brige B28170 new root port: p01
> 12:06:25:sttrans (B28170-p02): DISCARDING=>LEARNING
> 12:06:25:sttrans (B28170-p02): LEARNING=>FORWARDING
> 12:06:25:sttrans (B28170-p04):
> FORWARDING=>DISCARDING
> 12:06:25:sttrans (B28170-p03):
> FORWARDING=>DISCARDING
> 12:06:35:
> brige B28170 became root
> 12:06:35:
> brige B28170 new root port: p02
> 12:06:35:sttrans (B28170-p01):
> FORWARDING=>DISCARDING
> 12:06:35:
> brige B28170 became root
> 12:06:37:sttrans (B28170-p01): DISCARDING=>LEARNING
> 12:06:37:sttrans (B28170-p01): LEARNING=>FORWARDING
> 12:06:42:sttrans (B28170-p04): DISCARDING=>LEARNING
> 12:06:42:sttrans (B28170-p03): DISCARDING=>LEARNING
> 12:06:57:sttrans (B28170-p04): LEARNING=>FORWARDING
> 12:06:57:sttrans (B28170-p03): LEARNING=>FORWARDING
> 
> 12:06:58 B28170 > 
> 12:06:58 B28170 > show port
>  BridgeId: 00C8-000a6e000001  RootId:
> 00C8-000a6e000001
>      p01 8001 Fwd  00C8-000a6e000001
> 00C8-000a6e000001 8001 D
>      p02 8002 Fwd  00C8-000a6e000001
> 00C8-000a6e000001 8002 D
>      p03 8003 Fwd  00C8-000a6e000001
> 00C8-000a6e000001 8003 D
>      p04 8004 Fwd  00C8-000a6e000001
> 00C8-000a6e000001 8004 D
> 12:07:08 B28170 > shutdown from manager :(
> 
> > 12:05:26 B28171 > 
> 12:05:26 B28171 > show port
>  BridgeId: 012C-000b6e000001  RootId:
> 0064-00096e000001
>      p01 8001 Fwd  0064-00096e000001
> 0064-00096e000001 8003 R
>      p02 8002 Blk  0064-00096e000001
> 0064-00096e000001 8004 A
>      p03 8003 Blk  0064-00096e000001
> 00C8-000a6e000001 8003 A
>      p04 8004 Blk  0064-00096e000001
> 00C8-000a6e000001 8004 A
> 12:06:02 B28171 > 12:06:25:
> brige B28171 new root port: p03
> 12:06:25:sttrans (B28171-p01):
> FORWARDING=>DISCARDING
> 12:06:25:sttrans (B28171-p03): DISCARDING=>LEARNING
> 12:06:25:sttrans (B28171-p03): LEARNING=>FORWARDING
> 12:06:25:sttrans (B28171-p04): DISCARDING=>LEARNING
> 12:06:25:sttrans (B28171-p04): LEARNING=>FORWARDING
> 12:06:25:
> brige B28171 new root port: p02
> 12:06:25:sttrans (B28171-p03):
> FORWARDING=>DISCARDING
> 12:06:25:sttrans (B28171-p04):
> FORWARDING=>DISCARDING
> 12:06:25:sttrans (B28171-p02): DISCARDING=>LEARNING
> 12:06:25:sttrans (B28171-p02): LEARNING=>FORWARDING
> 12:06:25:
> brige B28171 new root port: p01
> 12:06:25:sttrans (B28171-p02):
> FORWARDING=>DISCARDING
> 12:06:25:sttrans (B28171-p01): DISCARDING=>LEARNING
> 12:06:25:sttrans (B28171-p01): LEARNING=>FORWARDING
> 12:06:27:
> brige B28171 new root port: p02
> 12:06:27:sttrans (B28171-p01):
> FORWARDING=>DISCARDING
> 12:06:27:sttrans (B28171-p02): DISCARDING=>LEARNING
> 12:06:27:sttrans (B28171-p02): LEARNING=>FORWARDING
> 12:06:27:
> brige B28171 new root port: p01
> 12:06:27:sttrans (B28171-p02):
> FORWARDING=>DISCARDING
> 12:06:27:sttrans (B28171-p01): DISCARDING=>LEARNING
> 12:06:27:sttrans (B28171-p01): LEARNING=>FORWARDING
> 12:06:35:
> brige B28171 became root
> 12:06:35:sttrans (B28171-p02): DISCARDING=>LEARNING
> 12:06:35:sttrans (B28171-p02): LEARNING=>FORWARDING
> 12:06:36:
> brige B28171 new root port: p04
> 12:06:36:sttrans (B28171-p02):
> FORWARDING=>DISCARDING
> 12:06:36:sttrans (B28171-p01):
> FORWARDING=>DISCARDING
> 12:06:36:sttrans (B28171-p04): DISCARDING=>LEARNING
> 12:06:36:sttrans (B28171-p04): LEARNING=>FORWARDING
> 12:06:36:
> brige B28171 new root port: p03
> 12:06:36:sttrans (B28171-p04):
> FORWARDING=>DISCARDING
> 12:06:36:sttrans (B28171-p03): DISCARDING=>LEARNING
> 12:06:36:sttrans (B28171-p03): LEARNING=>FORWARDING
> 12:06:36:
> brige B28171 new root port: p02
> 12:06:36:sttrans (B28171-p03):
> FORWARDING=>DISCARDING
> 12:06:36:sttrans (B28171-p02): DISCARDING=>LEARNING
> 12:06:36:sttrans (B28171-p02): LEARNING=>FORWARDING
> 12:06:37:
> brige B28171 new root port: p01
> 12:06:37:sttrans (B28171-p02):
> FORWARDING=>DISCARDING
> 12:06:37:sttrans (B28171-p01): DISCARDING=>LEARNING
> 12:06:37:sttrans (B28171-p01): LEARNING=>FORWARDING
> 
> 12:07:13 B28171 > 
> 12:07:13 B28171 > show port
>  BridgeId: 012C-000b6e000001  RootId:
> 00C8-000a6e000001
>      p01 8001 Fwd  00C8-000a6e000001
> 03E8-00096e000001 8003 R
>      p02 8002 Blk  00C8-000a6e000001
> 03E8-00096e000001 8004 A
>      p03 8003 Blk  00C8-000a6e000001
> 00C8-000a6e000001 8003 A
>      p04 8004 Blk  00C8-000a6e000001
> 00C8-000a6e000001 8004 A
> 12:07:16 B28171 > shutdown from manager :(
> 
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com

[Rstplib-users] Re: 802.1w question

[<alb...@ya...>]

G'Day

Benny seems to be right:
I simulated his configuration with
RSTLib (http://rstplib.sourceforge.net/)
and saw a long delay before the stabilisation
(see attached traces, sorry).

It may be flaw in .1w or in rstplib.
What does the community think ?

Bina


 --- Benny Thottakkara <be...@fo...> wrote: >
Mick,
> Thank you :=) for your comprehensive reply to my
> previous email.
> 
> I have Two  more questions
> I) Please refer to the attachment for the topology
> in question:(power point
> document)
> 
> In the given topology if switch1 dynamically changes
> its priority from 100
> to 1000 , the  designated Ports of switch1 will
> start transmitting with the following message vector
> { root_id = 1000:MAC_SW1,  RPC=0x0, 
> Designated_bridge_id = 1000:MAC_SW1,
> INDIVIDUAL_ PORT_ID}.
> 
> Consider the processing of these BPDUS on the
> Previous Root ports in switch2
> and switch3.
> These RST BPDUs when received on swicth3 and switch
> 2 will return a type
> OTHER_MESSAGE on execution of
> rcvBpdu() routine[Basis:  processing to be done on
> Port Info state
> Machine/RECEIVE state , Page 60 IEEE standard 802_1w
> 2001].
> 
> The condition for returning
> SUPERIOR_DESIGNATED_MESSAGE is not met since the
> Designated Bridge_ID in the received message vector
> is already changed to the new value
> [{MessageVector->Designated_bridge_id =
> {pri=1000: MAC_address= MAC_SW1}. ].
>  So a comparison of the  Designated BridgeID value
> held in the portPriority
> Vector  and bridge_id  received
> in the new message Vector will  return FALSE.
> [Basis: Section 17.19.8 Page 55 of the  IEEE
> standard 802_1w 2001].
> . And Port Information state machine does not have a
> local or global
> transition corresponding to this case.
> (pages  60-61 of the international standard
> indicates that   in this case we
> re-enter the CURRENT state to do checks for the
> applicable transitions  to AGED state and UPDATE
> state). None of these
> conditions are met since updtInfo is FALSE
> on all the bridge ports and  rcvdInfoWhile timer has
> not expired.
> 
> So we are left with option of  rcvdInfoWhile timer
> expiry for an applicable
> global transition which recomputes the
> spanning Tree vectors [on execution of
>  RoleSelectionStateMachine() ->updtRolesBridge()
> routine].
> 
> Assuming  the default value of hello time of  2
> seconds this will take 6
> seconds . Is this the correct behavior?
> 
> [ Suggestion: We could have returned 
> SUPERIOR_DESIGNATED_MESSAGE  for this
> inferior message
> if we were looking for   the  same value of MAC
> address(MAC_SW1) of the
> Bridge_ID component
> of the received message Vector and the value held in
> the
> PortPriorityVector->DesignatedBridgeID->MAC_address.
> Everything will work okay , since the reselect =
> TRUE on this port  will
> force the  recomputation ]
> 
> II) I have been going thru the 802.1y draft 2 . Our
> Company likes to have
> representation in this committe.
> how do we obtain membership into this committe?
> 
> Your reply is greatly appreciated,
> Benny
> 
> Benny Thottakkara            | Tel: (408)941-7317
> Foundry Networks, Inc.    | Fax: (408)586-1900
> 2100 Gold St.                       | email:
> be...@fo...
> P.O. Box 649100                  | Web:
> www.foundrynet.com
> San Jose, CA  95164
> 
>
---------------------------------------------------------------------------
>
----------------------------------------------------------------
> 
> 
> -----Original Message-----
> From: Mick Seaman [mailto:mic...@ie...]
> Sent: Tuesday, February 26, 2002 2:21 PM
> To: 'Benny Thottakkara'
> Cc: 'Raj Jalan'; 'Ivy Hsu'; std...@ie...
> Subject: RE:
> 
> 
> 
> Benny,
> You are asking this question in the right place, and
> it is a good question.
> 
> In my original paper I identified the opportunity to
> transition a Designated
> port to forwarding rapidly even if it was attached
> to a lan/point-to-point
> link where the other Bridge's port was an Alternate
> port.
> 
> When we got to the detail in the standards I found
> that the correctness
> proof I was most comfortable with did not support
> this behavior, and we
> settle for the situation you describe below where
> the timer expiry (twice)
> is required for such a Designated Port to transition
> to forwarding. This is
> not such a problem, since if the Alternate Port
> becomes a Root Port, the
> necessary exchanges will be kicked off to rapidly
> transition the Designated
> Port to forwarding. What is more in most cases of
> structured networks the
> network will have settled down for a while after its
> initial power up, and
> failures will be recovered from one by one, with
> sufficient interval for the
> Designated Ports you describe to become forwarding.
> 
> I now understand how to perform the necessary proof
> that would allow the
> Alternate Port to send an Agreement (and the
> conditions under which it can
> do so), but I strongly suggest that you stick to the
> letter of the standard
> in your implementation. There is always enough fine
> detail, and surprises
> and unintended consequences in detail, that it is
> not worth trying to one
> plus the standard until any improvement has received
> extensive peer review.
> Any suggestion for improvement that I would come up
> with in future would
> also be based on improvements currently being
> considered as maintenance
> items.
> 
> Mick
> 
> 
> 
> -----Original Message-----
> From: Benny Thottakkara
> [mailto:be...@fo...]
> Sent: Tuesday, February 26, 2002 1:30 PM
> To: mic...@ie...
> Cc: Raj Jalan; Ivy Hsu
> Subject:
> 
> 
> Mick,
> I have question on 802.1w implementation
> 
> Basis  "Loop cutting in the Original and Rapid
> Spanning Tree by Mick
> Seaman"
> under section Loop cutting in RSTP , you have
> mentioned about an alternate
> port sending a handshake
> to its designated Port so that the Designated port
> knows that the peer-port
> agrees with the current role assignment
> and goes to forwarding state.
> But in the international standard, the Transmit
> state machine does not let
> any transmissions from
> form an ALTERNATE_PORT or BACK_UP_PORT.
> so my question is if we strictly implement 802.1w ,
> does the designated port which is  attached to
> either ALTERNATE_PORT or
> BACK_UP_PORT goes to Forwarding state
> only after two instances of the fdWhile timer
> expiry?
> 
> If this is not the right forum to rise these
> questions please direct me to
> the right place.
> 
> Thank you in advance,
> Benny
> 
> Benny Thottakkara            | Tel: (408)941-7317
> Foundry Networks, Inc.    | Fax: (408)586-1900
> 2100 Gold St.                       | email:
> be...@fo...
> 
=== message truncated ===

> ATTACHMENT part 2 application/vnd.ms-powerpoint
name=RSTP question.ppt
 

http://movies.yahoo.com.au - Yahoo! Movies
- Vote for your nominees in our online Oscars pool.

[Rstplib-users] RST BPDU in Ethereal

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

Hi All,

I didn't see the option to browse RST BPDU (IEEE 802.1w) with ethereal
http://www.ethereal.com/ (I use the version 0.9.1).
Attached is the patch to ethereal, it may be useful for somebody.

NOTE: I don't show here "Version 1 Length" 

Best regards, Alex
---------------------
Open Source RSTP  http://rstplib.sourceforge.net
Optical Access Ltd. http://www.opticalaccess.com

Re: [Rstplib-users] RE: inferior message and disabling Root Port questions

[Imagine T. <ter...@ya...>]

Alex,

It seems to me, you don't understand: Benny writes,
that he finded flow in your source code. i.e.
your implementation doesn't correspond
to standard itself.

Benny, [if I am right] please refer me to the exact
place[s] in
in the "rstplib", where you have a doubt.

Regards, Imagine

--- Alex Ruzin <al...@nb...> wrote:
> On Tuesday, February 26, 2002 11:07 PM Benny
> Thottakkara wrote:
> Benny > alex,
> Benny > I was Implementing the 802.1w implementation
> . Your Linux
> Benny > implementation was extremely useful.
> Benny > could you please answer a few questions. I
> think they are flaws in the
> Benny > standard itself.
> IMHO you are right: I believe these questions relate
> more with standard
> itself.
> So, I both try to reply and forward your questions
> to std...@ie....
> 
> Benny > a) why do we just keep quite when we receive
> an inferior message ?
> What do you mean under "inferior message"?  IEEE
> 802.1w defines
> only 4 possible values of rcvdMsg (17.18.22):
> SuperiorDesignatedMsg,
> RepeatedDesignatedMsg, ConfirmedRootMsg, or
> OtherMsg.
> 
> Benny > b) what do we do when we receive a inferior
> message from a
> Benny > bridge which *was* previously the root
> bridge of the system?
> Actually, on OtherMsg - do nothing, irrelative of
> Port's role, see PIM,
> 17.21)
> 
> Benny > c) when  the current root port on a bridge
> becomes disabled
> Benny > do we have to set reselect to TRUE on all
> the remaining ports
> No, PIM (17.21) in the case jumps to DISABLED state,
> where, among others,
> it sets reselect of the Port to TRUE; as a result
> PRSM (17.22) updates
> roles of all Ports (17.19.21)
> 
> Best regards, Alex
> ---------------------
> Open Source RSTP  http://rstplib.sourceforge.net
> Optical Access Ltd. http://www.opticalaccess.com
> 
> 
> 
> _______________________________________________
> Rstplib-users mailing list
> Rst...@li...
>
https://lists.sourceforge.net/lists/listinfo/rstplib-users


__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com

[Rstplib-users] RE: inferior message and disabling Root Port questions

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

[ First - *please* don't mail me directly.
Keep discussions to the list, where others
can both learn and offer advice.  Thanks.  ]

On Tuesday, February 26, 2002 11:07 PM Benny Thottakkara wrote:
Benny > alex,
Benny > I was Implementing the 802.1w implementation . Your Linux
Benny > implementation was extremely useful.
Benny > could you please answer a few questions. I think they are flaws in
the
Benny > standard itself.
IMHO you are right: I believe these questions relate more with standard
itself.
So, I both try to reply and forward your questions to std...@ie....

Benny > a) why do we just keep quite when we receive an inferior message ?
What do you mean under "inferior message"?  IEEE 802.1w defines
only 4 possible values of rcvdMsg (17.18.22): SuperiorDesignatedMsg,
RepeatedDesignatedMsg, ConfirmedRootMsg, or OtherMsg.

Benny > b) what do we do when we receive a inferior message from a
Benny > bridge which *was* previously the root bridge of the system?
Actually, on OtherMsg - do nothing, irrelative of Port's role, see PIM,
17.21)

Benny > c) when  the current root port on a bridge becomes disabled
Benny > do we have to set reselect to TRUE on all the remaining ports
No, PIM (17.21) in the case jumps to DISABLED state, where, among others,
it sets reselect of the Port to TRUE; as a result PRSM (17.22) updates
roles of all Ports (17.19.21)

Best regards, Alex
---------------------
Open Source RSTP  http://rstplib.sourceforge.net
Optical Access Ltd. http://www.opticalaccess.com

RE: [Rstplib-users] how to subscribe to this list?

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

On Wednesday, February 20, 2002 12:18 AM Ken Lin asked:

Ken> Would someone please let me know how to subscribe onto this list?

Did you see the new Home Page on http://rstplib.sourceforge.net/ ?
If you only want to subscribe onto this list, go directly to
http://lists.sourceforge.net/lists/listinfo/rstplib-users

Best regards, Alex
---------------------
Open Source RSTP  https://sourceforge.net/projects/rstplib/
Optical Access Ltd. http://www.opticalaccess.com
 

[Rstplib-users] how to subscribe to this list?

[Ken L. <kl...@re...>]

Hi,

Would someone please let me know how to subscribe onto this list?

Thanks

Ken

[Rstplib-users] Announcement: RSTPIB Project Home Page

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

Hi All,
 I am happy to announce, that first edition of
the Project Home Page has been created on
http://rstplib.sourceforge.net/

 I want to thank all of you for your questions/remarks/feedbacks.
 
 Best regards, Alex
===============================
Open Source RSTP  https://sourceforge.net/projects/rstplib/
Optical Access Ltd. http://www.opticalaccess.com

[Rstplib-users] Re: Q: STP/RSTP solution ?

[Tony J. <to...@je...>]

At 08:29 13/02/2002 -0800, Ali Chanaui wrote:

>I see.
> >From other side, why don't you want to use
>RSTP implementation from sourceforge.net
>as a procedural model of the standard ?

1. The standard is already published, and already contains a specification 
of the state machines and procedures.
2. The sourceforge.net implementation didn't exist when we were developing 
the standard, so the question didn't arise before today.
3. 802.1, like the other working groups in IEEE 802, consists of a group of 
volunteers, who mostly do standards development as well as their day jobs. 
Questions of the form "Why don't you do X" aimed at such groups of 
volunteers tend to get ignored unless (a) there are existing members of the 
working group that consider it a worthwhile thing to do and also want to 
progress the work, or (b) the question is accompanied by warm bodies that 
are willing to take part in the working group's activities and are willing 
and able to progress the work.

Regards,
Tony


>Ali
>
>--- Tony Jeffree <to...@je...> wrote:
> > At 23:00 12/02/2002 -0800, Ali Chanaui wrote:
> >
> > >Hi All,
> > >I have found the RSTP home page on
> > >http://rstplib.sourceforge.net/
> > >I would like to ask the 802.1 WG
> > >relation to this page.
> >
> > There is no relation between 802.1 and this page.
> >
> >
> > >Did anyone of the Committee check it
> > >and its compliance with IEEE 802.1w ?
> >
> > No.
> >
> >
> > >Another question: is Committee going to
> > >make an examination, analysis, interpretation
> > >and review and of different alternate
> > >solutions? I mean solutions like, for example:
> > >- Cisco's Spanning-Tree Protocol's
> > >Backbone Fast Feature
> > >on http://www.cisco.com/warp/public/473/18.html#3
> > >- Cisco's Spanning Tree Protocol Loop Guard
> > >and BPDU Skew Detection Enhancements
> > >on http://www.cisco.com/warp/public/473/84.html
> > >- STAR Bridge Protocol on
> > >http://starbridge.sourceforge.net/
> > >- a set of RING solutions,
> > >etc.
> >
> > We have no current intentions to do any such
> > analysis. Generally, 802.1 is
> > not in the business of analyzing proprietary
> > solutions, unless they are
> > brought into the committee as part of a proposal for
> > developing a
> > particular standard.
> >
> > Regards,
> > Tony
> >
> >
>
>
>__________________________________________________
>Do You Yahoo!?
>Send FREE Valentine eCards with Yahoo! Greetings!
>http://greetings.yahoo.com

[Rstplib-users] Re: Q: STP/RSTP solution ?

[Ali C. <ali...@ya...>]

I see.
From other side, why don't you want to use
RSTP implementation from sourceforge.net
as a procedural model of the standard ?

Ali

--- Tony Jeffree <to...@je...> wrote:
> At 23:00 12/02/2002 -0800, Ali Chanaui wrote:
> 
> >Hi All,
> >I have found the RSTP home page on
> >http://rstplib.sourceforge.net/
> >I would like to ask the 802.1 WG
> >relation to this page.
> 
> There is no relation between 802.1 and this page.
> 
> 
> >Did anyone of the Committee check it
> >and its compliance with IEEE 802.1w ?
> 
> No.
> 
> 
> >Another question: is Committee going to
> >make an examination, analysis, interpretation
> >and review and of different alternate
> >solutions? I mean solutions like, for example:
> >- Cisco's Spanning-Tree Protocol's
> >Backbone Fast Feature
> >on http://www.cisco.com/warp/public/473/18.html#3
> >- Cisco's Spanning Tree Protocol Loop Guard
> >and BPDU Skew Detection Enhancements
> >on http://www.cisco.com/warp/public/473/84.html
> >- STAR Bridge Protocol on
> >http://starbridge.sourceforge.net/
> >- a set of RING solutions,
> >etc.
> 
> We have no current intentions to do any such
> analysis. Generally, 802.1 is 
> not in the business of analyzing proprietary
> solutions, unless they are 
> brought into the committee as part of a proposal for
> developing a 
> particular standard.
> 
> Regards,
> Tony
> 
> 


__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com

[Rstplib-users] Q: STP/RSTP solution ?

[Ali C. <ali...@ya...>]

Hi All,
I have found the RSTP home page on
http://rstplib.sourceforge.net/
I would like to ask the 802.1 WG
relation to this page.

Did anyone of the Committee check it
and its compliance with IEEE 802.1w ?

Another question: is Committee going to
make an examination, analysis, interpretation
and review and of different alternate
solutions? I mean solutions like, for example:
- Cisco's Spanning-Tree Protocol's
Backbone Fast Feature
on http://www.cisco.com/warp/public/473/18.html#3
- Cisco's Spanning Tree Protocol Loop Guard
and BPDU Skew Detection Enhancements
on http://www.cisco.com/warp/public/473/84.html
- STAR Bridge Protocol on
http://starbridge.sourceforge.net/
- a set of RING solutions,
etc.

Thanks in advance, Ali


__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com

[Rstplib-users] Re: RSTP & VLANs (MSTP ?)

[Tony J. <to...@je...>]

Robert -

As Alex (and others) have pointed out, this is not the appropriate place to 
se as a support forum for implementations of RSTP; its purpose is to 
support the standards development activities of 802.1.

Regards,
Tony

At 12:03 04/02/2002 +0000, Robert Petroff wrote:

>Hi Alex,
>
>In a couple of places of your RSTPLib I see
>allusions on VLANs and 'tags' (in data
>structure 'stpm', comments, etc.).
>What do you mean ?
>Does your library support MSTP (.1s) ?
>
>Thanks, Robert