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

[Gray, Eric]

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.

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

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

-- [SNIP] --