[rbridge] Ingress Rbridge address and BCN
Gray, Eric
Eric.Gray at marconi.com
Fri Oct 27 12:59:36 PDT 2006
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
--> --> --> -->
--> --> -->
--> -->
-->
More information about the rbridge
mailing list