Subject: [rbridge] Ingress Rbridge address and BCN

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

Manoj,

	Thanks!  Your explanation does clarify a few things... 

	So, BCN clouds can use priority bits to distinguish the
traffic that is BCN capable.  Does this mean that these bits
are over-loaded, or does a BCN cloud actually have a higher
priority in the original sense of the priority bits?

	In any case, it would still seem that it is quite easy
to distinguish BCN cloud traffic from non-BCN cloud traffic.
What would be the point of having all traffic in a network at
the same elevated priority?  Hence some subset of devices are
actually going to be able to consume BCNs.

	As a point of curiosity, how do the makers of BCN cloud
edge devices feel about the fact that the makers of BCN cloud
core switches have successfully "passed the buck" on the task 
of handling non-BCN compatible devices to the edge devices?

--
Eric

--> -----Original Message-----
--> From: Wadekar, Manoj K [mailto:manoj.k.wadekar at intel.com] 
--> Sent: Friday, October 27, 2006 2:56 PM
--> To: Gray, Eric
--> Cc: rbridge at postel.org
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> 
--> Hi Gary,
--> 
--> 	"BCN-compliant-cloud" has edges that may connect to
--> non-compliant End Station )ES or non-compliant switches. So, it is
--> possible that core can generate BCN that go towards edge of such a
--> cloud. In this case, edge of the cloud provides appropriate 
--> termination of BCN (and RLT tags in the data frames). 
--> 	BCNs don't necessarily get "dropped" at such an edge switch. In
--> case where this edge connects to a non-compliant ES, edge switch may
--> perform rate control on behalf of such non-compliant ES. 
--> So, the edge switches are consuming the BCNs and not dropping them.
--> 
--> 	So, core switches do not make the decisions about to whom they
--> are sending BCNs - they can't. They just don't have that 
--> information.
--> (Only edges know that).
--> 
--> 	About BCNs and VLANs:
--> 	
--> 	Just to make sure that I am in sync with terminology: By VLAN -
--> we are discussing vid (12 bits from VLAN tag) and not 
--> priority bits (3
--> bits from same VLAN tag). 
--> 	
--> 	Traffic in data center will be separated for different classes -
--> ones that use BCN and ones that don't. But they are 
--> differentiated with
--> priority bits and not by vids. One can't limit 
--> "BCN-compliant traffic"
--> only to certain VLANs - because it is possible that from 
--> server - I will
--> have traffic of both the types. (E.g. LAN traffic going 
--> towards WAN -
--> does not need BCN, but storage traffic within DC - needs BCN).
--> 
--> 	Please let me know if this is clear - or I can start drawing
--> pictures or forward link with discussion. (My wording may 
--> be confusing
--> ..)
--> 
--> Thanks,
--> - Manoj
--> 
--> -----Original Message-----
--> From: Gray, Eric [mailto:Eric.Gray at marconi.com] 
--> Sent: Friday, October 27, 2006 11:27 AM
--> To: Wadekar, Manoj K; Gray, Eric
--> Cc: rbridge at postel.org
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> 
--> Manoj,
--> 
--> 	A BCN notification sent to a non-BCN supporting end-station
--> is "junk traffic" - is it not?  Such an end-station will - at best
--> - simply ignore the extra traffic, and the switch will just end up
--> sending more "junk traffic" to that end-station.
--> 
--> 	A switch that sends junk traffic to end stations is not the
--> most useful of devices.  Hence it was suggested earlier (I don't
--> recall who suggested it) that BCN capable devices would nost likely
--> share common VLANs such that:
--> 
--> 	1) the aggregate of all BCN supporting devices can be protected
--> 	from non BCN supporting devices by protecting the bandwidth of
--> 	the BCN-VLAN(s);
--> 
--> 	2) BCN notifications only get sent to BCN capable devices.
--> 
--> Using this approach, a switch only needs to be configurable on a
--> per-VLAN basis to use, or not use, BCN.
--> 
--> --
--> Eric
--> 
--> --> -----Original Message-----
--> --> From: Wadekar, Manoj K [mailto:manoj.k.wadekar at intel.com] 
--> --> Sent: Friday, October 27, 2006 1:54 PM
--> --> To: Gray, Eric
--> --> Cc: rbridge at postel.org
--> --> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> --> 
--> --> Hi Eric,
--> --> 
--> --> 	(My apologies for being slow in my responses..)
--> --> 	
--> --> 	I did not understand your comment about: " you 
--> have to be
--> --> careful not to send BCN messages to those end-stations 
--> that don't
--> --> support them." Can you please clarify? 
--> --> 
--> --> 	Switches do not have knowledge of which end 
--> stations support
--> --> BCNs and which do not. 
--> --> 
--> --> 	Have I missed your point?
--> --> 
--> --> Thanks,
--> --> - Manoj
--> --> 	
--> --> -----Original Message-----
--> --> From: Gray, Eric [mailto:Eric.Gray at marconi.com] 
--> --> Sent: Friday, October 27, 2006 8:44 AM
--> --> To: Wadekar, Manoj K
--> --> Cc: rbridge at postel.org
--> --> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> --> 
--> --> Manoj,
--> --> 
--> --> 	Once again, the assumption that cores do not 
--> retain "addresses
--> --> of
--> --> all the end-stations in [the] whole cluster" is a "convenient
--> --> assumption"
--> --> for making the argument that another mechanism is required.
--> --> 
--> --> 	Currently, there would be no requirement for 
--> retaining all such 
--> --> addresses as you have to be careful not to send BCN 
--> --> messages to those
--> --> end-stations that don't support them.  Moreover, as mentioned
--> --> previously,
--> --> it is trivially easy to determine what address 
--> information should be
--> --> kept.
--> --> 
--> --> --
--> --> Eric
--> --> 
--> --> --> -----Original Message-----
--> --> --> From: rbridge-bounces at postel.org 
--> --> --> [mailto:rbridge-bounces at postel.org] On Behalf Of 
--> --> Wadekar, Manoj K
--> --> --> Sent: Friday, October 27, 2006 11:21 AM
--> --> --> To: rbridge at postel.org
--> --> --> Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> --> --> 
--> --> --> Yes, for large clusters, if cores do not maintain addresses 
--> --> --> of all the
--> --> --> end-stations in whole cluster - then only way to get BCN 
--> --> --> back to ES, is
--> --> --> to send them to ingress rbridge-address and then have 
--> --> that ingress
--> --> --> rbridge forward BCN to end station with appropriate 
--> ES address.
--> --> --> 
--> --> --> If so, ingress rbdridge address seems to be 
--> requirement to me.
--> --> --> 
--> --> --> Thanks,
--> --> --> - Manoj
--> --> --> 
--> --> --> -----Original Message-----
--> --> --> From: Silvano Gai [mailto:sgai at nuovasystems.com] 
--> --> --> Sent: Friday, October 27, 2006 8:00 AM
--> --> --> To: Radia.Perlman at sun.com; Wadekar, Manoj K
--> --> --> Cc: rbridge at postel.org
--> --> --> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> --> --> 
--> --> --> 
--> --> --> If the congestion is detected in the core of the TRILL 
--> --> --> network, how do
--> --> --> you signal back to the source host if you don't know 
--> --> which is the
--> --> --> ingresss RBridge? 
--> --> --> 
--> --> --> You cannot look-up the inner MAC address, because in 
--> --> the core of the
--> --> --> network you don't keep the inner MAC addresses in the 
--> --> --> table. Correct?
--> --> --> 
--> --> --> This is a clear reason while you need the ingress 
--> --> RBridge address.
--> --> --> 
--> --> --> -- Silvano
--> --> --> 
--> --> --> > -----Original Message-----
--> --> --> > From: rbridge-bounces at postel.org 
--> --> --> [mailto:rbridge-bounces at postel.org]
--> --> --> On
--> --> --> > Behalf Of Radia.Perlman at sun.com
--> --> --> > Sent: Thursday, October 26, 2006 5:02 PM
--> --> --> > To: Wadekar, Manoj K
--> --> --> > Cc: rbridge at postel.org
--> --> --> > Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> --> --> > 
--> --> --> > Hi Manoj,
--> --> --> > 
--> --> --> > I'm confused about BCN. Wouldn't congestion notification 
--> --> --> need to go to
--> --> --> the
--> --> --> > original endnode source,
--> --> --> > and not the ingress RBridge?
--> --> --> > 
--> --> --> > Radia
--> --> --> > 
--> --> --> 
--> --> --> _______________________________________________
--> --> --> rbridge mailing list
--> --> --> rbridge at postel.org
--> --> --> http://mailman.postel.org/mailman/listinfo/rbridge
--> --> --> 
--> --> 
-->