[rbridge] Ingress Rbridge address and BCN - 2nd Issue

[Gray, Eric]

Caitlin,

	Have we moved into the realm of _requiring_ support for BCN
in all RBridges?

	We can assume the "core RBridge" is BCN capable if it has
triggered a BCN event, but we cannot assume that the ingress is
likewise BCN capable unless we're going to require BCN support 
in every RBridge.

	Also, I cannot parse your last paragraph because I cannot 
identify who is doing what to whom.  See specifics below...

--
Eric 

--> -----Original Message-----
--> From: Caitlin Bestler [mailto:caitlinb at broadcom.com] 
--> Sent: Friday, October 27, 2006 6:57 PM
--> To: Gray, Eric; Larry Kreeger (kreeger)
--> Cc: rbridge at postel.org
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN - 2nd Issue
--> 
--> Gray, Eric wrote:
--> > Caitlin,
--> > 
--> > 	At this point I have completely lost the thread of what
--> > you're talking about.  Are you assuming that it is okay for a
--> > "core Rbridge" to literally return the frame that triggers a
--> > BCN to the ingress RBridge that introduced it, and that this
--> > RBridge is then responsible for generating a BCN and acting as an
--> > egress for the BCN? 
--> > 
--> > 	As I understand it, that's asking an awful lot of the
--> > ingress RBridge.
--> 
--> But that functionality would clearly be required for an 802.1au
--> compliant RBridge, because it could receive a BCN from an
--> 802.1au [non-R]bridge.
--> 
--> Clearly it would be undesirable for the 802.1au rbridge to act
--> as the edge of the congestion domain -- it SHOULD (perhaps MUST)
--> forward the BCN to the true source. The rbridge itself is not
--> well suited to adjust the source in a dropless fashion.

Breaking this up, which 802.1au RBridge are you talking about as
acting as the "edge of the congestion domain"?

As I understand it, a BCN looks to most transit devices just like
any other frame that is addressed to someone else.  So which "it"
are you referring to in "it SHOULD (perhaps MUST) forward the BCN
to the true source"?

Which RBridge is not suited to "adjust the source in a dropless
fashion"?

In the model we are currently free to assume (assuming I was not 
asleep when we all agreed that RBridges must ubiquitously support
BCN), the fact that a "core RBridge" has a BCN-triggering event,
indicates that it is a BCN-capable RBridge.  That is all we are
free to assume.  Hence, since it may be the _only_ BCN capable
RBridge, it MUST generate a BCN if there is one to be generated.

I do find the notion of creating a BCN and sending it back to 
the RBridge the BCN-triggering frame came from intriguing.  It
is possible (however unlikely) that the receiving RBridge is 
also a "core RBridge" - so this may be "pushing the bubble down
in one place only to have it pop up in another" - but it may be
demonstrable that this approach has a high probability of being
a "work saving" approach.  At the very least, it doubles the 
probability that a entry will be found for the BCN's destination
MAC address - either in the BCN-capable "core RBridge" or in its
neighboring victim (that may, or may not, be a "core RBridge" as
well).

--
Eric


-->