[rbridge] Ingress Rbridge address and BCN

[Gray, Eric]

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?

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,"

	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.

	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.

--
Eric

--> -----Original Message-----
--> From: Larry Kreeger (kreeger) [mailto:kreeger at cisco.com] 
--> Sent: Friday, October 27, 2006 12:07 PM
--> To: Gray, Eric; Wadekar, Manoj K
--> Cc: rbridge at postel.org
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> 
--> Eric,
--> 
--> I thought one of the advantages of RBridges was that the core of the
--> network did not have to maintain forwarding tables for every host MAC
--> address in the network. If we assume they do, they why should we bother
--> to use RBridge addresses for forwarding at all?  You could essentially
--> program host routes for every destination MAC.
--> 
-->  - Larry
--> 
--> Gray, Eric wrote on Friday, October 27, 2006 8:44 AM:
--> 
--> > Manoj,
--> > 
--> > 	Once again, the assumption that cores do not retain "addresses
--> > of all the end-stations in [the] whole cluster" is a "convenient
--> > assumption" for making the argument that another mechanism is
required.
--> > 
--> > 	Currently, there would be no requirement for retaining all such
--> > addresses as you have to be careful not to send BCN messages to those
--> > end-stations that don't support them.  Moreover, as mentioned
previously, 
--> > it is trivially easy to determine what address information should be 
--> > kept.    
-->