[rbridge] it's time to summarize things
Radia.Perlman at Sun.COM
Wed Dec 14 22:02:01 PST 2005
Joe Touch wrote On 12/14/05 21:33,:
> Routers terminate L2 broadcasts. Rbridges cannot. Routers decrement L3
> TTLs. Rbridges cannot. So the assertion that an rbridge campus should
> drop BPDUs - just like routers - doesn't follow.
I really don't understand what you're saying. RBridges can
terminate some L2 broadcasts, in particular, spanning tree messages.
True, RBridges will not decrement L3 TTLs.
And perhaps the assertion that RBridges should drop BPDUs does not
follow from the previous two sentences, but regardless, they
should drop BPDUs because that's what works, that's what is
simple, that's what makes the combination of bridging and RBridging
more robust than bridging alone, that's what preserves transparency
to layer 3 and yet increases robustness.
> So at the very least we need to explain the reason for this behavior
> more clearly, in a way that does not refer to routers as equivalent.
Hopefully the above explains why it has to work this way. We want
to break up the spanning tree into smaller and smaller spanning
trees, hopefully eventually getting rid of them entirely and
just having one big link state routed zero configuration infrastructure.
> AFAICT, having an rbridge campus drop BPDUs makes sense only by
> effectively considering the rbridge campus as the root of all trees, but
> that presumes it is always _the_ root (that there is only one 'drops
> BPDU' system per bridged LAN). Since there's no way to enforce that
> assertion, it seems problematic.
The above paragraph makes absolutely no sense to me.
Routers drop spanning tree messages, and the world winds up with
lots of isolated spanning trees. The same thing happens with
RBridges. If there were a problem with doing it this way,
IP mixed with bridges would not work.
More information about the rbridge