[Bridge-mib] RE: Learning & Forwarding flags in RST BPDU?
Ali Chanaui <ali_chanaui@yahoo.com> Tue, 26 March 2002 08:11 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27040 for <bridge-archive@odin.ietf.org>; Tue, 26 Mar 2002 03:11:38 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA00352 for bridge-archive@odin.ietf.org; Tue, 26 Mar 2002 03:11:40 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00333; Tue, 26 Mar 2002 03:11:36 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17136 for <bridge-mib@optimus.ietf.org>; Tue, 26 Mar 2002 02:15:56 -0500 (EST)
Received: from web13402.mail.yahoo.com (web13402.mail.yahoo.com [216.136.175.60]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26440 for <bridge-mib@ietf.org>; Tue, 26 Mar 2002 02:15:54 -0500 (EST)
Message-ID: <20020326071555.61498.qmail@web13402.mail.yahoo.com>
Received: from [194.90.136.135] by web13402.mail.yahoo.com via HTTP; Mon, 25 Mar 2002 23:15:55 PST
Date: Mon, 25 Mar 2002 23:15:55 -0800
From: Ali Chanaui <ali_chanaui@yahoo.com>
To: gwg@iol.unh.edu, stds-802-1@ieee.org
Cc: rstplib-users@lists.sourceforge.net, bridge-mib@ietf.org
In-Reply-To: <000301c1d43c$eff71c00$5a76b184@iol.unh.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [Bridge-mib] RE: Learning & Forwarding flags in RST BPDU?
Sender: bridge-mib-admin@ietf.org
Errors-To: bridge-mib-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <bridge-mib.ietf.org>
X-BeenThere: bridge-mib@ietf.org
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 <gwg@iol.unh.edu> 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 > gwg@iol.unh.edu 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: owner-stds-802-1@majordomo.ieee.org > [mailto:owner-stds-802- > > 1@majordomo.ieee.org] On Behalf Of Ali Chanaui > > Sent: Sunday, March 24, 2002 4:40 AM > > To: stds-802-1@ieee.org > > 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 (gwg@iol.unh.edu) > 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:gwg@iol.unh.edu > REV:20010705T194312Z > END:VCARD > __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib