Subject: [rbridge] Ingress Rbridge address and BCN - 1st Issue

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

Gray, Eric wrote on Friday, October 27, 2006 3:20 PM:

> Larry,
> 
> 	A slower look up may be okay for exception processing.

It depends on how much slower.  Low latency of BCN is very important to
the stability of the feedback loop.

> 
> 	BCNs should be required far less often than frames are being
> forwarded. 

Agreed.

> 	Having a transit RBridge "look inside [at?] the inner MAC"
> is not what is effectively happening - as I understand it - when a
> "core RBridge" is generating a BCN.  BCN-capable core RBridges would
> presumably copy the header information from some subset of the frames
> on a minimally-congested link, strip the tunneling encapsulation and
> originate a new frame containing a Notification (BCN) message.   
> 
> 	This must be a new frame, as opposed to a reflection of the
original
> frame, so it is interesting that people assume this is a trivial
> operation in hardware in the first place.  
> 
> 	Since the BCN-capable RBridge has to "flip" the MAC SA into a
MAC DA
> in a BCN anyway, it MUST look at that part of the frame in every case
> before it can generate a BCN.

You are right, the RBridge would have to parse to inner SA to build the
BCN.

> 
> 	In effect, the frame is (partially) copied, the copied
information
> is locally terminated and used to originate a new message.  This
> message would then be sent - presumably using the usual means for
> message origination - by encapsulating it in RBridge tunnel
> encapsulation and forwarding it to (at least) the ingress RBridge
> from which it was introduced.     
> 
> 	That is not nearly as much of a confusion of layers as it is to
1)
> assume that the frame is munged in hardware and turned around 

Yep, it isn't a munged frame, it is a brand new frame built using info
from the sampled frame.

> and 2) normal processing of originated local messages is bypassed in
an
> attempt to optimize BCN sending at the cost of including additional
> information in _every_ frame.    

Here I disagree.  Since the BCN is a new frame built using info from the
sampled frame, I see no problem in building the shim based on the info
in the sampled shim.

> 
> 	Oh, and, apparently I can blame you for trying... :-)