Subject: RE: Questions on Bridge MIB

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 5 Oct 2000 18:22:00 +0200

A good place to ask your question is at the Bridgemib WG mailing list.

I have cc: the list.

Bert

> ----------
> From: 	Arie Nimkovsky[SMTP:[email-masked]]
> Sent: 	Thursday, October 05, 2000 5:10 PM
> To: 	[email-masked]
> Subject: 	Questions on Bridge MIB
> 
> Hello,
> I have several questions regarding the meaning of objects in the Static
> Table of the Bridge MIB (defined in RFC1493). Can you please direct me an
> autority on these issues?
>  
> ----------------------------------------------------------------
> [1] What does it mean that "dot1dStaticAddress" and
> "dot1dStaticReceivePort", which are indexes to the table, are defined as
> read-write? What can be written into them? Should the SET command be
> supported for these objects, and if positive - in what way?
>  
> [2] How exactly "dot1dStaticAllowedToGoTo" should be interpreted:
> - As a limiting mask for flooding while the associated address has not
> been learned yet? In this case, when the actual port IS learned, the
> frames intended for the associated MAC address will be forwarded to this
> port ONLY.
> - Or: as a directive for the forwarding process to ALWAYS send frames to
> the specified ports, regardless of whether the actual port was learnt or
> not?
>  
> [3] What is meant under the term "Filtering Database re-initialization" in
> the following excerpt from the MAC Bridging Standard (IEEE P802.1D/D17 May
> 25, 1998):
>  
> "Changes to the contents of Static Filtering Entries in the Permanent
> Database do not affect forwarding and filtering decisions taken by the
> Forwarding Process until such a time as the Filtering Database is
> re-initialized. 
> NOTE - This aspect of the Permanent Database can be viewed as providing a
> 'boot image' for the Filtering Database, defining the contents of all
> initial entries, before any dynamic filtering information is added."
>  
>  
> When is the Filtering Database usually re-initialized?
>  
> ----------------------------------------------------------------
> Thanks,
> Arie Nimkovsky
> Vyyo Ltd, Israel 
>  
>  
>  
>  
>

---

From: "Les Bell" <[email-masked]>
Date: Tue, 10 Oct 2000 07:26:09 +0100

See comments below.

Les...

"Wijnen, Bert (Bert)" <[email-masked]> on 05/10/2000 17:22:00

Sent by:  "Wijnen, Bert (Bert)" <[email-masked]>

To:   Arie Nimkovsky <[email-masked]>
cc:   [email-masked] (Les Bell/GB/3Com)
Subject:  RE: Questions on Bridge MIB

I have cc: the list.

Bert

Only that this table was originally defined a long time ago,
before the rules on making index columns for tables
not-accessible was introduced.  It does not make much sense
to write to these columns, so don't.

> the specified ports, regardless of whether the actual port was learnt or

This was an interesting topic debated for the Bridge MIB
extensions, see RFC 2674.  The definition we came up with for
dot1qStaticUnicastAllowedToGoTo, the VLAN aware equivalent of
dot1dStaticAllowedToGoTo, makes the use of this more clear.

  "The set of ports for which a frame with a specific
  unicast address will be flooded in the event that it
  has not been learned.  It also specifies the set of
  ports a specific unicast address may be dynamically
  learnt on.  The dot1qTpFdbTable will have an equivalent
  entry with a dot1qTpFdbPort value of '0' until this
  address has been learnt, when it will be updated with
  the port the address has been seen on."