[rbridge] A question about (R)STP and routing protocol / requestfor comments to Abridges draft

[zhaisuping at huawei.com (Suping Zhai)]

Hi Guillermo,
Still another observation wrt the following draft.
If in the core Abridge there is no VLAN discrimination, so are there any security issues or application complex implications? What I concern is that the Abridges in the core belong to different service provider or something like that, if the VLAN domain a good way to control the access?

Regards,
Suping
>Let me give my opinions interleaved.
>By the way, as the Abridges draft we submitted last december is 
>somewhere between the current RBridges proposal and the IEEE Shortest 
>Path Bridging, we think it would help clarify to obtain comments to our 
>draft from the RBridges WG members.
>Regards
>Guillermo Ibanez
>
>
>http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt
>
>Guillermo Ibanez
>
>
>Radia Perlman wrote:
>
>>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.
>>
>>  
>>
>It is important to remember that the standard convergence times of RSTP 
>are lower than those of routing protocols, unless specific measures for 
>milliseconds convergence are applied.
>
>>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.
>>  
>>
>Both IEEE Shortest Path Bridging and the Abridges draft proposal ( see
>http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt)
>obtain shortest paths. They do not allow  path splitting, but are less 
>complex than IS-IS
>and do not mix STP and IS-IS protocols in same area.
>
>>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
>>  
>>
>I do not see an easy convergence between IEEE and RBridge proposals 
>unless the two groups cooperate strongly.
>IEEE will likely preserve basic RSTP mechanisms (fast convergence and 
>distance vector to (multiple) root bridges) with multiple spanning trees 
>(this is my guess, I do not follow their recent activities), while 
>RBridge uses IS-IS (link state mechanisms) as basic protocol.
>
>
>Guillermo Ibanez
>
>>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: [phone]
>>>Fax: [phone]
>>>2006-02-23
>>>
>>>
>>>
>>>
>>>
>>> 
>>>
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>rbridge mailing list
>>>rbridge at postel.org
>>>http://www.postel.org/mailman/listinfo/rbridge
>>> 
>>>
>>>    
>>>
>>
>>  
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>rbridge mailing list
>>rbridge at postel.org
>>http://www.postel.org/mailman/listinfo/rbridge
>>  
>>
>
>-- 
>Guillermo Ib¨¢?ez
>Departamento de Ingenier¨ªa Telem¨¢tica
>Universidad Carlos III de Madrid
>1.1.B.11 Colmenarejo 91-6241393
>4.1.F.13 Legan¨¦s 91-6248794
>
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge