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

From: kreeger at cisco.com (Larry Kreeger (kreeger))
Date: Fri, 27 Oct 2006 16:54:52 -0700

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