[rbridge] Ingress Rbridge address and BCN

[Larry Kreeger (kreeger)]

Eric,

My responses are inline below. - Larry

Gray, Eric wrote on Friday, October 27, 2006 10:13 AM:

> Larry,
> 
> 	The phrase "one of the advantages" is key here.
>                   +++++++++++++++++++++
> 
> 	We're complicating discussion by combining issues and trying to
> address them all at the same time. 
> 
> 1st Issue - Scale advantages of not retaining end-station MAC
> information in "core RBridges"? ==============================
> 
> 	The sole advantage that would derive from having a requirement
that
> so-called "core RBridges" do not need to retain MAC reachability
> information would be to increase the scale of LAN sizes by reducing
> the memory requirements associated with filtering database entries.   
> It is clearly demonstrable that having smaller filtering database
> entries _would_ result in better scaling properties, consequently
> many people are interested in doing this.  
> 
> 	But increased LAN scaling in not a goal of the work we are doing
> here.  While this is not specifically spelled out in the charter,
> past discussions - including those leading up to creation of the
> charter - have avoided saying anything more than "shall not preclude
> improvements in LAN scaling characteristics" or "must have at least
> similar scaling properties to those currently available with existing
> LAN technology."      
> 
> 	Any requirement we might imagine _should_ be in the charter for
> improving LAN scalability, is conspicuously _not_ in the charter. 
> 
> 	Realistically, our solution must allow for greater LAN scaling
by
> some amount, or it is unlikely to be of interest to many network
> users/administrators and would, therefore, be unlikely to be
> deployed.   
> And the option to discard reachability information that is not
> needed, is one of the factors that may lead to this greater
> scalability.  
> 
> 	But it is non-sensical to argue that discarding information that
is
> not needed will cause problems when it is needed. 
> 
> 	And filtering database sizes is not realistically a bottle-neck
for
> current LAN scalability.  Convergence in STP is.  Link utilization is
> as well.  But in networks where routers have to be able to retain as
> many as 10s of millions of route entries, are filtering databases in
> "core RBridge" with 10s of thousands of MAC entries something we
> should really view as a serious scaling limitation?     

Please correct me if I incorrectly summarize the above.

1) Scaling the number of fowarding entries in the core is not a problem
that TRILL needs to solve.
2) Link utilization is a problem and TRILL needs to be concerned with
it.

If this is correct, it leads me to believe that you would advocate for 
1) Remove the destination RBridge from the shim, and just lookup the
destination MAC directly
2) Eliminate the need for the outer MAC header between two RBridges if
the link is point to point (quite likely in my opinion).

Again, I apologize for not keeping up with the latest discussions, but
have these ideas been discussed already?  If so, could you summarize the
outcome?

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

> 
> 	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.
> 
> 3rd Issue - why use tunneling if RBridges typically may be required
> to retain all MAC reachability information?
> ======================================= 
> 
> 	There are several reasons to do this, indpendent of any desire
to
> reduce memory requirements of RBridges. 
> 
> 	One is that 802.1X bridges on intermediate links are shielded
from
> exposure to MAC addresses on separate bridged LAN segements. 

I thought that was accomplished by adding the additional MAC header
between the two RBridges carrying their MACs.  The 802.1X bridges
connecting them will only learn these two RBridges MACs regardless of
whether there is a destination RBridge in the shim.
> 
> 	Another is that the forwarding entries in RBridges are based on
use
> of RBridge MAC addresses - which reduces the number of entries that
> will typically be used for forwarding by an intermediate RBridge.  

I'm missing the destinction between what you call the "memory
requirements RBridges", and "the number of entries that will typeically
be used for forwarding".  I was assuming these were the same thing.