Subject: [rbridge] Ingress Rbridge address and BCN - 2nd Issue

From: kreeger at cisco.com (Larry Kreeger (kreeger))
Date: Fri, 27 Oct 2006 14:43:17 -0700

Gray, Eric wrote on Friday, October 27, 2006 11:46 AM:

> -- [SNIP] --
> 
> --> >
> --> > 2nd Issue - what is the importance of "optimizing" support for
> BCN? 
> --> >
> ================================================================== 
> --> >
> --> > 	BCN is likely to be important for a number of
applications that
> --> > we care about.  But is it important enough that we should design
> --> > an
> RBridge
> --> > solution that is optimized for it, or is it sufficient that our
> solution
> --> > is not significantly sub-optimal for these applications?
> --> >
> --> > 	As Radia has already pointed out, an RBridge that finds
itself
> --> > with a frame it must deliver, and no corresponding forwarding
> --> > entry, will forward that frame on the ingress RBridge tree
> --> > (corresponding to
> delivery
> --> > of unknown MAC destination "flooding").  This is sub-optimal,
> but 
> --> > the choice that leads to an RBridge finding it needs to do this
> in 
> --> > the BCN
> 
> --> > case is (as I've said before) entirely an implementation choice.
> --> > Presumably, the implementer may choose to discard even BCN
> related 
> --> > MAC
> 
> --> > reachability if - as a trade-off decision - they believe that
> conservative
> --> > retention of MAC reachability is desirable over optimal support
> of 
> BCN.
> --> >
> --> > 	I personally favor the idea of forwarding BCN
notifications on
> --> > the Ingress RBridge Tree - for those implementations that do not
> --> > keep the appropriate MAC reachability information.  I favor
> this because: 
> --> >
> --> > 	1) it is consistent with how bridges work now, therefore
it is
> --> > 	not a departure from "the devil we know,"
> -->
> --> Last time looked at the BCN proposal, there could be a significant
> amount
> --> of BCN traffic during congestion.  Flooding this traffic to ALL
> --> RBridges
> 
> --> seems like a bad idea if you are concerned with link utilization.
> 
> A couple of separable points -
> 
> 1) Flooding will only occur when a specific RBridge has removed (due
> to aging, for example), or failed to retain, an entry it subsequently
> needs.  
> This kind of flooding could occur in any case (although it might
> involve a smaller subset of the entire network). 

I understand that this will occur when an edge RBridge does not have an
entry, but I assume that this will be a fairly rare condition.  Also, I
am expecting the number of flows through an edge RBridge to be much less
than throught a core RBridge, such that the number of MAC addresses
entries needed would be much less at an edge RBridge.  If a core RBridge
did not have a larger table, then it could get easily filled which would
require flooding of the BCNs much more than would occur naturally at an
edge RBridge.

> 
> 2) If, as you say, "there could be a significant amount of BCN
> traffic during congestion", then BCN suffers from fatal design flaws.
> If the need to occasionally flood BCN notifications contributes to
> this flaw, that is an issue (certainly), but it is one that is likely
> to be fixed at the same time as the current fatal flaw in BCN is
> fixed.     

I don't think it is fair to criticize the 802.1au group unless you have
better suggestions.  I suggest you contribute to that group if you feel
it is fatally broken.  In the meantime, RBridges should not compound the
problem.

> 
> -->
> --> >
> --> > 	2) it affects only implementations that are designed to
discard
> --> > 	potentially useful information in favor of reduced
memory needs
> --> > 	and
> --> >
> --> > 	3) it is a generic solution related to Caitlin's earlier
> remarks 
> --> > 	with respect to the relative numbers of "core RBridges"
and the
> --> > 	likelihood that next-hop RBridges on the Ingress RBridge
Tree
> are 
> --> > 	actually going to have an entry for the "unknown MAC
> destination" 
> --> > 	in the frame being flooded on the IRT.
> --> >
> 
> -- [SNIP] --

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Fri, 27 Oct 2006 14:54:41 -0700

Larry Kreeger, responding to Eric Gray, wrote:
>> to aging, for example), or failed to retain, an entry it
>> subsequently needs. This kind of flooding could occur in any case
>> (although it might involve a smaller subset of the entire network).
> 
> I understand that this will occur when an edge RBridge does
> not have an entry, but I assume that this will be a fairly
> rare condition.  Also, I am expecting the number of flows
> through an edge RBridge to be much less than throught a core
> RBridge, such that the number of MAC addresses entries needed
> would be much less at an edge RBridge.  If a core RBridge did
> not have a larger table, then it could get easily filled
> which would require flooding of the BCNs much more than would
> occur naturally at an edge RBridge.
> 
More fundamentally, the egress rbridge will in most case also
encapsulate the reverse-bound frames, and so will have had a 
reason to note the mac->rbridge mapping in the first place.
A "core rbridge" would not have forgotten the mapping, it would
have never looked for it in the first place. Table size is irrelevant.