Subject: [rbridge] PS Issue #11

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Thu, 8 Dec 2005 13:16:58 -0500

--> 
--> #11 internal/external, inside/outside terminology
-->     there is one objection to these terms as topological;
-->     the draft intends to define them sufficiently
-->     does this need to be addressed further?

This is not a Problem Statement Issue because these terms are
defined in draft-touch-trill-rbridge-arch, rather than in
draft-touch-trill-prob.  Consequently, this is an issue with
the Architectural document, if not precisely an architectural
issue.

The draft definitions are not sufficiently clear on the current 
iteration.

The definitions offered there were - 

-> o  External (to a campus): describes communication on the non-rbridge 
->    components of an Ethernet link subnet, notably not between 
->    rbridges or between non-rbridges and rbridges. 
->
-> ... [snip] ...
-> 
-> o  Internal (to a campus): describes communication between rbridge 
->    devices; this communication may traverse external devices, but is 
->    still considered internal. 

Clearer wording was suggested on this list some time ago.

External links/interfaces are those that do not connect to a
cooperating RBridge; internal links/interfaces are those that
do.  Whether or not non-Bridge devices exist on - or are part 
of - a link between cooperating RBridges is irrelevant.  The
existing attempt to somehow include the possibility of other
devices as part of a link between RBridges in the definition
of internal and external is only confusing.

I believe that the confusion stems from an attempt to allow
for required communications between RBridges and other types
of devices.  This confusion is one strong indication of why
no such communications should be required.

--
Eric

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 08 Dec 2005 14:16:30 -0800

> the Architectural document, if not precisely an architectural

Yup - needs to be moved to the other doc. Let's call this ARCH issue #6
then (see header).

> ->    rbridges or between non-rbridges and rbridges.

The last part is a bug i.e., 'or between non-rbridges and rbridges'. It
should be omitted.

The previous proposal had problems:

> do. 

what does "connect" mean?
	a) physically connect (probably not)
	b) attached to the same bridged segment (won't work - see below)
	b) communicate directly
		(that's the spirit of what I ended up using)

what is being connected?
	the above lists only one end ('to a cooperating rbridge')

why is 'cooperating' required?

Consider the following (all rbridge and bridges shown; hosts connect to
all devices):

               r1----r2------b1
               |     |       |
               |     |       |
               r3----r4------b2

is r2-b1 internal or external?

I would think it is external, since the HELLO would prevent a tunnel
being created on r2-b1-b2-r4

However, this definition makes them internal.

In particular, this definition makes all links/interfaces internal if
they connect to an 'external' bridged segment that reconnects to the
rbridge elsewhere.

> Whether or not non-Bridge devices exist on - or are part 

Rbridges need to talk to bridges at some point; otherwise there's no
ingress or egress ;-)

Joe