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

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

Joe,

	We may be closer on this one too.  Again, please see
below...

--
Eric 

--> 
--> Gray, Eric wrote:
--> > Joe,
--> > 
--> > 	Taking things too litterally - so as to make them seem
--> > ridiculous - is an argument style, not a communication skill.
--> > Are we arguing to a purpose, or are we trying to communicate?
--> > 
--> > 	The phrase "like being a router" is a very far cry from 
--> > "being exactly like a router", and the phrase "the destination 
--> > is a layer 2 address rather than an IP address" implies a lot 
--> > of things about the differences between a router and an RBridge.
--> 
--> Agreed, but it has already proven useful in eliciting the idea 
--> that rbridges have external addresses that external hosts know 
--> about (which I disagree with).
--> 

I think I know how you got this interpretation out of what was
said, but it is an incorrect interpretation.

When saying "the destination is a layer 2 address rather than an IP 
address" the routing analog is fairly accurate.  That is, instead
of routing based on IP addresses, routing is based on layer 2 (MAC)
addresses.

In the same way that the IP address for the local router is usually
not used in forwarding IP traffic (unless the traffic is destined
for the router), RBridge addresses are not typically used to forward 
layer 2 traffic to non-RBridge destinations.  One key exception to
this is when forwarding traffic using tunneling encapsulation from
one RBridge to another.

Hosts in a common broadcast domain containing an RBridge campus are
not aware of the RBridge campus.  Same for routers and for routers
and hosts talking to each other.

Consequently, there is nothing to disagree with here.

--> I have been very specific about the idea of being "like a bridge" or
--> "like a hub"; it allows me to encapsulate a lot of rules about what 
--> the campus would do, w.r.t. nodes, bridges, etc.
--> 
--> If a campus is not "like" either a bridge or a hub, someone needs to
--> describe what it does - either in terms of another viable L2 analog,
--> or in terms of how it interacts with each level of protocol:
--> 
--> 	- do external nodes address traffic to the ingress?
--> 		I have been assuming NO.

That is correct.

--> 		if they do, then a lot of protocols are affected
--> 		and need modification and/or proxying.
--> 
--> 	- do external bridges address traffic to rbridges?
--> 	(basically BPDUs)
--> 		I have been assuming YES.

That is incorrect.

--> 		if not, then how do bridges know to forward
--> 		traffic to the ingresses?
--> 

The same way they always do.  That is, they learn about the
MAC addresses from traffic they see coming from the direction
of the RBridge campus, so they know to forward traffic with
a MAC DA toward the MAC SA they've learned earlier.

This is what makes the RBridge campus look like a collection
of MAC sources/sinks on a common Ethernet link.

Naturally, the process will be (as usual in 802.1 networks) 
"primed" by either by broadcast (e.g. ARP) or by flooding.

--> 		if not, then can there be broadcast storms?
-->

Certainly not worse than currently, except to the extent that
an RBridge campus enhanced broadcast domain _might_ be larger.

--> 		if not, then will broadcast be supported?
-->

Yes, of course.

--> 
--> (this is not necessarily a complete list, but it's a start; 
--> anyone want to answer it?)

Many people probably could.  What about somebody else?

--> 
--> Joe
--> 
--> > 
--> > --
--> > Eric
--> > 
--> > --> Routers do NOT propagate broadcasts at either L2 or L3.
--> > --> 
--> > --> So being an rbridge breaks broadcast, so ARP, DHCP, etc. won't
work.
--> > --> 
--> > --> Joe
--> > -->
--> > --> Gray, Eric wrote:
--> > --> Radia,
--> > -->  
--> > --> 	Very well put.
--> > --> 
--> > --> --> Being an RBridge is really like being a router, but the
--> > --> --> destination is a layer 2 address rather than an IP address.
--> > --> --> 
--> > --> --> Radia
--> > --> --> 
--> > --> 
--> > --> --
--> > --> Eric
--> > --> _______________________________________________
--> > --> rbridge mailing list
--> > --> rbridge at postel.org
--> > --> http://www.postel.org/mailman/listinfo/rbridge
--> > 
--> > --> -----Original Message-----
--> > --> From: rbridge-bounces at postel.org 
--> > --> [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch
--> > --> Sent: Thursday, December 15, 2005 11:08 AM
--> > --> To: Developing a hybrid router/bridge.
--> > --> Cc: Radia.Perlman at Sun.COM
--> > --> Subject: Re: [rbridge] it's time to summarize things
--> > --> 
--> > --> _______________________________________________
--> > --> rbridge mailing list
--> > --> rbridge at postel.org
--> > --> http://www.postel.org/mailman/listinfo/rbridge
--> > --> 
--> 
-->

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 15 Dec 2005 12:40:41 -0800

> 	We may be closer on this one too.  Again, please see

Agreed.

> Consequently, there is nothing to disagree with here.

That's good.

> --> 		I have been assuming YES.

Understood, at least assuming the BLOCK and PARTICIPATE cases. For
TRANSPARENT, this is still correct.

> "primed" by either by broadcast (e.g. ARP) or by flooding.

Agreed.

> Many people probably could.  What about somebody else?

OK - the answer to that list will help. IMO, the key for BLOCK is that
it's isomorphic to "PARTICIPATE as the root bridge" AFIACT. If not, then
what's the difference?

So far, all I can tell is that BLOCK means the campus as a whole will
"act like it's been elected root bridge" without having such an
election. That sounds unnecessarily dangerous to assume to me.

Joe

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Thu, 15 Dec 2005 14:59:02 -0600

Eric and Joe,

You guys are having a great time, but this may be a good opportunity for a 
"me, too", building towards the day when Erik tries to figure out what 
consensus looks like ...

>> --> or in terms of how it interacts with each level of protocol:

My understanding is "like a router that only has MAC addresses in its 
routing and forwarding tables".

>> --> I have been assuming NO.

I agree ("correct").

>> --> I have been assuming YES.

I agree (with "incorrect").

> TRANSPARENT, this is still correct.

I agree with this also, which is one of the things that bothers me about 
TRANSPARENT.

>> "primed" by either by broadcast (e.g. ARP) or by flooding.

I agree (with "Agreed").

>> an RBridge campus enhanced broadcast domain _might_ be larger.

Eric - is this just saying that someone may want to try for 100,000 MAC 
addresses in one RBRIDGE campus? Or did you mean more than this?

>> --> if not, then will broadcast be supported?

I agree (with "Yes, of course").

>> Many people probably could.  What about somebody else?

Hope this helps! Others?

Spencer

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 15 Dec 2005 14:02:23 -0800

> routing and forwarding tables".

Routers have other things:
	- for multipoint L2s, their interfaces have MAC addresses
	- they also have IP addresses
		even those with unnumbered (at L3) interfaces
		have a router ID number

All these addresses are externaly visible and used by nodes on the LAN
to address things TO the router's ingress.

What are the equivalent addresses here?

We already have an L2 device that works just like a router (at least
internally), lacking interface MAC addresses but possessing a node ID
MAC address - it's called a bridge. That's why I keep thinking of this
as being one large bridge. Because that's what "like a router that only
has MAC addresses in its routing and forwarding tables" _IS_. The
difference is that we're 'peeking inside' the bridge to talk about the
rbridge components and how they interconnect...

> I agree with this also, which is one of the things that bothers me about 

Presumably you would agree with the corrected version (agreed for BLOCK
and TRANSPARENT, but not PARTICIPATE)?

Joe

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Thu, 15 Dec 2005 16:23:15 -0600

"Snort"... Hilarious.

> and TRANSPARENT, but not PARTICIPATE)?

I was reading as fast as you were typing, apparently. I misread the question 
completely, so wasn't even answering the same question.

Sorry!

Spencer

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Fri, 16 Dec 2005 11:19:30 +0100

>routing and forwarding tables".
Assuming that this includes that Rbridges have lists of host MACs  
associated with every Rbridge MAC

>>>--> I have been assuming NO.
I agree

>I agree (with "incorrect").
I agree with incorrect.

>>>"primed" by either by broadcast (e.g. ARP) or by flooding.
I agree also . I would formulate like:  ".....to the ingresses? :  
According to IEEE 802.1D."

>I agree (with "Yes, of course").
Yes, of course

>>>Many people probably could.  What about somebody else?
I hope too .. :-)
Guillermo

>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

-- 
Guillermo Ib??ez
Departamento de Ingenier?a Telem?tica
Universidad Carlos III de Madrid
1.1.B.11 Colmenarejo 91-6241393
4.1.F.13 Legan?s 91-6248794

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 16 Dec 2005 07:11:20 -0800

Guillermo Ib??ez wrote:
...
> associated with every Rbridge MAC

That's described in the ARCH document - only the ingress/egress rbrodges
need such tables, called Campus Transit Tables therein (see Sec 3.3).

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/20051216/cb6975c1/signature.bin