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

[Rstplib-users] Q: "Bridge Functions Consortium Test Suite"?

[<tho...@ya...>]

[Sorry of a possible offtopic].

Dear Mr.Goubert,

Let me ask you about "Test RSTP.6.4 - The INACTIVE
State" from
ftp://ftp.iol.unh.edu/pub/bfc/testsuites/rstp/all-rstp.pdf
?
As I understand, the port on DUT, connected to
Station2 must here become Alternate, and the port,
connected to Station3 - Backup. But it looks like 
your description of "Procedure" is unsufficient in
step 1.

I will appreciate your clarifications.

Thom
 





http://www.sold.com.au - SOLD.com.au
- Find yourself a bargain!

[Rstplib-users] FW: RSTP Ring Size ?

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

-----Original Message-----
From: own...@ma...
[mailto:own...@ma...]On Behalf Of Shyam Kaluve
Sent: Thursday, June 27, 2002 4:29 AM
To: std...@ie...
Subject: RE: RSTP Ring Size ?




Catching up on my todo list :)

Mick said in some earlier thread that "The assumption in .1w is
that legacy STP bridges may always be present so Annex B always
applies." (http://www.ieee802.org/1/private/email/msg00425.html)

I agree, but Annex B was only a recommendation but not a requirement
for adherence. IMHO the protocol specification itself should not
include a limiting mechanism (message age increment by greater of 1
or 1/16th of MaxAge) when any such limiting can be purely achieved
by configuration.

I would propose to treat message age purely as a hop count and
increment by one irrespective of the value of MaxAge.

Tony, can we draft this into 802.1y please ?

Thanks.
-shyam


> To: "Les Bell" <Les...@eu...>, "Robert Petroff"
<rob...@ya...>
> Subject: RE: RSTP Ring Size ?
> From: "Liwei Yuan" <Liw...@wo...>
> Date: Mon, 4 Feb 2002 09:11:29 -0800
> Cc: <std...@ie...>
>
> Les,
>
> You did explain things well, but I gauss that you didn't take any possible
> link outage into account. For example, the 45 bridges ring is only
> theoretically possible.  Because if in worst case, the root bridge lost
one
> of its links, then the total age will much more than 23, it will never
> converge since the bpdu aged out at middle of the broken ring !!!
>
> So as a workable ring, the maximum bridges allowed is about 21, unless you
> either assume a perfect ring (why do you need the spanning tree for then?)
> or change the standard on bpdu age calculation.
>
> Liwei Yuan
>
> -----Original Message-----
> From: Les Bell [mailto:Les...@eu...]
> Sent: Monday, February 04, 2002 7:16 AM
> To: Robert Petroff
> Cc: std...@ie...; rst...@li...
> Subject: Re: RSTP Ring Size ?
<snip>
Full text ... http://www.ieee802.org/1/private/email/msg00500.html

[Rstplib-users] RE: RSTP tests in *Bridge Functions Consortium*? Former RE: RST BPDU in Ethereal

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

Gerard,

You are right: in English my last name may be spelled both like
Ruzin and like Rozin. You may call me Alex :)

I will wait impatiently for your reply.

I very like your approach to testing. We usually build a setup with
couple of bridges, load the setup with some traffic ("ping",
unicats/multicats/broadcasts/unknowns)  and check the behavior:
port states changes and conversion time.

We started to use your tests not long time ago and have just found&fixed a
couple of bugs.

We had a problem with configurable BPDU generator. I inserted some
additional feature specially for it:
an RSTP instance may be set in *test* mode, where a port may be
configured for transmit any BPDUs with any rate. I am going to
submit this feature into rstplib. Nevertheless the complicated tests
like "4.2 Part C", "7.1", "8.6" & "8.7" we cannot make :(

I'd like to ask you to "reply all* so, that your responses will appear into
rstplib
mailing list - I believe that all rstplib users are interested in the
discussion.

Thank you for the cooperation & best regards, Alex

On Tuesday, June 18, 2002 4:57 PM Gerard Goubert wrote:

>
>
> Mr. Ruzin, (or is it Rozin? It appears to spelled differently on
> different accounts you use??)
>
> I am formulating a reply to your questions, I am very busy
> over the next
> few days so it may take a while but I (we) are working on
> answering all
> your questions. Please feel free to post our responses to the
> appropriate groups.
> We are always looking for people to find errors/bugs in our suites
> and/or discuss fixes or new tests to be added. Our goal is to
> make good
> test suite(s) with as much cooperation from interested parties a
> possible.
>
> We will work on formulating answers to your questions for
> tests 2.5, 3.3
> and 8.2. As usual feel free to contact us here at the IOL at any time.
>
> -gerard
>
> Gerard Goubert
> Bridge Functions Manager
> IPv6 Test Engineer
> InterOperability Lab @ UNH
> http://www.iol.unh.edu
> gw...@io... 603.862.2060
> BFC Phone: 603.862.3525
>
>
> > -----Original Message-----
> > From: Alex Ruzin [mailto:al...@nb...]
> > Sent: Tuesday, June 18, 2002 11:41 AM
> > To: gw...@io...
> > Cc: rst...@li...
> > Subject: Q: RSTP tests in *Bridge Functions Consortium*? Former RE:
> RST
> > BPDU in Ethereal
> >
> > Dear Mr. Goubert,
> >
> > You graciously suggested me to check & use
> > your tests from http://www.iol.unh.edu/consortiums/bfc/
> > I did it and found a couple of bugs in my implementation,
> > thank you.
> >
> > May I ask some questions, related to these tests?
> >
> > -- Test RSTP.2.5  - SuperionDesignatedMsg Received: Part B,E
> >      Between old and new bridge-id there is at least one packet with
> >      DUT's own bridge-id as root (DUT considers itself as root).
> >      Is it OK or I should debug it?
> >
> > -- Test RSTP.3.3 - Alternate Port Role Selection, Part C
> >     The port, connected to Station 2 becomes Backup, not Alternate.
> Why do
> > expect him
> >     to be Alternate?
> >
> > -- Test RSTP.8.2 - tcWhile (page 83)
> >    1). Part A. It seems to me, that the ports in DUP, connected to
> both
> > Stations,
> >          has to be configured with adminEdgePort=NO; or we must
> transmit
> > BPDU from Stations:
> >          test will work, only if operEdge-NO on both ports.
> >    2). In "Observable Results" for Part A you demand exact 2 BPDUs
> with
> > Topology Change
> >          flag set. Why? It seems to me, that there must be between 1
> and
> > 2..
> >
> > Your reply will be accepted with heartfelt gratitude,
> > Thank for it in advance, Alex
> >
> > P.S. As you may see, I made CC to rstplib mailing list; let me
> > know if you would not like to post there.
> >
> > > -----Original Message-----
> > > From: Gerard Goubert [mailto:gw...@io...]
> > > Sent: Thursday, February 28, 2002 5:13 PM
> > > To: Ar...@Op...
> > > Subject: RE: RST BPDU in Ethereal
> > >
> > >
> > > 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?
> > >
> > > 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.
> > > Regards,
> > >
> > > Gerard Goubert
> > > Bridge Functions Consortium
> > > Operations Manager
> > > InterOperability Lab @ UNH
> > > gw...@io... 603.862.2060
> > > BFC Phone: 603.862.3525
> > >
> > >
> > > > -----Original Message-----
> > > > From: Alex Ruzin [mailto:al...@nb...]
> > > > Sent: Thursday, February 28, 2002 8:08 AM
> > > > To: gw...@io...
> > > > Subject: RE: RST BPDU in Ethereal
> > > >
> > > > Mr. Goubert,
> > > > The file is a regular Linux patch. You should see "man patch",
> > > > if you are working in Linux.
> > > > In the case of problem (let's say, you are working in Windows),
> > > > feel free to ask and I am ready to send you
> > > > the only changed file - packet-bpdu.c
> > > > Thank you for your interest.
> > > >
> > > > Best regards, Alex
> > > >
> > > > On Wednesday, February 27, 2002 6:11 PM Gerard Goubert wrote:
> > > > > Hello Mr. Ruzin,
> > > > >
> > > > > I see your message on the 802.1 list about the ethereal patch
> > > > > (ethereal.RSTP.diff) but how does one apply the patch...?
> > > > > It's not in a plugin format or an executable....? it is
> > > zip'd tar'd?
> > > > > I tried a few things but it is not obvious how to use
> this file.
> > > > >
> > > > > Can you please tell me what to do with this file.
> > > > > Thanks,
> > > > >
> > > > > Gerard Goubert
> > > > > Bridge Functions Consortium
> > > > > Operations Manager
> > > > > InterOperability Lab @ UNH
> > > > > gw...@io... 603.862.2060
> > > > > BFC Phone: 603.862.3525
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
>
>
>

[Rstplib-users] Q: RSTP tests in *Bridge Functions Consortium*? Former RE: RST BPDU in Ethereal

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

Dear Mr. Goubert,

You graciously suggested me to check & use
your tests from http://www.iol.unh.edu/consortiums/bfc/
I did it and found a couple of bugs in my implementation,
thank you.

May I ask some questions, related to these tests?

-- Test RSTP.2.5  - SuperionDesignatedMsg Received: Part B,E
     Between old and new bridge-id there is at least one packet with
     DUT's own bridge-id as root (DUT considers itself as root).
     Is it OK or I should debug it?

-- Test RSTP.3.3 - Alternate Port Role Selection, Part C
    The port, connected to Station 2 becomes Backup, not Alternate. Why do
expect him
    to be Alternate?

-- Test RSTP.8.2 - tcWhile (page 83)
   1). Part A. It seems to me, that the ports in DUP, connected to both
Stations,
         has to be configured with adminEdgePort=NO; or we must transmit
BPDU from Stations:
         test will work, only if operEdge-NO on both ports.
   2). In "Observable Results" for Part A you demand exact 2 BPDUs with
Topology Change
         flag set. Why? It seems to me, that there must be between 1 and 2..

Your reply will be accepted with heartfelt gratitude,
Thank for it in advance, Alex

P.S. As you may see, I made CC to rstplib mailing list; let me
know if you would not like to post there.

> -----Original Message-----
> From: Gerard Goubert [mailto:gw...@io...]
> Sent: Thursday, February 28, 2002 5:13 PM
> To: Ar...@Op...
> Subject: RE: RST BPDU in Ethereal
>
>
> 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?
>
> 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.
> Regards,
>
> Gerard Goubert
> Bridge Functions Consortium
> Operations Manager
> InterOperability Lab @ UNH
> gw...@io... 603.862.2060
> BFC Phone: 603.862.3525
>
>
> > -----Original Message-----
> > From: Alex Ruzin [mailto:al...@nb...]
> > Sent: Thursday, February 28, 2002 8:08 AM
> > To: gw...@io...
> > Subject: RE: RST BPDU in Ethereal
> >
> > Mr. Goubert,
> > The file is a regular Linux patch. You should see "man patch",
> > if you are working in Linux.
> > In the case of problem (let's say, you are working in Windows),
> > feel free to ask and I am ready to send you
> > the only changed file - packet-bpdu.c
> > Thank you for your interest.
> >
> > Best regards, Alex
> >
> > On Wednesday, February 27, 2002 6:11 PM Gerard Goubert wrote:
> > > Hello Mr. Ruzin,
> > >
> > > I see your message on the 802.1 list about the ethereal patch
> > > (ethereal.RSTP.diff) but how does one apply the patch...?
> > > It's not in a plugin format or an executable....? it is
> zip'd tar'd?
> > > I tried a few things but it is not obvious how to use this file.
> > >
> > > Can you please tell me what to do with this file.
> > > Thanks,
> > >
> > > Gerard Goubert
> > > Bridge Functions Consortium
> > > Operations Manager
> > > InterOperability Lab @ UNH
> > > gw...@io... 603.862.2060
> > > BFC Phone: 603.862.3525
> > >
> > >
> > >
> > >
> > >
>
>
>

[Rstplib-users] Re: transplantation learning entries in .1w and .1s

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

[First, please send mails in plain text, not in HTPM,
thanks]

Dislo> From your improvement code in
Dislo>updtRolesBridge() in I saw 
Dislo>  stp_out_transplant_learning(int port_index,
Dislo> int port_index). But could you pls show the
Dislo> content of this function.
Dislo> What's its primary
Dislo> usage? 

As usually accepted in RSTPLib, "stp_out" prefix of
the function names means, that it is a system
specific function and it has to be implemented
for the concrete hardware/software environment.
So, you have to implement it yourself :(

Dislo> Could you pls also briefly explain to me what
Dislo> actualy transplantation learning mean ?

It makes exact the job we are discussing in
the thread: move all fdb entried, learned on one port
to another one.

Dislo> Sorry, I am new in RSTP ....:)
Don't be shy, most of us too ....:)

Dislo> Thank you very much for your answer.
Not at all :))

Bina



http://www.sold.com.au - SOLD.com.au
- Find yourself a bargain!

RE: [Rstplib-users] # Multiple Spanning Tree Sample Code

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

Sam>     In my opinion, the FINAL Spec will attach
Sam> the sample code, ex:
Sam> SpanningTree
Sam> The standard 1.s  draft 12 seem not provide
Sam> the example currently,

It looks like 802.1 WG stoped to provide"procedural
model", instead they draw nice states machines
diagrams. We, as engeneers, have to understand &
to implement these diagrams.
Luckily Alex in his RSRPLib
(http://rstplib.sourceforge.net/)
proposes an engine to implement diagrams almost
formally. IMHO this engine may be ported to MSTP.

Sam>     Does anybody try to understand MST?
Sam>     Maybe somebody can give me some suggestion,

Subscribe to 2 relevant mailing lists (I mean
http://lists.sourceforge.net/lists/listinfo/rstplib-users
and http://eleccomm.ieee.org/sub-domo.html)
and try to ask your question - I hope it will help
you.

I hope, the site
http://www.iol.unh.edu/testsuites/bfc/
would help you too.

Best wishes, Bina


http://www.sold.com.au - SOLD.com.au
- Find yourself a bargain!

RE: [Rstplib-users] # Multiple Spanning Tree Sample Code

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

Sam>     In my opinion, the FINAL Spec will attach the sample code, ex:
Sam> SpanningTree
Sam>     The standard 1.s  draft 12 seem not provide the example currently,
I don't hope, that " FINAL Spec will attach the sample code"; 802.w didn't.

Sam>     Does anybody try to understand MST?
Sam>     Maybe somebody can give me some suggestion,
I may only suggest you to read (or even to
participate) http://www.ieee802.org/1/private/email/threads.html

Alex

Re: [Rstplib-users] # Multiple Spanning Tree Sample Code

[Sam <is...@ms...>]

Hey Alex,

    Thanks for your reply,
    In my opinion, the FINAL Spec will attach the sample code, ex:
SpanningTree
    The standard 1.s  draft 12 seem not provide the example currently,
    Should I modify the Spanning Tree code directly!?

    Does anybody try to understand MST?
    Maybe somebody can give me some suggestion,

--Sam

----- Original Message -----
From: "Alex Ruzin" <al...@nb...>
To: "'Sam'" <is...@ms...>; <rst...@li...>
Sent: Thursday, June 13, 2002 7:12 PM
Subject: RE: [Rstplib-users] # Multiple Spanning Tree Sample Code


> On Thursday, June 13, 2002 10:25 AM Sam wrote:
> Sam >     I want to port MST into our linux kernel,
> Me too (may be not in kernel, but it is unimportant)
>
> Sam >     I ever find RSTPLIB from http://rstplib.sourceforge.net/
> Sam >     It look like they will move the project in the direction
> Sam > toward 802.1s (MSTP)
> It is correct, but the game takes time :(
>
> Sam >     Is there any sample code for Multiple Spanning Tree!?
> I don't know in spite of the fact that I'd like to.
>
> Sam >     I just can not find it from 802.1s draft 12
> Get from http://www.ieee802.org/1/mirror/8021/s-drafts/d12/802-1s-d12.pdf
>
> Best regards, Alex
>
>

RE: [Rstplib-users] # Multiple Spanning Tree Sample Code

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

On Thursday, June 13, 2002 10:25 AM Sam wrote:
Sam >     I want to port MST into our linux kernel,
Me too (may be not in kernel, but it is unimportant)

Sam >     I ever find RSTPLIB from http://rstplib.sourceforge.net/
Sam >     It look like they will move the project in the direction 
Sam > toward 802.1s (MSTP)
It is correct, but the game takes time :(

Sam >     Is there any sample code for Multiple Spanning Tree!?
I don't know in spite of the fact that I'd like to.

Sam >     I just can not find it from 802.1s draft 12
Get from http://www.ieee802.org/1/mirror/8021/s-drafts/d12/802-1s-d12.pdf

Best regards, Alex

[Rstplib-users] # Multiple Spanning Tree Sample Code

[Sam <is...@ms...>]

Hi everybody,

    I want to port MST into our linux kernel,
    I ever find RSTPLIB from http://rstplib.sourceforge.net/
    It look like they will move the project in the direction toward 802.1s
(MSTP)
    Is there any sample code for Multiple Spanning Tree!?
    even from the SPEC?
    I just can not find it from 802.1s draft 12

    thanks all!

--Sam

Re: [Rstplib-users] RE: Q: *transplantation* of learning entries in .1w & .1s?

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

Yes, I do it myself. Believe me,
it was not very hard work :)

You can do it too, use as a template
the function
STP_stpm_get_port_name_by_id ()

In the case of the trouble, let me know : I may send
you all stpm.c

 --- Peter Bock <pet...@ya...> wrote: >
Albina,
> 
> It looks like correct improvement,
> but I don't see the function
> STP_stpm_get_port_index_by_id in stpm.c
> Did you add it yourself?
> 
> Regards, Peter


http://www.sold.com.au - SOLD.com.au
- Find yourself a bargain!

[Rstplib-users] RE: Q: *transplantation* of learning entries in .1w & .1s?

[<pet...@ya...>]

Albina,

It looks like correct improvement,
but I don't see the function
STP_stpm_get_port_index_by_id in stpm.c
Did you add it yourself?

Regards, Peter

 --- Albina Krigma-Lee <alb...@ya...> wrote:
> Yes, I have updated this function in the file
> rolesel.c, see the attachement (sorry) and search
> 'stp_out_transplant_learning':
> [snip]


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

[Rstplib-users] RE: Q: *transplantation* of learning entries in .1w & .1s?

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

Yes, I have updated this function in the file
rolesel.c, see the attachement (sorry) and search
'stp_out_transplant_learning':

 --- "Diamond, Paul" <di...@en...> wrote: >
Peter,
> 
> It looks like updtRolesBridge() is a good place to
> make the decision to
> transfer the addresses. All the necessary
> information is present at that
> time.
> 
> Paul
> 


http://www.sold.com.au - SOLD.com.au
- Find yourself a bargain!

[Rstplib-users] RE: Q: "Bridge Functions Consortium Test Suite"?

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

Gerard,

My sincere "thank you" for finding time to answer my
questions.

1. Unfortunately, I will not be at the
Vancouver 802.1 meeting - I don't feel myself to be a
great expert :)

2. I see, that your tests are fine, but I can't make a
most
of them because I have to have some configurable BPDU
generator.
I thought to extend rstplib
(http://rstplib.sourceforge.net/)
for this or to ask Alex to do it. Apropos, did you
check rstplib and, if yes, how did you find it?

3. In the test 2.1 you check MAC Enabled feature. How
do you
understand it (for me, IEEE 802.1t describes it not
clear enough)?
I saw a great discussion in "Bridge-MIB Area
Discussion Archive" concerning to dot1dStpPortEnabled.
I see 3 possible meanings of Port with
MACEnabled==FALSE:
  3.1. This Port is lifeless at all (in spite of the
fact that it
      has *link*); it discards all incoming frames and
doesn't
      forwards/transmits any frames.
  3.2. This Port operates as usual, except the fact,
that it
      doesn't participate in STP: it discards all
BPDUs and
      doesn't forwards/transmits any BPDUs.
  3.3. This Ports operates as Port of hub: it doesn't
learn,
      doesn't participate in STP, all incoming frames
if forwards
      to all another Ports of the Bridge.
What do think about it?

Yours sincerely, Ali 

--- Gerard Goubert <gw...@io...> wrote:
> Ali,
> 
> No actually we developed this test suite on our own,
> we did not propose
> it to the WG to be integrated, and to my knowledge
> no one has 'checked'
> the tests yet. Though we did send a copy to Les Bell
> and Tony Jeffree
> for their review, but I figured they would be too
> busy to review it. We
> have done some preliminary testing and have already
> made some changes to
> the suite. If you or anyone discovers issues with
> the tests we would
> like to fix them so please share your thoughts and
> suggestions of how to
> fix/add to the suite. We are working on revising the
> suite now as well
> as building our own custom GUI front end to run it.
> (the GUI will not be
> publicly available)
> 
> Will you be at the Vancouver 802.1 meeting?
> If you have any questions please feel free to
> contact us.
> Thanks,
> 
> Gerard Goubert
> Bridge Functions Manager
> IPv6 Test Engineer
> InterOperability Lab @ UNH
> http://www.iol.unh.edu
> gw...@io... 603.862.2060
> BFC Phone: 603.862.3525
> 
> 
> > -----Original Message-----
> > From: Ali Chanaui [mailto:ali...@ya...]
> > Sent: Tuesday, June 04, 2002 1:25 AM
> > To: Gerard Goubert
> > Subject: Re: Q: "Bridge Functions Consortium Test
> Suite"?
> >
> > Dear Mr. Goubert,
> > Did you propose your tests to 802.1 WG as an
> integral
> > part of the standard?
> > Did they checked the tests?
> >
> > Alex
> >
> > --- Gerard Goubert <gw...@io...> wrote:
> > > Hi,
> > >
> > > I helped write this document and build the tests
> > > (some of the new software is
> > > still in progress). I am away from the office
> right
> > > now, but I will be back
> > > this Friday.
> > >
> > > Let me know if you want to work together on
> this.
> > > Also I will be at the 802.1
> > > meeting in Vancouver, if you want to talk some
> more.
> > > Also please feel free to
> > > email me as well.
> > >
> > > Thanks,
> > >
> > > Gerard Goubert
> > > Bridge Functions Consortium
> > > Operations Manager
> > > InterOperability Lab @ UNH
> > > gw...@io... 603.862.2060
> > > BFC Phone: 603.862.3525
> > >
> > > Quoting Ali Chanaui <ali...@ya...>:
> > >
> > > >
> > > > Hi All,
> > > >
> > > > I've found a couple of complicated tests for
> .1w
> > > in
> > > > "Bridge Functions Consortium Test Suite"
> > > >
> (ftp://public.iol.unh.edu/pub/bfc/testsuites/rstp/
> > > > from http://www.iol.unh.edu/testsuites/bfc/)
> > > >
> > > > The questions are:
> > > > 1. How strong do these tests correspond to
> .1w?
> > > > 2. Did anyone from IEEE 801.1 WG check these
> > > tests?
> > > > 3. Why these tests are not a part (as an anex)
> of
> > > .1w?
> > > >
> > > > Best regards, Ali
> > > >
> > > >
> __________________________________________________
> > > > Do You Yahoo!?
> > > > Yahoo! - Official partner of 2002 FIFA World
> Cup
> > > > http://fifaworldcup.yahoo.com
> > > >
> > >
> > >
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! - Official partner of 2002 FIFA World Cup
> > http://fifaworldcup.yahoo.com
> 
> 
> 

> ATTACHMENT part 2 application/octet-stream
name=Gerard W Goubert (gw...@io...).vcf



__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

[Rstplib-users] Q: *transplantation* of learning entries in .1w & .1s?

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

Hi,

How useful may be an option to transplant all learning entries
from specific Port to another Port in IEEE 802.1w?

Where and how can this option be inserted in the states machines?

I see only one usage: if the Bridge (or instance in .1s)  has exactly 2
enabled Ports...

Best regards, Alex 

[Rstplib-users] Q: "Bridge Functions Consortium Test Suite"?

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

Hi All,

I've found a couple of complicated tests for .1w in
"Bridge Functions Consortium Test Suite" 
(ftp://public.iol.unh.edu/pub/bfc/testsuites/rstp/
from http://www.iol.unh.edu/testsuites/bfc/)

The questions are:
1. How strong do these tests correspond to .1w?
2. Did anyone from IEEE 801.1 WG check these tests?
3. Why these tests are not a part (as an anex) of .1w?

Best regards, Ali

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

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

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

I have another question (it seems to me,
it dedicated rather to std...@ie...).

If Port has been done forceDisable(2) or
disabled(2) - does this Port take place in Active
Topology?
I mean: does it forward frames, leran addresses?
Does it participate in GVRP, etc.?

Ali


--- Michael MacFaden <mr...@ri...> wrote:
> On Sun, May 26, 2002 at 09:20:20AM +0200, Alex Ruzin
> wrote:
> >Actually I only meant to make the definition for
> this
> >object *semantically* better. Are you agree with my
> proposition
> >"in general", except "MAX-ACCESS"? Do you think,
> that definition
> >of this object has to be improved?
> >If so, I propose
> >
> >    dot1dStpPortEnable OBJECT-TYPE
> >        SYNTAX      INTEGER {
> >                        dummyReadValue(0),
> >                        forceBlock(1),
> >                        forceDisable(2)
> >                   }
> >        MAX-ACCESS  read-write
> >        STATUS      current
> >        DESCRIPTION
> >            "'Force Port State' of the port. Both
> GET and GETNEXT operation
> >              always return value
> dummyReadValue(0). An attempt to write the value
> >             dummyReadValue(0) must cause an
> error."
> >        REFERENCE
> >            "IEEE 802.1D-1998: Section 14.8.2.2"
> >        ::= { dot1dStpPortEntry 4 }
> >
> >Your comments and/or proposition, please?
> 
> The operation of this object is clear but such a
> redefinition
> would not be allowed by IESG mib doctors as it is
> not backward compatible. 
> 
> If this definition were for a new object, then I
> don't see why there is
> a need for a dummyReadValue other than to create a
> write-only style access.
> The SMIv2 dropped write-only access for a purpose
> and as such most MIB 
> doctors would discourage its use.
> 
> I think dot1dStpPortEnable should be left as-is but
> the front matter
> should explain how this object was supposed to
> operate since it 
> is clear that many vendors did not implement it
> according to 
> the original authors intentions.
> 
> Mike MacFaden
> 
> _______________________________________________
> Bridge-mib mailing list
> Bri...@ie...
> https://www1.ietf.org/mailman/listinfo/bridge-mib


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

[Rstplib-users] Re: Q: Traps in Bridge MIB?

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

There is no work ongoing for Spanning Tree traps, other than to define them in
the SMIv2 notification format.  See
http://www.ietf.org/internet-drafts/draft-ietf-bridge-bridgemib-smiv2-02.txt for
the definitions.

The newRoot and topologyChange traps apply to RSTP as well as legacy STP.

Les...





al...@nb... (Alex Ruzin) on 01/05/2002 16:54:55

Please respond to Ar...@Op...

Sent by:  al...@nb... (Alex Ruzin)


To:   Les Bell/GB/3Com
cc:   bri...@ie..., std...@ie...,
      rst...@li...
Subject:  Q: Traps in Bridge MIB?




Is Bridge MIB WG (or IEEE 802.1 WG?) working on Spanning Tree traps in the
MIB?
If yes - what is a status?
For example, which parameters will have legacy (newRoot & topologyChange)
and/or new traps?

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

[Rstplib-users] Q: Traps in Bridge MIB?

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

Is Bridge MIB WG (or IEEE 802.1 WG?) working on Spanning Tree traps in the
MIB?
If yes - what is a status?
For example, which parameters will have legacy (newRoot & topologyChange)
and/or new traps?

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

[Rstplib-users] RE: Learning & Forwarding flags in RST BPDU?

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

What I meant was: where and how may I obtain previous rev of P802.1y drafts?
[Sorry for stupid question, but could you reply, please]
Regards, Beth

Tony > What I meant was I will add it to the next rev of the P802.1y draft -
Tony > probably April/May timeframe.
Tony >
Tony > Regards,
Tony > Tony

> >Mr. Jeffree,
> >
> >Where and how may I obtain P802.1y list?
> >Regards, Beth


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

[Rstplib-users] RE: Learning & Forwarding flags in RST BPDU?

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

What I meant was I will add it to the next rev of the P802.1y draft -=20
probably April/May timeframe.

Regards,
Tony


At 09:56 26/03/2002 +0000, Elisabeth Green wrote:

>Mr. Jeffree,
>
>Where and how may I obtain P802.1y list?
>Regards, Beth
>
>Tony>Given that these fields are defined in the PDU,
>Tony>it seems reasonable to me
>Tony>that the spec should specify how they are
>Tony>populated, and how (if at all)
>Tony>they are used on receipt.  If the spec is
>Tony>silent on these points (which
>Tony>sounds likely from the past conversation
>Tony>on this topic) then this should be
>Tony>a maintenance item for P802.1y. I will add
>Tony>it to the list.
>Tony>
>Tony>Regards,
>Tony>Tony
>Tony>At 23:15 25/03/2002 -0800, Ali Chanaui wrote:
>Tony>
>>>Mr. Goubert,
>>>
>>>I want to ask you now: do you think, that these flags
>>>may be avoided in outgoing RST BPDU and such
>>>implementation would be compatible with IEEE 802.1w?
>>>
>>>I checked only one implementation on
>>>http://rstplib.sourceforge.net/ (apropos, did you
>>>check it?) and I see, that these flags are not sent
>>>there at all in function txRstp() in file transmit.c;
>>>and Alex keeps a silence about the issue :(
>>>
>>>Dou you find, that the request to IEEE 802.1y must be
>>>done with
>>>your (my? our?) proposition?
>>>Yours truly, Ali
>>>
>>>--- Gerard Goubert <gw...@io...> wrote:
>>> > Ali,
>>> >
>>> > (I hope you have html email--- otherwise the colors
>>> > won't work)
>>> >
>>> > I agree with you, though throughout our work with
>>> > RSTP we have sort of
>>> > assumed that the blue (if html is on) statement
>>> > below is implied.
>>> >
>>> > However, I cannot find anywhere where a bridge is
>>> > required to look at
>>> > the Learning and Forwarding flags in a received
>>> > BPDU. I would then come
>>> > to the conclusion that these two flags are
>>> > informational in nature and
>>> > should be set according to the blue statement
>>> > below.. This is good in a
>>> > situation like ours where we are examining the
>>> > BPDU's that are sent with
>>> > a traffic analyzer, we can directly see (without the
>>> > use of the CLI)
>>> > what state(s) the port (that sent the BPDU) is in.
>>> > However, the bridge
>>> > receiving the BPDU does not need to know this
>>> > information, and the state
>>> > machines do not have any mechanisms to enhance the
>>> > operation of RSTP if
>>> > it is known that the 'neighbor' bridge (the one
>>> > sending the BPDU with
>>> > flags set) is transitioning (or has transitioned) to
>>> > the learning or
>>> > forwarding state.
>>> >
>>> > As far as encoding:
>>> > Forwarding =3D True =3D 1
>>> > Forwarding =3D False =3D 0
>>> > Learning =3D True =3D 1
>>> > Learning =3D False =3D 0
>>> > (This is just my assumption)
>>> >
>>> > I would think that these flag fields should be
>>> > utilized, but perhaps the
>>> > intent was for informational use only and not to
>>> > affect any state
>>> > machine by triggering a transition.
>>> >
>>> > In 17.18.1, 17.18.19 and 17.18.20 it talks about
>>> > checking and setting
>>> > flags (agreed->Agreement Flag and
>>> > proposing->Proposal Flag) so I would
>>> > say (IMHO) that there should also be a sentence
>>> > added to both 17.18.5
>>> > and 17.18.9 saying that a flag should be set.
>>> >
>>> > I know I am not answering your question, but we too
>>> > have discussed this
>>> > issue and decided to wait and see how people choose
>>> > to implement
>>> > .1w-d10. From the implementations that we have seen.
>>> > it seems that our
>>> > interpretation seems to agree with how other people
>>> > are interpreting the
>>> > draft.
>>> >
>>> > Gerard Goubert
>>> > Bridge Functions Consortium
>>> > Operations Manager
>>> > InterOperability Lab @ UNH
>>> > gw...@io... 603.862.2060
>>> > BFC Phone: 603.862.3525
>>> >
>>> > Below are the clauses in question.
>>> >
>>> > 9.3.3 Rapid Spanning Tree BPDUs (RST BPDUs)
>>> > <snip>
>>> > g) The Learning flag is encoded in Bit 5 of Octet 5
>>> > of the BPDU (see
>>> > 17.19.16).
>>> > h) The Forwarding flag is encoded in Bit 6 of Octet
>>> > 5 of the BPDU (see
>>> > 17.19.16).
>>> > <snip>
>>> >
>>> > 17.19.16 txRstp()
>>> > Transmits an RST BPDU. The first four components of
>>> > the message priority
>>> > vector (17.4.2.2) conveyed in
>>> > the BPDU are set to the value of portPriority
>>> > (17.18.17) for this Port.
>>> > The Port Role in the BPDU (9.3.3) is
>>> > set to the current value of the role variable for
>>> > the transmitting port
>>> > (17.18.30). The Agreement and Proposal
>>> > flags in the BPDU are set to the values of the
>>> > synced (17.18.35) and
>>> > proposing (17.18.20) variables for the
>>> > transmitting Port respectively. The topology change
>>> > flag is set if
>>> > (tcWhile !=3D 0) for the Port. The topology
>>> > change acknowledge flag in the BPDU is never used
>>> > and is set to zero.
>>> > The value of the Message Age, Max
>>> > Age, Fwd Delay, and Hello Time parameters conveyed
>>> > in the BPDU are set
>>> > to the values held in portTimes
>>> > (17.18.18) for the Port.
>>> >
>>> > There should be a phrase here something like this:
>>> > The Learning and Forwarding Flags in the BPDU are
>>> > set to the values of
>>> > learning (17.18.9) and forwarding (17.18.5),
>>> > respectively. These values
>>> > are set by the Port State Transition state machine
>>> > (17.24, fig. 17-18)
>>> > (This seems to be implied, but never explicitly
>>> > stated)
>>> >
>>> > 17.18.5 forwarding
>>> > This is the operational state for the packet
>>> > forwarding function. It is
>>> > set TRUE by the Port State Transitions
>>> > state machine when packet forwarding is enabled. It
>>> > is set FALSE by the
>>> > Port State Transitions state machine
>>> > when packet forwarding is disabled.
>>> >
>>> > 17.18.9 learning
>>> > This is the operational state for the source address
>>> > learning function.
>>> > It is set TRUE by the Port State Transitions
>>> > state machine when source address learning is
>>> > enabled. It is set FALSE
>>> > by the Port State Transitions
>>> > state machine when source address learning is
>>> > disabled.
>>> >
>>> >
>>> > 17.24 Port State Transition state machine
>>> > <snip>
>>> > On entry to the LEARNING state, learning is enabled
>>> > and then the
>>> > learning variable is set TRUE. The state
>>> > machine transitions back to DISCARDING if learn
>>> > becomes FALSE, and
>>> > transitions to FORWARDING if
>>> > forward becomes TRUE.  What about the flag? (Set
>>> > Learning flag =3D 1)
>>> >
>>> > In the FORWARDING state, the tc variable is set TRUE
>>> > if the Port is not
>>> > an edge Port; this signals to the
>>> > Topology Change state machine that topology change
>>> > information should be
>>> > propagated, as this Port has
>>> > been added to the active topology. Forwarding is
>>> > enabled and then the
>>> > forwarding variable is set TRUE. The
>>> > state machine will revert to the DISCARDING state if
>>> > forward becomes
>>> > FALSE. What about the flag? (Set Forwarding flag =3D1)
>>> > <snip>
>>> >
>>> >
>>> >
>>> >
>>> > > -----Original Message-----
>>> > > From: own...@ma...
>>> > [mailto:owner-stds-802-
>>> >> > > 1...@ma...] On Behalf Of Ali Chanaui
>>> > > Sent: Sunday, March 24, 2002 4:40 AM
>>> > > To: std...@ie...
>>> > > Subject: Q: Learning & Forwarding flags in RST
>>> > BPDU?
>>> > >
>>> > >
>>> > > Hi All,
>>> > > In IEEE 802.1w in RST BPDU there are two bits:
>>> > > Learning flag (9.3.3.g) and Forwarding flag
>>> > (9.3.3.h).
>>> > > Both of them are referenced to 17.19.16, but there
>>> > is
>>> > > no
>>> > > any any mention about these flags coding.
>>> > > And what is more: there is no description, how do
>>> > we
>>> > > use
>>> > > these bit in 17.19.8
>>> > > I read P802.1w/D10, March 26, 2001.
>>> > > It seems, that:
>>> > > a) you simply forgot about these flags
>>> > > b) these flags will be used in future, for example
>>> > in
>>> > > .1s
>>> > > c) thse flags are dedicated for debugging.
>>> > > d) I missed some significant part of the spec.
>>> > >
>>> > > Please, remove my scruple,
>>> > > Sincerely yours, Ali
>>> > >
>>> > >
>>> >
>>>=3D=3D=3D message truncated =3D=3D=3D> BEGIN:VCARD
>>> > VERSION:2.1
>>> > N:Goubert;Gerard;W;Mr.
>>> > FN:Gerard W Goubert (gw...@io...)
>>> > ORG:Interoperability Lab - BFC;BFC
>>> > TITLE:Operations Manager
>>> > TEL;WORK;VOICE:603-862-3525
>>> > TEL;CELL;VOICE:(603)-759-7922
>>> > ADR;WORK:;337;337 Morse Hall;Durham;NH;03824;USA
>>> > LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:337=3D0D=3D0A337
>>> > Morse Hall=3D0D=3D0ADurham, NH 03824=3D0D=3D0AUSA
>>> > ADR;HOME:;;;Dover;NH;03820;USA
>>> > LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:Dover, NH
>>> > 03820=3D0D=3D0AUSA
>>> > EMAIL;PREF;INTERNET:gw...@io...
>>> > REV:20010705T194312Z
>>> > END:VCARD
>>> >
>>>
>>>
>>>__________________________________________________
>>>Do You Yahoo!?
>>>Yahoo! Movies - coverage of the 74th Academy Awards=AE
>>>http://movies.yahoo.com/
>>
>>
>
>
>_________________________________________________________________
>Join the world=92s largest e-mail service with MSN Hotmail.=20
>http://www.hotmail.com
>
>

[Rstplib-users] RE: Learning & Forwarding flags in RST BPDU?

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

Mr. Jeffree,

Where and how may I obtain P802.1y list?
Regards, Beth

Tony>Given that these fields are defined in the PDU,
Tony>it seems reasonable to me
Tony>that the spec should specify how they are
Tony>populated, and how (if at all)
Tony>they are used on receipt.  If the spec is
Tony>silent on these points (which
Tony>sounds likely from the past conversation
Tony>on this topic) then this should be
Tony>a maintenance item for P802.1y. I will add
Tony>it to the list.
Tony>
Tony>Regards,
Tony>Tony
Tony>At 23:15 25/03/2002 -0800, Ali Chanaui wrote:
Tony>
>>Mr. Goubert,
>>
>>I want to ask you now: do you think, that these flags
>>may be avoided in outgoing RST BPDU and such
>>implementation would be compatible with IEEE 802.1w?
>>
>>I checked only one implementation on
>>http://rstplib.sourceforge.net/ (apropos, did you
>>check it?) and I see, that these flags are not sent
>>there at all in function txRstp() in file transmit.c;
>>and Alex keeps a silence about the issue :(
>>
>>Dou you find, that the request to IEEE 802.1y must be
>>done with
>>your (my? our?) proposition?
>>Yours truly, Ali
>>
>>--- Gerard Goubert <gw...@io...> wrote:
>> > Ali,
>> >
>> > (I hope you have html email--- otherwise the colors
>> > won't work)
>> >
>> > I agree with you, though throughout our work with
>> > RSTP we have sort of
>> > assumed that the blue (if html is on) statement
>> > below is implied.
>> >
>> > However, I cannot find anywhere where a bridge is
>> > required to look at
>> > the Learning and Forwarding flags in a received
>> > BPDU. I would then come
>> > to the conclusion that these two flags are
>> > informational in nature and
>> > should be set according to the blue statement
>> > below.. This is good in a
>> > situation like ours where we are examining the
>> > BPDU's that are sent with
>> > a traffic analyzer, we can directly see (without the
>> > use of the CLI)
>> > what state(s) the port (that sent the BPDU) is in.
>> > However, the bridge
>> > receiving the BPDU does not need to know this
>> > information, and the state
>> > machines do not have any mechanisms to enhance the
>> > operation of RSTP if
>> > it is known that the 'neighbor' bridge (the one
>> > sending the BPDU with
>> > flags set) is transitioning (or has transitioned) to
>> > the learning or
>> > forwarding state.
>> >
>> > As far as encoding:
>> > Forwarding = True = 1
>> > Forwarding = False = 0
>> > Learning = True = 1
>> > Learning = False = 0
>> > (This is just my assumption)
>> >
>> > I would think that these flag fields should be
>> > utilized, but perhaps the
>> > intent was for informational use only and not to
>> > affect any state
>> > machine by triggering a transition.
>> >
>> > In 17.18.1, 17.18.19 and 17.18.20 it talks about
>> > checking and setting
>> > flags (agreed->Agreement Flag and
>> > proposing->Proposal Flag) so I would
>> > say (IMHO) that there should also be a sentence
>> > added to both 17.18.5
>> > and 17.18.9 saying that a flag should be set.
>> >
>> > I know I am not answering your question, but we too
>> > have discussed this
>> > issue and decided to wait and see how people choose
>> > to implement
>> > .1w-d10. From the implementations that we have seen.
>> > it seems that our
>> > interpretation seems to agree with how other people
>> > are interpreting the
>> > draft.
>> >
>> > Gerard Goubert
>> > Bridge Functions Consortium
>> > Operations Manager
>> > InterOperability Lab @ UNH
>> > gw...@io... 603.862.2060
>> > BFC Phone: 603.862.3525
>> >
>> > Below are the clauses in question.
>> >
>> > 9.3.3 Rapid Spanning Tree BPDUs (RST BPDUs)
>> > <snip>
>> > g) The Learning flag is encoded in Bit 5 of Octet 5
>> > of the BPDU (see
>> > 17.19.16).
>> > h) The Forwarding flag is encoded in Bit 6 of Octet
>> > 5 of the BPDU (see
>> > 17.19.16).
>> > <snip>
>> >
>> > 17.19.16 txRstp()
>> > Transmits an RST BPDU. The first four components of
>> > the message priority
>> > vector (17.4.2.2) conveyed in
>> > the BPDU are set to the value of portPriority
>> > (17.18.17) for this Port.
>> > The Port Role in the BPDU (9.3.3) is
>> > set to the current value of the role variable for
>> > the transmitting port
>> > (17.18.30). The Agreement and Proposal
>> > flags in the BPDU are set to the values of the
>> > synced (17.18.35) and
>> > proposing (17.18.20) variables for the
>> > transmitting Port respectively. The topology change
>> > flag is set if
>> > (tcWhile != 0) for the Port. The topology
>> > change acknowledge flag in the BPDU is never used
>> > and is set to zero.
>> > The value of the Message Age, Max
>> > Age, Fwd Delay, and Hello Time parameters conveyed
>> > in the BPDU are set
>> > to the values held in portTimes
>> > (17.18.18) for the Port.
>> >
>> > There should be a phrase here something like this:
>> > The Learning and Forwarding Flags in the BPDU are
>> > set to the values of
>> > learning (17.18.9) and forwarding (17.18.5),
>> > respectively. These values
>> > are set by the Port State Transition state machine
>> > (17.24, fig. 17-18)
>> > (This seems to be implied, but never explicitly
>> > stated)
>> >
>> > 17.18.5 forwarding
>> > This is the operational state for the packet
>> > forwarding function. It is
>> > set TRUE by the Port State Transitions
>> > state machine when packet forwarding is enabled. It
>> > is set FALSE by the
>> > Port State Transitions state machine
>> > when packet forwarding is disabled.
>> >
>> > 17.18.9 learning
>> > This is the operational state for the source address
>> > learning function.
>> > It is set TRUE by the Port State Transitions
>> > state machine when source address learning is
>> > enabled. It is set FALSE
>> > by the Port State Transitions
>> > state machine when source address learning is
>> > disabled.
>> >
>> >
>> > 17.24 Port State Transition state machine
>> > <snip>
>> > On entry to the LEARNING state, learning is enabled
>> > and then the
>> > learning variable is set TRUE. The state
>> > machine transitions back to DISCARDING if learn
>> > becomes FALSE, and
>> > transitions to FORWARDING if
>> > forward becomes TRUE.  What about the flag? (Set
>> > Learning flag = 1)
>> >
>> > In the FORWARDING state, the tc variable is set TRUE
>> > if the Port is not
>> > an edge Port; this signals to the
>> > Topology Change state machine that topology change
>> > information should be
>> > propagated, as this Port has
>> > been added to the active topology. Forwarding is
>> > enabled and then the
>> > forwarding variable is set TRUE. The
>> > state machine will revert to the DISCARDING state if
>> > forward becomes
>> > FALSE. What about the flag? (Set Forwarding flag =1)
>> > <snip>
>> >
>> >
>> >
>> >
>> > > -----Original Message-----
>> > > From: own...@ma...
>> > [mailto:owner-stds-802-
>> > > 1...@ma...] On Behalf Of Ali Chanaui
>> > > Sent: Sunday, March 24, 2002 4:40 AM
>> > > To: std...@ie...
>> > > Subject: Q: Learning & Forwarding flags in RST
>> > BPDU?
>> > >
>> > >
>> > > Hi All,
>> > > In IEEE 802.1w in RST BPDU there are two bits:
>> > > Learning flag (9.3.3.g) and Forwarding flag
>> > (9.3.3.h).
>> > > Both of them are referenced to 17.19.16, but there
>> > is
>> > > no
>> > > any any mention about these flags coding.
>> > > And what is more: there is no description, how do
>> > we
>> > > use
>> > > these bit in 17.19.8
>> > > I read P802.1w/D10, March 26, 2001.
>> > > It seems, that:
>> > > a) you simply forgot about these flags
>> > > b) these flags will be used in future, for example
>> > in
>> > > .1s
>> > > c) thse flags are dedicated for debugging.
>> > > d) I missed some significant part of the spec.
>> > >
>> > > Please, remove my scruple,
>> > > Sincerely yours, Ali
>> > >
>> > >
>> >
>>=== message truncated ===> BEGIN:VCARD
>> > VERSION:2.1
>> > N:Goubert;Gerard;W;Mr.
>> > FN:Gerard W Goubert (gw...@io...)
>> > ORG:Interoperability Lab - BFC;BFC
>> > TITLE:Operations Manager
>> > TEL;WORK;VOICE:603-862-3525
>> > TEL;CELL;VOICE:(603)-759-7922
>> > ADR;WORK:;337;337 Morse Hall;Durham;NH;03824;USA
>> > LABEL;WORK;ENCODING=QUOTED-PRINTABLE:337=0D=0A337
>> > Morse Hall=0D=0ADurham, NH 03824=0D=0AUSA
>> > ADR;HOME:;;;Dover;NH;03820;USA
>> > LABEL;HOME;ENCODING=QUOTED-PRINTABLE:Dover, NH
>> > 03820=0D=0AUSA
>> > EMAIL;PREF;INTERNET:gw...@io...
>> > REV:20010705T194312Z
>> > END:VCARD
>> >
>>
>>
>>__________________________________________________
>>Do You Yahoo!?
>>Yahoo! Movies - coverage of the 74th Academy Awards®
>>http://movies.yahoo.com/
>
>
>


_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

[Rstplib-users] RE: Learning & Forwarding flags in RST BPDU?

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

On Tuesday, March 26, 2002 9:16 AM Ali Chanaui wrote:
Ali> I want to ask you now: do you think, that these flags
Ali> may be avoided in outgoing RST BPDU and such
Ali> implementation would be compatible with IEEE 802.1w?
Ali> 
Ali> I checked only one implementation on
Ali> http://rstplib.sourceforge.net/ (apropos, did you
Ali> check it?) and I see, that these flags are not sent
Ali> there at all in function txRstp() in file transmit.c;
Ali> and Alex keeps a silence about the issue :(
Ali> 

Excuse me, Ali, I was out of the business.
You are right: I don't use these flags in rstplib since .1w doesn't mention
them in 17.19.8 nor in 17.19.16. From other side, I don't need them
for "examining the BPDU's", as  Gerard writes, while I have
another tools for that.
I'll implement these flags (you are right again, function
txRstp in file transmit.c is the place for it) as soon as the spec will be
correspondingly changed.

Regards, Alex

> 
> --- Gerard Goubert <gw...@io...> wrote:
> > Ali,
> >  
> > (I hope you have html email--- otherwise the colors
> > won't work)
> >  
> > I agree with you, though throughout our work with
> > RSTP we have sort of
> > assumed that the blue (if html is on) statement
> > below is implied.
> >  
> > However, I cannot find anywhere where a bridge is
> > required to look at
> > the Learning and Forwarding flags in a received
> > BPDU. I would then come
> > to the conclusion that these two flags are
> > informational in nature and
> > should be set according to the blue statement
> > below.. This is good in a
> > situation like ours where we are examining the
> > BPDU's that are sent with
> > a traffic analyzer, we can directly see (without the
> > use of the CLI)
> > what state(s) the port (that sent the BPDU) is in.
> > However, the bridge
> > receiving the BPDU does not need to know this
> > information, and the state
> > machines do not have any mechanisms to enhance the
> > operation of RSTP if
> > it is known that the 'neighbor' bridge (the one
> > sending the BPDU with
> > flags set) is transitioning (or has transitioned) to
> > the learning or
> > forwarding state.
> >  
> > As far as encoding:
> > Forwarding = True = 1
> > Forwarding = False = 0
> > Learning = True = 1
> > Learning = False = 0
> > (This is just my assumption)
> >  
> > I would think that these flag fields should be
> > utilized, but perhaps the
> > intent was for informational use only and not to
> > affect any state
> > machine by triggering a transition.
> >  
> > In 17.18.1, 17.18.19 and 17.18.20 it talks about
> > checking and setting
> > flags (agreed->Agreement Flag and
> > proposing->Proposal Flag) so I would
> > say (IMHO) that there should also be a sentence
> > added to both 17.18.5
> > and 17.18.9 saying that a flag should be set.
> >  
> > I know I am not answering your question, but we too
> > have discussed this
> > issue and decided to wait and see how people choose
> > to implement
> > .1w-d10. From the implementations that we have seen.
> > it seems that our
> > interpretation seems to agree with how other people
> > are interpreting the
> > draft.
> >  
> > Gerard Goubert
> > Bridge Functions Consortium
> > Operations Manager
> > InterOperability Lab @ UNH 
> > gw...@io... 603.862.2060
> > BFC Phone: 603.862.3525
> >  
> > Below are the clauses in question.
> >  
> > 9.3.3 Rapid Spanning Tree BPDUs (RST BPDUs)
> > <snip>
> > g) The Learning flag is encoded in Bit 5 of Octet 5
> > of the BPDU (see
> > 17.19.16).
> > h) The Forwarding flag is encoded in Bit 6 of Octet
> > 5 of the BPDU (see
> > 17.19.16).
> > <snip>
> >  
> > 17.19.16 txRstp()
> > Transmits an RST BPDU. The first four components of
> > the message priority
> > vector (17.4.2.2) conveyed in
> > the BPDU are set to the value of portPriority
> > (17.18.17) for this Port.
> > The Port Role in the BPDU (9.3.3) is
> > set to the current value of the role variable for
> > the transmitting port
> > (17.18.30). The Agreement and Proposal
> > flags in the BPDU are set to the values of the
> > synced (17.18.35) and
> > proposing (17.18.20) variables for the
> > transmitting Port respectively. The topology change
> > flag is set if
> > (tcWhile != 0) for the Port. The topology
> > change acknowledge flag in the BPDU is never used
> > and is set to zero.
> > The value of the Message Age, Max
> > Age, Fwd Delay, and Hello Time parameters conveyed
> > in the BPDU are set
> > to the values held in portTimes
> > (17.18.18) for the Port.
> >  
> > There should be a phrase here something like this:
> > The Learning and Forwarding Flags in the BPDU are
> > set to the values of
> > learning (17.18.9) and forwarding (17.18.5),
> > respectively. These values
> > are set by the Port State Transition state machine
> > (17.24, fig. 17-18) 
> > (This seems to be implied, but never explicitly
> > stated)
> >  
> > 17.18.5 forwarding
> > This is the operational state for the packet
> > forwarding function. It is
> > set TRUE by the Port State Transitions
> > state machine when packet forwarding is enabled. It
> > is set FALSE by the
> > Port State Transitions state machine
> > when packet forwarding is disabled.
> >  
> > 17.18.9 learning
> > This is the operational state for the source address
> > learning function.
> > It is set TRUE by the Port State Transitions
> > state machine when source address learning is
> > enabled. It is set FALSE
> > by the Port State Transitions
> > state machine when source address learning is
> > disabled.
> >  
> >  
> > 17.24 Port State Transition state machine
> > <snip>
> > On entry to the LEARNING state, learning is enabled
> > and then the
> > learning variable is set TRUE. The state
> > machine transitions back to DISCARDING if learn
> > becomes FALSE, and
> > transitions to FORWARDING if
> > forward becomes TRUE.  What about the flag? (Set
> > Learning flag = 1)
> >  
> > In the FORWARDING state, the tc variable is set TRUE
> > if the Port is not
> > an edge Port; this signals to the
> > Topology Change state machine that topology change
> > information should be
> > propagated, as this Port has
> > been added to the active topology. Forwarding is
> > enabled and then the
> > forwarding variable is set TRUE. The
> > state machine will revert to the DISCARDING state if
> > forward becomes
> > FALSE. What about the flag? (Set Forwarding flag =1)
> > <snip>
> >  
> >  
> >  
> >  
> > > -----Original Message-----
> > > From: own...@ma...
> > [mailto:owner-stds-802-
> > > 1...@ma...] On Behalf Of Ali Chanaui
> > > Sent: Sunday, March 24, 2002 4:40 AM
> > > To: std...@ie...
> > > Subject: Q: Learning & Forwarding flags in RST
> > BPDU?
> > > 
> > > 
> > > Hi All,
> > > In IEEE 802.1w in RST BPDU there are two bits:
> > > Learning flag (9.3.3.g) and Forwarding flag
> > (9.3.3.h).
> > > Both of them are referenced to 17.19.16, but there
> > is
> > > no
> > > any any mention about these flags coding.
> > > And what is more: there is no description, how do
> > we
> > > use
> > > these bit in 17.19.8
> > > I read P802.1w/D10, March 26, 2001.
> > > It seems, that:
> > > a) you simply forgot about these flags
> > > b) these flags will be used in future, for example
> > in
> > > .1s
> > > c) thse flags are dedicated for debugging.
> > > d) I missed some significant part of the spec.
> > > 
> > > Please, remove my scruple,
> > > Sincerely yours, Ali
> > > 
> > > 
> > 
> === message truncated ===> BEGIN:VCARD
> > VERSION:2.1
> > N:Goubert;Gerard;W;Mr.
> > FN:Gerard W Goubert (gw...@io...)
> > ORG:Interoperability Lab - BFC;BFC
> > TITLE:Operations Manager
> > TEL;WORK;VOICE:603-862-3525
> > TEL;CELL;VOICE:(603)-759-7922
> > ADR;WORK:;337;337 Morse Hall;Durham;NH;03824;USA
> > LABEL;WORK;ENCODING=QUOTED-PRINTABLE:337=0D=0A337
> > Morse Hall=0D=0ADurham, NH 03824=0D=0AUSA
> > ADR;HOME:;;;Dover;NH;03820;USA
> > LABEL;HOME;ENCODING=QUOTED-PRINTABLE:Dover, NH
> > 03820=0D=0AUSA
> > EMAIL;PREF;INTERNET:gw...@io...
> > REV:20010705T194312Z
> > END:VCARD
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Movies - coverage of the 74th Academy Awards.
> http://movies.yahoo.com/
> 

[Rstplib-users] RE: Learning & Forwarding flags in RST BPDU?

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

Mr. Goubert,

I want to ask you now: do you think, that these flags
may be avoided in outgoing RST BPDU and such
implementation would be compatible with IEEE 802.1w?

I checked only one implementation on
http://rstplib.sourceforge.net/ (apropos, did you
check it?) and I see, that these flags are not sent
there at all in function txRstp() in file transmit.c;
and Alex keeps a silence about the issue :(

Dou you find, that the request to IEEE 802.1y must be
done with
your (my? our?) proposition?
Yours truly, Ali

--- Gerard Goubert <gw...@io...> wrote:
> Ali,
>  
> (I hope you have html email--- otherwise the colors
> won't work)
>  
> I agree with you, though throughout our work with
> RSTP we have sort of
> assumed that the blue (if html is on) statement
> below is implied.
>  
> However, I cannot find anywhere where a bridge is
> required to look at
> the Learning and Forwarding flags in a received
> BPDU. I would then come
> to the conclusion that these two flags are
> informational in nature and
> should be set according to the blue statement
> below.. This is good in a
> situation like ours where we are examining the
> BPDU's that are sent with
> a traffic analyzer, we can directly see (without the
> use of the CLI)
> what state(s) the port (that sent the BPDU) is in.
> However, the bridge
> receiving the BPDU does not need to know this
> information, and the state
> machines do not have any mechanisms to enhance the
> operation of RSTP if
> it is known that the 'neighbor' bridge (the one
> sending the BPDU with
> flags set) is transitioning (or has transitioned) to
> the learning or
> forwarding state.
>  
> As far as encoding:
> Forwarding = True = 1
> Forwarding = False = 0
> Learning = True = 1
> Learning = False = 0
> (This is just my assumption)
>  
> I would think that these flag fields should be
> utilized, but perhaps the
> intent was for informational use only and not to
> affect any state
> machine by triggering a transition.
>  
> In 17.18.1, 17.18.19 and 17.18.20 it talks about
> checking and setting
> flags (agreed->Agreement Flag and
> proposing->Proposal Flag) so I would
> say (IMHO) that there should also be a sentence
> added to both 17.18.5
> and 17.18.9 saying that a flag should be set.
>  
> I know I am not answering your question, but we too
> have discussed this
> issue and decided to wait and see how people choose
> to implement
> .1w-d10. From the implementations that we have seen.
> it seems that our
> interpretation seems to agree with how other people
> are interpreting the
> draft.
>  
> Gerard Goubert
> Bridge Functions Consortium
> Operations Manager
> InterOperability Lab @ UNH 
> gw...@io... 603.862.2060
> BFC Phone: 603.862.3525
>  
> Below are the clauses in question.
>  
> 9.3.3 Rapid Spanning Tree BPDUs (RST BPDUs)
> <snip>
> g) The Learning flag is encoded in Bit 5 of Octet 5
> of the BPDU (see
> 17.19.16).
> h) The Forwarding flag is encoded in Bit 6 of Octet
> 5 of the BPDU (see
> 17.19.16).
> <snip>
>  
> 17.19.16 txRstp()
> Transmits an RST BPDU. The first four components of
> the message priority
> vector (17.4.2.2) conveyed in
> the BPDU are set to the value of portPriority
> (17.18.17) for this Port.
> The Port Role in the BPDU (9.3.3) is
> set to the current value of the role variable for
> the transmitting port
> (17.18.30). The Agreement and Proposal
> flags in the BPDU are set to the values of the
> synced (17.18.35) and
> proposing (17.18.20) variables for the
> transmitting Port respectively. The topology change
> flag is set if
> (tcWhile != 0) for the Port. The topology
> change acknowledge flag in the BPDU is never used
> and is set to zero.
> The value of the Message Age, Max
> Age, Fwd Delay, and Hello Time parameters conveyed
> in the BPDU are set
> to the values held in portTimes
> (17.18.18) for the Port.
>  
> There should be a phrase here something like this:
> The Learning and Forwarding Flags in the BPDU are
> set to the values of
> learning (17.18.9) and forwarding (17.18.5),
> respectively. These values
> are set by the Port State Transition state machine
> (17.24, fig. 17-18) 
> (This seems to be implied, but never explicitly
> stated)
>  
> 17.18.5 forwarding
> This is the operational state for the packet
> forwarding function. It is
> set TRUE by the Port State Transitions
> state machine when packet forwarding is enabled. It
> is set FALSE by the
> Port State Transitions state machine
> when packet forwarding is disabled.
>  
> 17.18.9 learning
> This is the operational state for the source address
> learning function.
> It is set TRUE by the Port State Transitions
> state machine when source address learning is
> enabled. It is set FALSE
> by the Port State Transitions
> state machine when source address learning is
> disabled.
>  
>  
> 17.24 Port State Transition state machine
> <snip>
> On entry to the LEARNING state, learning is enabled
> and then the
> learning variable is set TRUE. The state
> machine transitions back to DISCARDING if learn
> becomes FALSE, and
> transitions to FORWARDING if
> forward becomes TRUE.  What about the flag? (Set
> Learning flag = 1)
>  
> In the FORWARDING state, the tc variable is set TRUE
> if the Port is not
> an edge Port; this signals to the
> Topology Change state machine that topology change
> information should be
> propagated, as this Port has
> been added to the active topology. Forwarding is
> enabled and then the
> forwarding variable is set TRUE. The
> state machine will revert to the DISCARDING state if
> forward becomes
> FALSE. What about the flag? (Set Forwarding flag =1)
> <snip>
>  
>  
>  
>  
> > -----Original Message-----
> > From: own...@ma...
> [mailto:owner-stds-802-
> > 1...@ma...] On Behalf Of Ali Chanaui
> > Sent: Sunday, March 24, 2002 4:40 AM
> > To: std...@ie...
> > Subject: Q: Learning & Forwarding flags in RST
> BPDU?
> > 
> > 
> > Hi All,
> > In IEEE 802.1w in RST BPDU there are two bits:
> > Learning flag (9.3.3.g) and Forwarding flag
> (9.3.3.h).
> > Both of them are referenced to 17.19.16, but there
> is
> > no
> > any any mention about these flags coding.
> > And what is more: there is no description, how do
> we
> > use
> > these bit in 17.19.8
> > I read P802.1w/D10, March 26, 2001.
> > It seems, that:
> > a) you simply forgot about these flags
> > b) these flags will be used in future, for example
> in
> > .1s
> > c) thse flags are dedicated for debugging.
> > d) I missed some significant part of the spec.
> > 
> > Please, remove my scruple,
> > Sincerely yours, Ali
> > 
> > 
> 
=== message truncated ===> BEGIN:VCARD
> VERSION:2.1
> N:Goubert;Gerard;W;Mr.
> FN:Gerard W Goubert (gw...@io...)
> ORG:Interoperability Lab - BFC;BFC
> TITLE:Operations Manager
> TEL;WORK;VOICE:603-862-3525
> TEL;CELL;VOICE:(603)-759-7922
> ADR;WORK:;337;337 Morse Hall;Durham;NH;03824;USA
> LABEL;WORK;ENCODING=QUOTED-PRINTABLE:337=0D=0A337
> Morse Hall=0D=0ADurham, NH 03824=0D=0AUSA
> ADR;HOME:;;;Dover;NH;03820;USA
> LABEL;HOME;ENCODING=QUOTED-PRINTABLE:Dover, NH
> 03820=0D=0AUSA
> EMAIL;PREF;INTERNET:gw...@io...
> REV:20010705T194312Z
> END:VCARD
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/

[Rstplib-users] Q: Learning & Forwarding flags in RST BPDU?

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

Hi All,
In IEEE 802.1w in RST BPDU there are two bits:
Learning flag (9.3.3.g) and Forwarding flag (9.3.3.h).
Both of them are referenced to 17.19.16, but there is
no
any any mention about these flags coding.
And what is more: there is no description, how do we
use
these bit in 17.19.8
I read P802.1w/D10, March 26, 2001.
It seems, that:
a) you simply forgot about these flags
b) these flags will be used in future, for example in
.1s
c) thse flags are dedicated for debugging.
d) I missed some significant part of the spec.

Please, remove my scruple,
Sincerely yours, Ali




__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/