Subject: [rbridge] Ingress Rbridge address and BCN - 1st Issue

From: manoj.k.wadekar at intel.com (Wadekar, Manoj K)
Date: Mon, 6 Nov 2006 11:33:07 -0800

Hi Eric,

	BCN has been defined to work on the data center networks with
short range networks (in meters, not kilometers). Network latency is
definitely significant factor in the analysis for BCN. 

	Current analysis showed stability of solution for networks with
control loop delay of < 1mS. (This includes delay at the end nodes,
links as well as switch forwarding delays). 

	We can discuss details of BCN protocol and any concerns you may
have tomorrow in SD. I will be happy to share due diligence done on BCN.

Thanks,
-Manoj
-----Original Message-----
From: Silvano Gai [mailto:sgai at nuovasystems.com] 
Sent: Sunday, November 05, 2006 10:33 AM
To: Gray, Eric; Larry Kreeger (kreeger); Wadekar, Manoj K; Davide
Bergamasco (davide)
Cc: rbridge at postel.org
Subject: RE: [rbridge] Ingress Rbridge address and BCN - 1st Issue

Eric,

I am OK to have this discussion, I understand BCN at the system level,
but I am not a control theory guy or a congestion management geek.

Two engineers that know BCN very well and that can contribute to the
discussion are:
Manoj K Wadekar <manoj.k.wadekar at intel.com> and
Davide Bergamasco <davide at cisco.com>
I'll recommend we include them in the discussion.

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> Sent: Sunday, November 05, 2006 10:25 AM
> To: Silvano Gai; Larry Kreeger (kreeger)
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] Ingress Rbridge address and BCN - 1st Issue
> 
> Silvano,
> 
> 	We should probably have some discussion - perhaps off line -
> about how BCN actually works.
> 
> 	For one thing, from what I've heard so far, I have some doubts
> about it working in real networks at all.  That might be addressed by
> taking the time to read the actual BCN specifications in detail and -
> if I were in  a position of having a lot of free time, or under some
> direct pressure from customers to support BCN - I would do that.  So
> far, I have heard that some people have some customers that want BCN
> support (whatever that actually means) and it is hard for me to drop
> something else on so thin a basis.
> 
> 	And it seems likely - based on what people are saying - that our
> taking the time to figure out how BCN "works" might be a waste of
time.
> 
> 	For one thing, your observation about the need for fast feedback
> mechanisms (that appear to be supported by protocol analysis that has
> been performed by someone at least) tends to argue that this technique
> was not designed with real networks in mind.
> 
> 	Delay is a big part of the nature of networks.  Hence realistic
> feedback mechanisms need not only to take into account the fact that
> delay is absolutely unavoidable, but they need to have "knobs" that
> can be adjusted to allow for the mechanism to adapt to different
delays
> in different networks.
> 
> 	The way I am hearing BCN described, it seems as if it has "hard"
> delay bounds and that is a problem - IMO - with the design of BCN.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:sgai at nuovasystems.com]
> --> Sent: Saturday, October 28, 2006 11:16 AM
> --> To: Gray, Eric; Larry Kreeger (kreeger)
> --> Cc: rbridge at postel.org
> --> Subject: RE: [rbridge] Ingress Rbridge address and BCN - 1st Issue
> -->
> --> Eric,
> -->
> --> > -----Original Message-----
> --> > From: rbridge-bounces at postel.org
> --> [mailto:rbridge-bounces at postel.org]
> --> On
> --> > Behalf Of Gray, Eric
> --> > Sent: Friday, October 27, 2006 3:20 PM
> --> > To: Larry Kreeger (kreeger)
> --> > Cc: rbridge at postel.org
> --> > Subject: Re: [rbridge] Ingress Rbridge address and BCN - 1st
Issue
> --> >
> --> > Larry,
> --> >
> --> > 	A slower look up may be okay for exception processing.
> -->
> -->
> --> The BCN closed loop control algorithm requires timely
> --> replies done in
> --> HW. We can ask BCN experts which is the amount of delay that can
be
> --> tolerate, but if I remember correctly the stability
> --> analysis, it was not
> --> much.
> -->
> --> -- Silvano
> -->
> -->
> --> >
> --> > 	BCNs should be required far less often than frames are
being
> --> > forwarded.
> --> >
> --> > 	Having a transit RBridge "look inside [at?] the inner
MAC"
> --> > is not what is effectively happening - as I understand it - when
> --> > a "core RBridge" is generating a BCN.  BCN-capable core RBridges
> --> > would presumably copy the header information from some subset of
> --> > the frames on a minimally-congested link, strip the tunneling
> --> > encapsulation and originate a new frame containing a
Notification
> --> > (BCN) message.
> --> >
> --> > 	This must be a new frame, as opposed to a reflection of
the
> --> > original frame, so it is interesting that people assume this is
a
> --> > trivial operation in hardware in the first place.
> --> >
> --> > 	Since the BCN-capable RBridge has to "flip" the MAC SA
into
> --> > a MAC DA in a BCN anyway, it MUST look at that part of the frame
> --> > in every case before it can generate a BCN.
> --> >
> --> > 	In effect, the frame is (partially) copied, the copied
> --> > information is locally terminated and used to originate a new
> --> > message.  This message would then be sent - presumably using
> --> > the usual means for message origination - by encapsulating it
> --> > in RBridge tunnel encapsulation and forwarding it to (at least)
> --> > the ingress RBridge from which it was introduced.
> --> >
> --> > 	That is not nearly as much of a confusion of layers as
it
> --> > is to 1) assume that the frame is munged in hardware and turned
> --> > around and 2) normal processing of originated local messages is
> --> > bypassed in an attempt to optimize BCN sending at the cost of
> --> > including additional information in _every_ frame.
> --> >
> --> > 	Oh, and, apparently I can blame you for trying... :-)
> --> >
> --> > --
> --> > Eric
> --> >
> --> > --> -----Original Message-----
> --> > --> From: Larry Kreeger (kreeger) [mailto:kreeger at cisco.com]
> --> > --> Sent: Friday, October 27, 2006 5:26 PM
> --> > --> To: Gray, Eric
> --> > --> Cc: rbridge at postel.org
> --> > --> Subject: RE: [rbridge] Ingress Rbridge address and
> --> BCN - 1st Issue
> --> > -->
> --> > --> Gray, Eric wrote on Friday, October 27, 2006 11:33 AM:
> --> > -->
> --> > --> > Larry,
> --> > --> >
> --> > --> > 	Separating these issues...
> --> > --> >
> --> > --> > -- [SNIP] --
> --> > --> > -->
> --> > --> > --> Please correct me if I incorrectly summarize the
above.
> --> > --> > -->
> --> > --> > --> 1) Scaling the number of fowarding entries in the
> --> > --> core is not a
> --> > --> > --> problem that TRILL needs to solve.
> --> > --> >
> --> > --> > While this is a possible intrepretation, it is not
> --> an accurate
> --> > --> > characterization of what I said.
> --> > --> >
> --> > --> > I'll try again, starting with what you have said.
> --> > --> >
> --> > --> > Scaling of the number of forwarding entries in the
> --> core is not a
> --> > --> > problem that the TRILL working group has decided to solve.
> --> > --> >
> --> > --> > Hence, you might conclude that the TRILL working group
> --> > --> has passively
> --> > --> > decided that this is not a problem that TRILL needs
> --> to solve.
> --> > --> >
> --> > --> > One reason why this might be the case is that people
> --> > --> could not decide
> --> > --> > the "by how much" question.
> --> > --> >
> --> > --> > Never-the-less, an implicit requirement that the solution
> --> > --> should not
> --> > --> > prevent more scalable implementations, enables people who
> --> > --> might not
> --> > --> > be able to agree in public (as to what factor of increased
> --> > --> > scalability should apply) to produce and deploy solutions
> --> > --> that are in
> --> > --> > fact more scalable, by at least some amount.
> --> > --> >
> --> > --> > --> 2) Link utilization is a problem and TRILL needs to
> --> > --> be concerned
> --> > --> > --> with it.
> --> > --> >
> --> > --> > Certainly.
> --> > --> >
> --> > --> > -->
> --> > --> > --> If this is correct, it leads me to believe that you
> --> > --> would advocate
> --> > --> > --> for
> --> > --> > --> 1) Remove the destination RBridge from the shim, and
> --> > --> just lookup
> --> > --> > the
> --> > --> > --> destination MAC directly
> --> > --> >
> --> > --> > How do you arrive at this conclusion?  There are
> --> > --> scenarios where this
> --> > --> > might be done, but clearly the use of a smaller field for
> --> > --> a look-up
> --> > --> > is traditionally viewed as likely to be quicker.
> --> > -->
> --> > --> I appologize for trying to put words in you mouth, but I am
> --> > --> trying to
> --> > --> understand what you are arguing for...and after
> --> reading the above,
> --> I
> --> > --> still don't know.  Maybe it is because I am confusing
> --> what you are
> --> > --> personally saying versus what you are echoing from others
> --> > --> in the group.
> --> > --> Do you believe we need the RBridge Id in the shim or not?
> --> > --> If you do,
> --> > --> then why?  For a quicker lookup?  If so, then why would a
> --> > --> slower lookup
> --> > --> to generate the source RBridge for BCN be acceptable?
> --> > -->
> --> > --> >
> --> > --> > --> 2) Eliminate the need for the outer MAC header
> --> between two
> --> > --> > RBridges
> --> > --> > --> if the link is point to point (quite likely in
> --> my opinion).
> --> > --> >
> --> > --> > Ultimately, point-to-point is very likely, but we have to
> --> > --> deal with
> --> > --> > the step-by-step deployment scenarios.
> --> > --> >
> --> > --> > In any case, I do not advocate special-casing
> --> > --> encapsulation based on
> --> > --> > link types in general - beyond that already required by
> --> > --> the specific
> --> > --> > link.  As I thought would be obvious by now, I advocate
> --> functional
> --> > --> > separation - which works better if you don't build in a
> --> > --> lot of layer
> --> > --> > dependencies.
> --> > -->
> --> > --> I agree with you about building in a lot of layer
> --> > --> dependencies.  Having
> --> > --> transit RBridges look inside the inner MAC seems like a
> --> > --> layer dependency
> --> > --> to me.  Not encapsulating with an extra 14 to 18 bytes on
> --> > --> point to point
> --> > --> link seems like it would be well worth it if you are
> --> > --> concerned with link
> --> > --> overhead.  I would gladly trade 14/18 bytes of overhead for
> --> > --> another 2
> --> > --> bytes of source RBridge which will help with BCN as well as
> --> > --> help with
> --> > --> network troubleshooting.
> --> > -->
> --> > --> >
> --> > --> > -->
> --> > --> > --> Again, I apologize for not keeping up with the latest
> --> > --> discussions,
> --> > --> > --> but have these ideas been discussed already?
> --> If so, could
> --> you
> --> > --> > --> summarize the outcome?
> --> > --> >
> --> > --> > This is not a reasonable request.
> --> > -->
> --> > --> Oh well, cant' blame me for trying can you? ;-)
> --> > -->
> --> > --> >
> --> > --> > -- [SNIP] --
> --> > -->
> --> > _______________________________________________
> --> > rbridge mailing list
> --> > rbridge at postel.org
> --> > http://mailman.postel.org/mailman/listinfo/rbridge
> -->