[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