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

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 27 Oct 2006 18:20:26 -0400

Larry,

	A slower look up may be okay for exception processing.

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

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Fri, 27 Oct 2006 15:53:19 -0700

rbridge-bounces at postel.org wrote:
> 	BCNs should be required far less often than frames are
> being forwarded.
> 
> 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 RBridge tunnel encapsulation and forwarding it to (at
> least) the ingress RBridge from which it was introduced.
> 

When the RBridge generating the BCN is a core rbridge, i.e.
neither the ingress or egress rbridge for the instigating
frame, it is highly likely that this will be the first
unencapsulated frame for this destination in some time.

Unless a special accomodation is made in the shim header
it will not know the ingress RBridge, only the *prior*
RBridge. While that will *probably* be the ingress RBridge
there is certainly no guarantee of that.

If you forward the BCN to the *prior* rbridge, and that
rbridge also has no idea where the ultimate destination
of the BCN is, it will ultimately be forced to do
rbridge encapsultion for an unknown destination, which
means that the BCN could end up being flooded.

This is obviously undesirable. The real debate is whether
this is a minor statistical nuisance or a major problem.