[rbridge] it's time to summarize things

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

See below...

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

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

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

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

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

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDofZUE5f5cImnZrsRAoqGAJ9DQh5vm4a65UWW3Kz0IbMrGmljAQCgu6x8
bQU89YnqNLFMFmK/i5L8ChE=
=vi82
-----END PGP SIGNATURE-----