[rbridge] Minor issue in draft-touch-trill-rbridge-arch-00a.txt

[Erik Nordmark]

Joe Touch wrote:

> You are correct that routing information might not go over tunnels, but
> I'm wondering why - the performance benefit is minimal, and by using the
> tunnels the routing protocol 'fate shares' the data paths - I thought
> that was a desirable property.
> 
> So, strictly, it's not required, but what's the benefit?

The discovery packets might be the more interesting case.
The encapsulation header includes the "next hop" as well as "final 
rbridge", and at least the last one would be useless hence potentially 
confusing for the discovery packets, since they take a single RBridge 
hop to an unknown (multicast) destination.

> We can define internal/external just as easily without discussing
> tunnels, FWIW (sorry, I lost this idea while I was writing the drafts,
> but can fix it): all internal traffic is addressed TO the rbridge's 802
> address (whether it is tunneled or not). I also didn't get to the part
> where we need to discuss how many 802 addresses an rbridge has (it may
> need one per port; I can't see how to avoid that - more in the update to
> the draft on that).

Yes, I think describing internal vs. external *traffic* (or frames) is 
useful. Basing that on the destination address is probably general enough.

But the current set of definitions try to define internal and external 
*parts of topology*, which I think adds confusion.

    Erik