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

[Gray, Eric]

-- [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).

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.

--> 
--> > 
--> > 	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] --