[rbridge] A question about (R)STP and routing protocol

[Radia Perlman]

Suping Zhai,

You are not the first person to ask these questions.
There is a lot of confusion over what is different between RSTP and STP,
and what is different between RSTP and link state routing.
I'll try to explain.

1) What's the difference between RSTP and STP?

RSTP and STP are almost identical, are compatible,
and it would be less confusing to think of RSTP as a different
version of the bridge spec than a different protocol.

RSTP calculates the
same spanning tree, and uses the same algorithm and even
packet formats as STP. Both RSTP and STP calculate a tree of shortest paths
from the Root bridge, which is the bridge with lowest ID/priority.

The major difference between RSTP and STP
is how they avoid temporary loops.
STP did it with a timer. RSTP coordinates between neighbors
to turn on links more quickly after topology changes.

However, in either case, it is impossible to always avoid temporary
loops...the simplest case is when a repeater comes up, or if too many
spanning tree messages get lost due to congestion.

So to summarize, both STP and RSTP use the same basic
algorithm...the heart of algorithm is to calculate a tree
of shortest paths from a single point.
And the resulting tree and data packet
forwarding path is the same in both (because it is the
same algorithm). A single shared loop-free subset
of the physical topology is calculated, upon which data packets are
forwarded.

2) What is the difference between RSTP and IS-IS?

This is harder to answer than the difference between RSTP and STP,
because IS-IS and spanning tree (RSTP/STP) are so very different from
each other. IS-IS passes around topology
information so that every RBridge calculates the shortest path between
itself
and each
destination. With spanning tree (RSTP/STP) each bridge just knows which
subset of its
own ports are "in" or "out" of the spanning tree. If a link is not in
the spanning tree,
then it cannot be used, even if it is the shortest path between point A
and B, and
pairwise paths can be quite suboptimal. Furthermore, traffic is concentrated
on the links in the spanning tree, because no traffic can be on links
not in the
spanning tree.

Also spanning tree bridges learn, based on
seeing data traffic, which
direction the source is. (which of its own local ports lead to the
source of
the data packet). So packets must always arrive from a particular source
from
the same direction or else bridges will get confused. In contrast, with
IS-IS,
switches can do path splitting; using multiple paths to reach a destination.

3) What is difference between RSTP and RBridge approach?

RBridge incorporates
a TTL into the header of forwarded data packets so a temporary loop is
not really bad, so it need not
be very conservative about avoiding loops. Also,
a link state protocol (IS-IS) calculates shortest
pair-wise paths. Also, it can calculate multiple paths to the
destination, and do path splitting.

4) What is the difference between recent work in IEEE to calculate
per-ingress trees, and RBridge approach?

IEEE may indeed wind up doing the same thing as RBridge. Several years
before TRILL I tried to get IEEE interested in doing this approach,
but they were not interested, perhaps because I didn't explain it
well enough. Now that work has started in IETF, I think it is possible
that IEEE will converge on the same solution, which would actually
be good for the industry.

Radia


Suping Zhai wrote:

>hi,
>I am confronted with some questions when reading the Rbridge protocol related draft and hope someone can help me with details.
>What's the essential difference between (R)STP and routing protocol(e.g. IS-IS)? 
>How dose the routing protocol(e.g. IS-IS) can optimize the routing path while (R)STP can't? 
>Can we optimize the (R)STP protocol itself to reach that goal? If that's the case, then I think that all RBridge WG works can be substituted. And I have seen some work been done in IEEE802.1aq which is on the way to the per bridge MSTP road. But what I imagine is that should we get a comparable simple and untangled solution for the bridge network routing path?
>
>TIA.
>
>Best Regards,
>zhaisuping at huawei.com
>Huawei Technologies Co., Ltd.
>Tel: +86-10-82836882
>Fax: +86-10-82836020
>2006-02-23
>
>
>
>
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>  
>