[rbridge] PS Issue #11 -> now ARCH issue #6
erik.nordmark at sun.com
Mon Dec 19 04:01:03 PST 2005
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
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
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
More information about the rbridge