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

From: zhaisuping at huawei.com (Suping Zhai)
Date: Fri, 24 Feb 2006 10:34:01 +0800

Hi Radia,
Thank you at first for you response. See inline my further doubts.
>This would be much clearer if I could make little ASCII drawings, but
>tonight I'm tired. Maybe I'll
>make a pdf drawing and send it to you if I can't explain in words.
>
>With spanning tree, there is only a single loop-free tree that is
>calculated by all the bridges.
>Let's say there is one link that is not selected to be in the spanning
>tree, and it connects
>B1 and B2. If B1 has a packet that needs to get sent to B2, it cannot
>use the B1-B2 link,
>since that link is not in the spanning tree. The spanning tree path
>between any two points can
>be quite bad because it is constrained not to use some links. In
>contrast, the IS-IS path
>can always choose the shortest path between any two points.
>
>As for whether RSTP/STP can be modified to calculate the same paths as
>IS-IS...sure...in the
>sense that anything can be modified to be anything else. But it really
>would be completely doing
>it a different way. The spanning tree algorithm is very different from
>Dijkstra/link state routing.

>
>So, the spanning tree has ALL bridges calculate the SAME spanning
>tree...the tree of shortest
>paths from the Root bridge to all the other bridges. IS-IS has each
>switch calclate a DIFFERENT
>graph, which is the graph of shortest paths from that switch to each
>destination. ANd I said "graph"
>rather than "tree" because with IS-IS you can calculate multiple paths
>to a destination. If you do
>that (calculate multiple paths), then it's no longer a tree.

[zsp]I go through some kinds of topology and use two kinds algorithms, that is using STP algorithm and Dijkstra seperately, and ultimately get the same tree or graph. So perhaps what I should ask is in what situation, with what topology there are different result forwarding tree when using above two mechanisms?

Suping
>
>Even if bridges were modified somehow to calculate the same paths as
>IS-IS, they would not
>be able to do path splitting (i.e., multiple paths to the same
>destination), because all traffic from S
>must be received on the same port....by the nature of how bridges do
>learning.
>
>If you do the modifications to achieve the same things as TRILL, you are
>basically doing the TRILL
>design....replacing spanning tree with link state Dijkstra, doing
>endnode learning differently, and
>then while you are at it, it would be a good idea to add a TTL to the
>header so temporary loops
>aren't a problem.
>
>Radia
>
>Suping Zhai wrote:
>
>>Radia,
>>Thank you for your detail explanations.
>>With the following 2) point, I am not yet clear enough and hope you can help me with that.
>>What I think about IS-IS is that, IS-IS router uses the neighbour link state informations, using the Dijakson algorithm to calculate the shortest path to the DR(Designated Router).
>>For the STP/RSTP(as I understand, they are almost the same regarding to the algorithm except for some convergence optimization), bridge also use the neighbour link state informations, using algorithm like Dijackson to calculate the tree path from the root bridge to every leaf bridge.
>>
>>So my question is, in what sense you can differ the result tree or routing path from the IS-IS and STP/RSTP? And are there any difference between the IS-IS and STP/RSTP with regard to the path calculation mechanisms?
>>With that my last question is, if STP/RSTP can be optimized to get the same result with what the IS-IS has?
>>
>>With Kind Regards,
>>Suping
>>
>>  
>>
>>>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
>>>> 
>>>>
>>>>      
>>>>
>>
>>
>>  
>>