[rbridge] PS Issue #11 -> now ARCH issue #6
touch at ISI.EDU
Mon Dec 19 09:51:46 PST 2005
-----BEGIN PGP SIGNED MESSAGE-----
Erik Nordmark wrote:
> 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
>>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.
The term 'inside' in the PS doc refers to components and protocols local
to the solution, rather than those that are visible to the rest of the
The terms 'internal interface' and 'external interface' in the ARCH doc
is consistent with the terms 'inside' and 'outside' in the PS, but is
specific to a component of the described architecture.
We can try to pick mutually exclusive adjectives throughout, but in this
case the use is consistent, and the terms sufficiently qualified
(interface) to be clear.
> 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?
Grep for them in the docs; if there's a way to get rid of them without
being too roundabout, fine. However, they've been used pervasively in
discussions of the protocols and mechanisms.
> 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.
Perhaps, but why? It's clear enough from the above.
> 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?
If we're talking about frames, yes. But what about the protocol to
manage the paths of encapsulated frames? That's unnecessarily awkward,
compared to 'internal routing protocol'.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the rbridge