[rbridge] it's time to summarize things
touch at ISI.EDU
Thu Dec 15 08:02:59 PST 2005
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.
> 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
>>> 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
>> 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?
>> rbridge mailing list
>> rbridge at postel.org
> rbridge mailing list
> rbridge at postel.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20051215/7ff3e1b3/signature-0001.bin
More information about the rbridge