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

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 9 Dec 2005 12:39:43 -0500

Joe,

	See even more comments embedded below...

--
Eric 

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch
--> Sent: Thursday, December 08, 2005 5:17 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] PS Issue #11 -> now ARCH issue #6
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> 
--> 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
--> > issue.
--> 
--> Yup - needs to be moved to the other doc. Let's call this ARCH issue #6
--> then (see header).

In this case, the PS/ARCH issue is that definitions need
to be moved to the PS document, from the ARCH document.

Issues relating to the specific definitions are issues for
whatever document they are currently in.

--> 
--> > 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.
--> 
--> The last part is a bug i.e., 'or between non-rbridges and rbridges'. It
--> should be omitted.

The entire statement is hard to parse, even if we were
to agree that this is basically what we want to say.  We
are not agreed, at this point, but a better way to say
what I think you are trying to say is:

o  External (to a campus): describes communication between non-rbridge
   components of an Ethernet subnet.

As I have said numerous times, I have problems with your 
definition, but - even if the WG were to decide to adopt
it - it is not necessary to make it hard to understand by
decorating it with redundancy...

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

Which were?  The only indication I have seen that 
there were "problems" is in the way that the present
definition has simply refused to get better.

Why not be more specific?

--> 
--> > External links/interfaces are those that do not connect to a
--> > cooperating RBridge; internal links/interfaces are those that
--> > do. 
--> 
--> what does "connect" mean?
--> 	a) physically connect (probably not)

Although, actually, yes in a subset of cases.

--> 	b) attached to the same bridged segment (won't work - see below)

And this is the rest of the cases.  I will address your 
issues below.

--> 	b) communicate directly
--> 		(that's the spirit of what I ended up using)

What does "communicate" mean?  Do they gossip among themselves?
Are they mutual participants in RBridge protocols exchanges, or
is it sufficient that they pass data in common?  If they are 
mutual participants, are they "connected" by some media that we 
have determined is "in-scope" for TRILL, or does any connection
count?

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

"Connected" and "being connected" are obviously synonymous.

Kind of like "picky" and "being picky" :-)

--> 
--> why is 'cooperating' required?

This is not a new term.  It was introduced weeks (months?) 
ago when we were talking about the meaning of "internal"
and "external".  It is possible to have multiple RBridge
"campi" if the RBridges between them are configured not
to cooperate with each other in hello/discovery protocol.

In such a case, and assuming STP blocking, the separate 
campi simply do not see each other, even though they are
"connected" via some media, and "communicate" at the data
plane level just fine.

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

Huh?  Absolutely not true.  Although it is interesting that 
you're assuming that "tunnels" are created.

The path - which could become a tunnel if frames are transported
over it using RBridge-to-Rbridge encapsulation - r2-b1-b2-r4 is
simply and obviously not a preferred path.  Should it become the
preferred path, then it will obviously be used to tunnel frames
between r2 and r4.  Why would we want to assume that another link 
going away between r2 and r4 would suddenly make r2-b1-b2-r4 into
an internal communication (path) or connection?  Let's not confuse
the terms "internal" and "preferred."

If that _is_ what it means, then it is not a particularly useful
term...

--> 
--> However, this definition makes them internal.

And, so they are.

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

Brilliant!  And, of course, absolutely true.  It would be nice
if this meant we are in agreement - but I believe I detect a
small bit of irony in your use of single quotes above.

This happens to be exactly what you convinced me of when last 
we had this discussion.  Note, you convinced me!

Take - for example - the below figure:

 ---> rb1 <---> rb2 <---> b1 <----> b2 <---> rb3 <---> rb4 <---
       |         |         |        |         |         |
       +-> rb5 <-+         +-> b3 <-+         +-> rb6 <-+

Earlier, you persuaded me that - as long as rb2 and rb3 are 
connected, and not configured to ignore each other - (rb1, rb2, rb5)
and (rb3, rb4, rb6) are not separate RBridge campi but are instead
a single RBridge campus.  This, you argued is true because the fact
that rb2 and rb3 are connected (and communicating control protocol)
to each other makes the "link" between rb2 and rb3 "internal".

Now, take this picture and modify it as shown below:

 ---> rb1 <---> rb2 <---> b1 <----> b2 <---> rb3 <---> rb4 <---
       |         |         |        |         |         |
       +-> rb5 <-+         +-> b3 <-+         +-> rb6 <-+
            |                  |
            +------> b4 <------+

The new link, rb5-b4-b3-b2-rb3, is also an internal connection.
If, for example, the physical connection rb2<->b1 were to go 
down, that link (rb5-b4-b3-b2-rb3) would be the only internal
connection between rb2 and rb3.

Similarly, the new link in the above picture - rb5-b4-b3-b1-rb2
- is also an internal connection.  If we were to subsequently
lose the (apparently unrelated) connection b2<->rb3, would the
link rb5-b4-b3-b1-rb2 suddenly become an external link?

It was arguments along this line that originally caused me to
understand your assertion that you could not normally have two
or more RBridge campi in the same broadcast domain.

Have you forgotten your own arguments?

--> 
--> > 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 ;-)

"Talk to" is, I presume, synonymous with "communicate."

There is a clear distinction between data-plane and control
plane communication.

Once we are in agreement that "internal" and "external" are
"topological" constructs, then it should be a simple step to
agree that an "ingress" is how you get from "external" to 
"internal" and an "egress" is how you get from "internal"
to "external".  

We don't need to try to make this harder than it is, abusing
common usage of very well understood terminology.

--> 
--> Joe
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.2.4 (MingW32)
--> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
--> 
--> iD8DBQFDmLC+E5f5cImnZrsRAlXZAKCJZsBCaNsffdCBZThm+9Ca6WLxPwCfbdXV
--> 5KCUBeCNg2oelTukVeU1mMA=
--> =PF20
--> -----END PGP SIGNATURE-----
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 09 Dec 2005 10:30:47 -0800

See below.

> Gray, Eric wrote:
>> 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
>>> issue.
>> 
>> Yup - needs to be moved to the other doc. Let's call this ARCH issue #6
>> then (see header).
> 

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.

> whatever document they are currently in.

Agreed.

>>> 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.
>> 
>> The last part is a bug i.e., 'or between non-rbridges and rbridges'. It
>> should be omitted.
>> 

The non-redundent portion is that the definition focuses on the
communication - rather than the interface.

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

I have listed the problem below.

> Why not be more specific?

Again, the problem below.

>>> External links/interfaces are those that do not connect to a
>>> cooperating RBridge; internal links/interfaces are those that
>>> do. 
>> 
>> what does "connect" mean?
>> 	a) physically connect (probably not)
>  

That is a trivial subset that we aren't defining rbridges for, so
there's no utility in focusing on that.

>> 	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?
>> 
> and "external". 

The whole point of an issues list is to have the discussion in a way
that we can refer to. I am hoping posts will enough context for that to
happen.

> It is possible to have multiple RBridge

If that's true (and I hope it is), then BLOCK is absolutely out of the
question - there's no way to avoid loops back and forth between the
campuses (campi is preferred in latin, not English ;-)

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

That's how an rbridge works - the encapsulation headers are tunnels
between ingress and egress rbridges.

> the terms "internal" and "preferred."

I use the term 'internal' for the tunnels, and external for everything
else. Otherwise, the only thing 'internal' means is 'possible path for a
tunnel' - but that's not really internal. If it's not the active path of
the traffic, it's external.

I.e., your version of 'internal' is more like 'potentially internal'.

>> However, this definition makes them internal.
>  
> And, so they are.

What is the point of calling them internal? ALL interfaces that are to
non-stub bridged segments will be internal, but they're not used for
rbridge-rbridge communication.

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

Yes - I don't see what the utility in flagging the world as internal
when they're not actually used for internal communication.

There are paths that are used for internal (rbridge-rbridge)
communication and those that are not. That seems to be what the point of
internal is.

>  ---> rb1 <---> rb2 <---> b1 <----> b2 <---> rb3 <---> rb4 <---

That discussion was before we talked about external hosts hanging off of
b1 (or b2 or b3). In that case, the link acts both internal and
external; we need to distinguish between the two uses.

>  ---> rb1 <---> rb2 <---> b1 <----> b2 <---> rb3 <---> rb4 <---

This, as well as when hosts exist on those bridges, is why interfaces
and links should not be called 'internal' IMO.

> link rb5-b4-b3-b1-rb2 suddenly become an external link?

This is again the reason internal/external should describe
communication, not links or interfaces.

> Have you forgotten your own arguments?

I have remembered the subsequent resolution of the internal/external
terms with the dual use of a bridged segment - remember? ;-)

>  
>>> 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 ;-)
>> 

There are four kinds of communication that muddy the data/control
distinction:

	- bridged segment data
	- bridged segment control (e.g., BPDUs)
	- rbridge control (non-ecapsulated HELLO, encapsulated IS-IS)
	- rbridge data (encapsulated)

IMO, the internal/external is defined by encapsulation, not data/control.

> "topological" constructs,

We are not ;-)

> then it should be a simple step to

Agreed. But how do we resolve the fact that internal/external is NOT
topological except to refer to the encapsulation headers instead?

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20051209/a46e3044/signature.bin

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Mon, 19 Dec 2005 04:01:03 -0800

> 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 
and useful?

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

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 
frames, right?

    Erik

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 19 Dec 2005 09:51:46 -0800

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

> confusion by just deleting the terms. Where are the terms actually used 

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.

> "internal" or "external" terms.

Perhaps, but why? It's clear enough from the above.

> This is the distinction between encapsulated and non-encapsulated 

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

Joe