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

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 27 Oct 2006 20:03:38 -0400

Larry,

	There are other reasons for using a SHIM than RBridge e2e
tunneling.

	Interestingly enough, if we omitted the SHIM, we would be
using simple MAC-in-MAC encapsulation, and we might be able to
further abbreviate that by using tag-stacking.  But that's a
discussion for another forum...

--
Eric 

--> -----Original Message-----
--> From: Larry Kreeger (kreeger) [mailto:kreeger at cisco.com] 
--> Sent: Friday, October 27, 2006 7:55 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 3:48 PM:
--> 
--> > 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."  
--> 
--> Yes, this is the disconnect.  I am assuming that the shim with the
--> egress RBridge that is carried from ingress RBridge to 
--> egress RBridge is
--> the tunnel.  I guess you are referring to the outer MAC 
--> which changes at
--> each hop as the tunnel (or a series of interconnected tunnels).  It
--> seems that if we don't care about scaling, we could remove 
--> the end to
--> end tunnel (dest RBridge), but still retain the additional 
--> MAC header
--> for transiting 802.1Q networks (although I'd like to remove 
--> it for point
--> to point links).
--> 
--> > 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.
--> > --> >
--> > --> > -->
--> > -->
-->