Radia.Perlman at Sun.COM
Fri Apr 8 14:34:32 PDT 2005
Michael Smith said:
>>Rbridging will reorder during a stable topology. The reordering in
>>rbridges happens when learning occurs. This is independent of topology
To explain to the technical point you are raising to the llist (because it's
not really a change to the minutes, but is instead a technical point
be discussed on the list), the strawman draft design does have that
property, because when endnode A
talks to endnode B, if the RBridges do not yet know where B is, they
will send it on
a spanning tree, and when they do find out who the egress RBridge is,
they will send it directly.
A variant that has been discussed is to use the link state information
to calculate a per-ingress
RBridge spanning tree. Then all the paths will be optimal (except during
topology change). But of course it is more expensive
to calculate all those trees. So it's an engineering tradeoff. MOSPF
spanning trees, by the way.
All this stuff is an engineering tradeoff, so we shouldn't necessarily
assume one thing is
cast in stone if we find out it precludes other good properties. I asked
still depend on in-order delivery, and it didn't seem like a lot of them
do. And in the
installations with SNA or whatever legacy protocols we're talking about,
forced to use RBridges...they could stick with standard bridges.
I'd hope modern protocols are not being designed that would break if
And if it's OK to sometimes reorder (when topology changes), then I'd
think it couldn't
be fatal to reorder at other times too.
So, could someone list the protocols that break with reordering, and how
deployed they are, and whether they need the features of RBridge, or are
fine with bridges?
If they are important, AND if they need the features of RBridges rather than
bridges, then RBridges could send unknown destination frames to
a spanning tree rooted at the ingress RBridge, and that would solve the
The question again is, are these protocols worth the cost of computing
all these extra trees?
On the upside if it's considered important enough to do all these trees,
the cost of the extra trees is totally internal to the RBridge (computation,
extra forwarding tables).
And on another upside of the extra trees...for multicast packets for
applications (which will usually be IP multicast applications, so will
be using IGMP),
having per-ingress RBridge trees, plus pruning based on IGMP snooping,
the number of packet-hops necessary to distribute that data.
More information about the rbridge