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

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Thu, 05 Jan 2006 15:39:16 -0800

Joe Touch wrote:

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

FWIW I'm confused each time I see an argument that uses "inside" and 
"outside" in the context of rbridges.

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

I took a look, and it looks quite easy to remove them (and the use of 
"internal" and "external" in arch). For instance, "internal traffic" 
should just be replaced with "encapsulated traffic".

If we do this, we can also remove the (in my mind) confusing statements like
  this communication may traverse external devices, but is
       still considered internal.
and avoid the artificial splitting in figure 3 in arch of the r7-b8-r9
path into an external and an internal path; this is merely a path which 
carries both encapsulated and non-encapsulated frames. (And in fact, all 
paths will carry non-encapsulated frames during flooding to find an 
unknown destination.)

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

I don't think "internal routing protocol" or "external to the solution" 
is per-see problematic, but the former can be replaced by "the rbridge 
link-state routing protocol", which can be shortened to "the rbridge 
routing protocol" or even "the routing protocol" when the rest is clear 
from the context.

What I do find confusing are the notions of inside/internal and 
outside/external:
  - ports/links/topology
  - traffic
  - campus (FWIW I view the campus as the thing which includes the 
hosts, bridges, etc; but the arch document presents the campus as 
something which is just the rbridges and some subset of the connectivity 
between the rbridges - I can't tell for sure what's viewed as part of it)

    Erik