[rbridge] PS Issue #11 -> now ARCH issue #6
touch at ISI.EDU
Thu Dec 8 14:16:30 PST 2005
-----BEGIN PGP SIGNED MESSAGE-----
Gray, Eric wrote:
> --> #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
Yup - needs to be moved to the other doc. Let's call this ARCH issue #6
then (see header).
> The draft definitions are not sufficiently clear on the current
> 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.
The last part is a bug i.e., 'or between non-rbridges and rbridges'. It
should be omitted.
> -> ... [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.
The previous proposal had problems:
> External links/interfaces are those that do not connect to a
> cooperating RBridge; internal links/interfaces are those that
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
| | |
| | |
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
> 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.
Rbridges need to talk to bridges at some point; otherwise there's no
ingress or egress ;-)
-----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