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

[Silvano Gai]

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