[Bridge-mib] RE: Learning & Forwarding flags in RST BPDU?

[[e-mail] (Alex Ruzin)]

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 <[e-mail]> 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 
> > [e-mail] 603.862.2060
> > BFC Phone: [phone]
> >  
> > 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: [e-mail]
> > [mailto:owner-stds-802-
> > > [e-mail]] On Behalf Of Ali Chanaui
> > > Sent: Sunday, March 24, 2002 4:40 AM
> > > To: [e-mail]
> > > 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 ([e-mail])
> > 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:[e-mail]
> > REV:20010705T194312Z
> > END:VCARD
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Movies - coverage of the 74th Academy Awards.
> http://movies.yahoo.com/
> 

_______________________________________________
Bridge-mib mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/bridge-mib