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

From: sgai at nuovasystems.com (Silvano Gai)
Date: Sun, 5 Nov 2006 10:32:32 -0800

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
> -->