Subject: [rbridge] Ingress Rbridge address and BCN

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

Sure.  Looking forward to it...  :-) 

--> -----Original Message-----
--> From: Wadekar, Manoj K [mailto:manoj.k.wadekar at intel.com] 
--> Sent: Friday, October 27, 2006 3:29 PM
--> To: Gray, Eric
--> Cc: rbridge at postel.org
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> 
--> Hi,
--> 
--> I am planning to attend San Diego meeting. Will it be 
--> easier to discuss this and more with pictures (and little 
--> background info) in front of us?
--> 
--> Thanks,
--> Manoj
--> P.S. Meanwhile I will respond to your questions Eric in a bit. 
--> 
--> Sent from my GoodLink synchronized handheld (www.good.com)
--> 
--> 
-->  -----Original Message-----
--> From: 	Gray, Eric [mailto:Eric.Gray at marconi.com]
--> Sent:	Friday, October 27, 2006 12:15 PM Pacific Standard Time
--> To:	Wadekar, Manoj K; Gray, Eric
--> Cc:	rbridge at postel.org
--> Subject:	RE: [rbridge] Ingress Rbridge address and BCN
--> 
--> 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
--> --> --> --> 
--> --> --> 
--> --> 
-->