[rbridge] it's time to summarize things

[Joe Touch]

Radia Perlman wrote:
> Yes Spencer,
> 
> You understood my note, and I'm glad you
> agree with it. Apparently there was some confusion about
> taking the phrase "looking like a bridge" too literally.
> 
> An RBridge campus should look like a single broadcast domain
> to layer 3 devices,

L3 has two kinds of broadcast: all 1's, and subnet.

All 1's corresponds directly to an L2 broadcast domain; subnet
broadcasts are depricated so we can skip them.

> but that doesn't mean an RBridge should participate
> in spanning tree, any more
> than that if it had two token ring interfaces, that it should
> pass the token from one interface to another. (though hopefully
> this analogy won't confuse people, since a station on a
> token ring *does* have to pass the token within that ring...
> however an Ethernet endnode does NOT have to participate
> in spanning tree (nor should it), and likewise, an RBridge
> does not have to participate in spanning tree.

That logic is makes as much (or as little) sense as an rbridge
correlating to a router. Routers and hosts on L2 are L2 sources and L2
sinks. To the existing L2, external traffic transits the rbridge; the
rbridge sources and sinks no traffic to these external nodes.

> I think people were perhaps getting hung up on "layer n". Whatever
> you call it, bridges are a lower layer than RBridges, and
> RBridges are a lower layer than IP. So we could call RBridges
> layer 2.5 if we insisted on giving them a layer name.
> 
> Radia
> 
> 
> 
> Spencer Dawkins wrote On 12/14/05 21:11,:
>> Dear All (following up from Radia's note),
>>
>>
>>
>>> I just got back from a bunch of travel, and was trying to catch
>>> up on the mailing list, and it's really so long.
>>>
>>> It looks like the thread of whether RBridges participate
>>> in spanning tree popped up again. I thought that had been
>>> resolved.
>>>
>>> RBridges should NOT participate in spanning tree, which means
>>> they should DROP spanning tree messages.
>>>
>>> An RBridge should NOT merge spanning trees. It should terminate
>>> spanning trees, just like routers do.
>>
>> I believe one idea has contributed to this - the idea that an RBRIDGE campus 
>> should look like a single very large bridge at its interfaces, which implies 
>> (in at least some e-mail) that it participates in the same spanning tree on 
>> both sides.
>>
>> My apologies for cut-and-pasting, but the discussion has looked like this, 
>> in recent e-mail:
>>
>>
>>> --> > --> #1 resolve recommendations for the three modes of
>>> --> BSTP messages:
>>> --> > -->    (is this part of the PS or ARCH?)
>>> --> > --> participate
>>> --> > --> forward
>>> --> > --> block
>>> --> >
>>> --> > Block by default.  Optional configuration for forwarding and/or
>>> --> > participating MAY be allowed but SHOULD be considered sub-optimal.
>>> -->
>>> --> Forward maps to what hubs do.
>>> --> Participate maps to what bridges do.
>>
>> My understanding of Radia's note is that an RBRIDGE campus looks like one 
>> very large router at its interfaces (no spanning tree, so no spanning tree 
>> merge).
>>
>> If I am not misunderstanding Radia's note, I like this answer, because it 
>> looked like a lot of work to figure out what to do, in order to look like 
>> one very large bridge. If this is the high-order bit, things are clearer.
>>
>> Am I reading the note correctly? And do others agree?
>>
>> Spencer 
>>
>> _______________________________________________
>> rbridge mailing list
>> rbridge at postel.org
>> http://www.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge

-------------- 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/20051215/7ff3e1b3/signature-0001.bin