[rbridge] PS Issue #11 -> now ARCH issue #6

[Erik Nordmark]

Joe Touch wrote:

> Internal/external as used in the PS doc is specific to protocols
> 'inside' the solution. It is not used the same way in the arch document
> (internal/external interfaces).
> 
> That difference needs to be made more clear.


Or maybe not. Having two different definitions of internal and external 
in different documents doesn't improve comprehension.

Do we even need any such terms? If not, then we can get rid of any 
confusion by just deleting the terms. Where are the terms actually used 
and useful?

A rbridge device will be capable of interaction with end nodes (station) 
on any interface, by sending and receiving non-encapsulated frames. And 
in general it must assume that an end node can exist on any of its 
interfaces, since there can be hubs.
A rbridge device will also be capable of interaction with other rbridges 
on any interface, as part of some rbridge discovery/hello mechanism as 
well as sending and receiving encapsulate frames.

Also, the rbridges in a campus create an overlay topology through their 
operation.

But I'm pretty sure we can describe all this without needing any 
"internal" or "external" terms.


Later you wrote:
> The issue isn't that the meaning is hard to understand; the issue is
> that the term is inaccurate. Hosts can - and will - sit on that
> interface. I was trying to reserve internal/external for a distinction
> between traffic between rbridges and traffic from ingress/egress to
> hosts - where inside/outside meant 'inside the campus' (invisible to
> hosts) and 'outside to the hosts' (visible to hosts).

This is the distinction between encapsulated and non-encapsulated 
frames, right?


    Erik