[rbridge] Ingress Rbridge address and BCN - 3rd Issue

Gray, Eric Eric.Gray at marconi.com
Fri Oct 27 15:48:27 PDT 2006


Larry,

	We are in synch on what I mean by "802.1X"

	The issue was - you asked (paraphrasing) why use tunneling if 
the RBridges themselves might have to retain all MAC reachability.

	I answered that this is useful if you have to deal with 802.1X
bridges between RBridges.

	You replied that you thought that was done by (paraphrasing,
again) using an "additional MAC header between the two RBridges."

	To me this _might_ be a terminology issue if - for example -
in your lexicon, there is a difference between "using tunneling" and
and using an "additional MAC header between the two RBridges."  In
any other case, it must be the case that you are addressing some 
issue other than the one that is obviously intended for this thread.

--> -----Original Message-----
--> From: Larry Kreeger (kreeger) [mailto:kreeger at cisco.com] 
--> Sent: Friday, October 27, 2006 5:51 PM
--> To: Gray, Eric
--> Cc: rbridge at postel.org
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN - 3rd Issue
--> 
--> Gray, Eric wrote on Friday, October 27, 2006 11:52 AM:
--> 
--> > -- [SNIP] --
--> > 
--> > --> > 3rd Issue - why use tunneling if RBridges typically may be
--> > --> > required to retain all MAC reachability information?
--> > --> > ==========================================
--> > --> >
--> > --> > 	There are several reasons to do this, independent 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.
--> > 
--> > Look, again, at the definition of the "3rd Issue" above.
--> > 
--> > From you comment, it seems you missed that...
--> 
--> Ok, I looked again, but I don't get it.  Maybe we have a terminology
--> mismatch.  When you say 802.1X I assume you mean 802.1D or 802.1Q. I
--> assume you are talking about the case where one of these bridges is
--> providing transport between two RBridges.  If we are in 
--> sync with that,
--> then I am missing your point.
--> 
--> > --> >
--> > --> > 	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.
--> > 
--> > They are separable in a number of different ways.  Trying 
--> to state it
--> > at a high level, it is certainly possible to optimize your look-up
--> > algorithms for a subset of frequently used entries.  
--> Caching comes to
--> > mind, for example.   
--> > 
--> > -->
--> 


More information about the rbridge mailing list