[rbridge] reordering

[Radia Perlman]

Michael Smith said:

>>
>>Rbridging will reorder during a stable topology.  The reordering in
>>rbridges happens when learning occurs.  This is independent of topology
>>changes.  
>>    
>>
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 
that should
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 
calculated per-source
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 
what protocols
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, 
they're not
forced to use RBridges...they could stick with standard bridges.

I'd hope modern protocols are not being designed that would break if 
packets get
reordered.

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 
widely
deployed they are, and whether they need the features of RBridge, or are 
doing just
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 
problem.

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 
high-bandwidth
applications (which will usually be IP multicast applications, so will 
be using IGMP),
having per-ingress RBridge trees, plus pruning based on IGMP snooping, 
will minimize
the number of packet-hops necessary to distribute that data.

Radia