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

From: kreeger at cisco.com (Larry Kreeger (kreeger))
Date: Fri, 27 Oct 2006 14:26:01 -0700

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