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

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 27 Oct 2006 19:22:40 -0400

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

-->

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Sat, 28 Oct 2006 18:07:00 -0700

Gray, Eric wrote:
> 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.
> 

Consider the following scenario: Host A is 802.1au compliant
(it will respond to BCNs), and 802.1au capable Bridge C is
part of its path to the end destination D.

At this time if C generates a BCN to A, A will receive it
and adjust its sending rate in compliance with 802.1au,
without dropping frames.

If we place an 802.1au-ignorant RBridge B is injected
between A and C then congestion domain has to shrink,
and C has to act as an edge to the congestion domain.
C has no method of regulating the flow from A to D
other than dropping frames.

If RBridge B is nominally 802.1au compliant, but will
not act as a proxy to relay BCNs then it effectively
becomes the edge of the congestion domain. That means
that B must regulate the flow from A to D by dropping
frames.

The only way an RBridge can avoid impairing 802.1au
congestion avoidance is for it to fully proxy 802.1au
functionality when interacting with an 802.1au bridge
that is not an rbridge.