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

[Gray, Eric]

Larry,

	This may be a moot point.  Your observation is about a method
of implementation.  Logically, what you're doing is an isomorphism of
having a stubbed receiver/sender function where the receiver strips
off the SHIM, passing information to the sender function and the 
sender function constructs a new frame, and adds a new SHIM.  Where 
the difference comes up is in how the information is derived for the 
new SHIM - is it a function of having been provided in the original 
SHIM, or is it a look-up function (as would typically be the case in 
originating a new frame).

	If it is provided in the original SHIM, and there is no reason
to believe a look-up function would provide different information, 
then it is naturally a reasonable optimization to use the provided
information.  What's in question is whether or not it is worth this
optimization to always include the information in the original SHIM.

	Note that - if, for any reason, it is possible that a properly
performed look-up might result in a different SHIM entry - then a
look-up MUST be performed.  Currently, I know of only one reason why
this might be the case - if the topology changed immediately after
receiving the triggering frame - and I cannot say exactly how likely
this is to occur.  I imagine it is very unlikely, and the consequences
of ignoring the change in the rare case where such a change occurs
would be no more pathological than if a change were slightly delayed
for some other reason.

	Where it might be a problem is if another frame were being
originated by a "natural" process (such as responding to management
activity) to the same destination, the look-up for that frame led
to the use of a different egress RBridge and the frames were sent
in a peculiarly pathological order - leading to confusion of 802.1
bridges in the local LAN segment.

	Also, it is conceivable that there might be other cases...

-- [SNIP] --

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

-- [SNIP] --