Subject: [rbridge] it's time to summarize things

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Thu, 15 Dec 2005 15:40:11 -0500

Joe,

	Please see below...

--
Eric 

--> -----Original Message-----
--> From: Joe Touch [mailto:touch at ISI.EDU] 
--> Sent: Thursday, December 15, 2005 2:02 PM
--> To: Gray, Eric
--> Cc: Radia.Perlman at Sun.COM; 'Developing a hybrid router/bridge.'
--> Subject: Re: [rbridge] it's time to summarize things
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> 
--> Gray, Eric wrote:
--> > Joe,
--> > 
--> > 	We're getting closer, maybe, on this one.  Please
--> > see below...
--> > 
--> > __
--> > Eric
--> > 
--> > --> -----Original Message-----
--> > --> From: Joe Touch [mailto:touch at ISI.EDU] 
--> > --> Sent: Thursday, December 15, 2005 12:11 PM
--> > --> To: Gray, Eric
--> > --> Cc: Radia.Perlman at Sun.COM; 'Developing a hybrid 
--> router/bridge.'
--> > --> Subject: Re: [rbridge] it's time to summarize things
--> > --> 
--> > --> 
--> > --> 
--> > --> Gray, Eric wrote:
--> > --> > Joe,
--> > --> > 
--> > --> > 	I've addressed this issue before, just as you have
--> > --> > raised it before.
--> > --> > 
--> > --> > 	Assuming that "external nodes" below refers to the
--> > --> > portions of the L2 broadcast domain that are topologically
--> > --> > outside of the RBridge campus, the RBridge campus actually
--> > --> > looks to external nodes as if it is a (possibly largish)
--> > --> > collection of L2 frame sources and sinks.
--> > --> 
--> > --> For internal traffic, sure. For ingress/egress traffic, 
--> > --> this would need to hijack ARP to work.
--> > --> 
--> > 
--> > Why?  ARP, at least the ARP I am familiar with, allows for the
--> > conversion of an IP address into a LAN-local MAC address (much
--> > the same as DNS allows for conversion of a network name into an
--> > IP address).
--> > 
--> > The RBridge campus forwards ARP - just as the local and remote 
--> > LAN segments do - and the appropriate entity (an L2 source/sink
--> > such as a router or host) responds.  Why would RBridges care
--> > about - or interfer with - ARP?
--> 
--> Because somehow the traffic from external nodes needs to arrive at
--> ingresses. Ingresses don't have (or at least don't use) external
--> addresses; the traffic from external nodes needs to arrive at ingresses
--> based on the external spanning trees, NOT based on being addressed to
--> ingresses.
--> 

You are confusing STP with bridge learning - not even close to 
the same thing.

If a bridge does not hear BPDUs on an interface, that interface
will not be put in a non-forwarding mode.  This corresponds to 
a LAN stub.

Because the bridge will not put that interface in non-forwarding
mode, it will receive broadcast and flooded frames on that link
from frame sources within and beyond the RBridge campus.

It will learn the MAC SAs from those frames and it will construct
learning database entries accordingly.  So will all the other 
bridges on the spanning tree.  Consequently, in a way so glaringly
obvious as to be perfectly clear to even the most casual observer,
the local LAN segment will learn how to forward packets across the
(invisible) RBridge campus.

--> In fact, there is NO external traffic that should ever be directed
--> at an ingress address - thus I believe that rbridge campuses do not
--> participate in ARP. That is a substantial difference from a router,
--> which DO participate in ARP.
--> 

Again, you're being to litteral.

--> Which means that the rbridge campus does NOT look like a collection of
--> sources and sinks to external devices w.r.t. ingress/egress traffic. The
--> only aspect in which rbridges DO look like conventional sources/sinks is
--> for internal traffic.
--> 

I don't follow how you arrive at this conclusion.  Perhaps you 
don't any more.

--> > --> To external nodes, the rbridge MUST act like a transit, not 
--> > --> a source or sink.
--> > -->
--> > 
--> > I think we're in agreement here.  My statement was as to how the
--> > RBridge campus "appears" to the rest of the network.  Yours is to 
--> > how an RBridge campus "acts."
--> 
--> I'm confused about the difference. If all you mean by source/sink
--> is 'traffic goes in that direction', then you're talking about
--> upstream/downstream channels, not sources or sinks. IMO, a source/sink
--> appears as a source/destination in a packet haeader, and (I now think we
--> agree) that never happens for ingress/egress traffic.
--> 

I don't follow how you arrive at this conclusion.  Perhaps you 
don't any more.

--> > Obviously the campus does not "act" like a source or sink.  If it
--> > did, it would be a gibbering black-hole.  It merely appears like
--> > a collection of sources or sinks to external nodes.
--> 
--> I'm not sure how that description is useful. Can you explain how?
-->

Hopefully I have.  I did this earlier too, and thought it
had taken, but here we are going through it again.  

I invite your attention to my E-Mail on the subject of 
"RBridge/bridge interaction", dated Fri 10/21/2005 2:59 PM.
 
--> Joe
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.2.4 (MingW32)
--> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
--> 
--> iD8DBQFDob2UE5f5cImnZrsRAsUaAJ44nwX7pA7yBDIGpwXKPtkcZA0kaACeNyeg
--> hco5aPY+Wji9vTw8f94UCnU=
--> =nqbN
--> -----END PGP SIGNATURE-----
-->

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 15 Dec 2005 15:03:48 -0800

See below...

> 	Please see below...

Spanning trees and bridge learning together (otherwise it won't get to
the ingress more than one bridge away).
...

> Again, you're being to litteral.

If we're correcting spelling, it's "literal". ;-)

The rest of this line is based on the assumption that "source/sink"
means source/destination address, which we agree it does not as you were
using it. So it seems moot - we agree, I think.
...

> "RBridge/bridge interaction", dated Fri 10/21/2005 2:59 PM.

It was Guillermo who introduced the terms source and sink in all
messages from you on that date, in his note from 10/20/2005,
Message-ID: <43588B9D.5050306 at it.uc3m.es>

In that text, the terms SOURCE/SINK were in reference to the BPDUs, not
other L2 packets to be sourced or sunk. His description there matches
more of what I consider a version of "PARTICIPATE", i.e.,:

			incoming BPDUs		outgoing BPDUs
			(to the rbridge)	(emitted by the rbridge)

BLOCK			silently sink		never source

PARTICIPATE-bridge	accept as if 1 bridge	emit as if 1 bridge
(compute what is emitted as if the entire campus is a single bridge)

PARTICIPATE-root	accept as if root	emit as if root
(Guillermo's suggestion, the one that I think BLOCK really maps to,
and which assumes election to root; I would prefer PARTICIPATE-bridge
that behaves this way ONLY if election is won)

TRANSPARENT		accept and ->		send a copy to all
						ports except the one
						the BPDU enters

Joe