[rbridge] Ingress Rbridge address and BCN - 1st Issue
Eric.Gray at marconi.com
Fri Oct 27 17:00:18 PDT 2006
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] --
More information about the rbridge