[rbridge] Convergence time

Tue Sep 13 06:01:50 PDT 2005

OK.
GOE is superoptimized and goes beyond RSTP in using the "Alternate" root 
port. But the values given for RSTP are pertinent.
I think the "clever" approach of tree instances rooted in the sink 
should be considered by Rbridges.
Lucent paper reports low reconfiguration times for  "their" RSTP 
including root bridge failure, only slightly superior to link failure. 
So it seems it can optimized only with RSTP.
Regards
Guillermo

Sofia, Rute wrote:

>Hello Guillermo,
>
>Thanks for the references.
>
>I am aware of GOE. However, GOE uses multiple-tree instances in a quite clever way, given that each bridge (edge bridge) becomes the root of a sink ST. And in fact, they do not take care of root failure - at least the paper does not really specify how root failure is treated. When the root fails, then they cleverly assume that because the root is the sink and represents an edge bridge (e.g., an access node), then there is no need to "recover". In other words, recover is not possible, unless there is a backup edge bridge (multi-homed scenarios) Moreover, GOE relies not only in multiple tree instances (simplification of MSTP) but also in "backup" trees, given that for each bridge, they establish two trees giving them different priorities.
>But it is a fact that their approach converges quickly. Again, this is due to the in-service reconfiguration they provide.
>
>As for the Lucent paper, I'll check it. However, my question was more related to the subject previously mentioned, meaning, the question Wojtek asked about IS-IS convergence time tunning in Rbridges and this compared to "pure" RSTP (one tree instance).
>
>The pre-flooding ability of Rbridges brings in flexibility but there is (possibly) a cost associated to the IS-IS tunning. The following reference concerns IS-IS tunning on IP:
>
>http://portal.acm.org/citation.cfm?id=1070873.1070877
>
>But the question is: does Rbridges consider this? In fact, the tuning of IS-IS may affect the performance of Rbridges, given that while tuning IS-IS to achieve convergence in the order of 10/100 ms seems feasible, there is a price to pay in terms of updates exchanged...
>
>Regards,
>Rute
>
>
>
>-----Original Message-----
>From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Guillermo Ibáñez
>Sent: 13 September 2005 12:54
>To: Developing a hybrid router/bridge.
>Subject: Re: [rbridge] Convergence time
>
>
>
>
>Rute ,
>       10 msec is cited in the standard as a reachable minimum to detect 
>link failure (for instance of the bridge root port link).  As the 
>alternate port for root port  is preselected, no BPDU interchange across 
>the link is needed in this particular case for reconfiguration of the link. Global Open Ethernet goes beyond this, reaching 2 msec for switchover to 
>an alternate link with GOE switches. See:  Global Open Ethernet (GOE) 
>System and its Performance Evaluation/ A. Iwata, Y. Hidaka, M. 
>Umayabashi, N. Enomoto, and A. Arutaki  (IEEE Journal on Selected Areas 
>in Communications) Oct. 2004 ./In this article performance for 
>reconfiguration with RSTP switches is reported as 60 msec, but growing 
>with increasing network sizes.
>Lucent offers RSTP based improved implementations with reconvergence 
>under 200 msec. in :  
>www.lucent.ru/i/docs/TripplePlay/Spanning-Trees-Whitepaper.doc
>Although the upper limit for RSTP seems to be on the several seconds 
>range, it seems there is still room for improvement as the vendors 
>manifest (Lucent) and implementations show. So, improving RSTP to lower 
>upper convergence limit  might be one way to advance, as the capability 
>for fast transitions is proven.
>Regards
>Guillermo
>PD. Root bridge failure seems to be the worst case for reconvergence in 
>RSTP compared with link failure or new root bridge election.
>
>Sofia, Rute wrote:
>
>  
>
>>Guillermo,
>>
>>Can you please refer to *any* performance study on RSTP that shows 
>>convergence times in the order of 10/100 ms?
>>
>>Best Regards,
>>Rute Sofia
>>
>>
>> 
>>
>>    
>>
>>>-----Original Message-----
>>>From: rbridge-bounces at postel.org
>>>[mailto:rbridge-bounces at postel.org] On Behalf Of Guillermo Ibáñez
>>>Sent: Monday, September 12, 2005 11:43 PM
>>>To: Developing a hybrid router/bridge.
>>>Subject: Re: [rbridge] Convergence time
>>>
>>>I recommend a reading of RSTP (IEEE 802.1D) protocol for
>>>mechanisms of 
>>>fast reconfiguration and spanning tree reconstruction. Although 
>>>convergence is alleged to extend to several seconds in case of root 
>>>bridge failure (Myers 2004), tipical times are tenths, hundreds of 
>>>milliseconds, not easy to achieve with routing protocols.
>>>I am not familiar with fast rerouting but applying it to 
>>>build spanning 
>>>trees may be require a different solution than repairing routes with 
>>>backup routes.
>>>Guillermo Ibáñez
>>>
>>>Alia Atlas wrote:
>>>
>>>   
>>>
>>>      
>>>
>>>>I imagine that one could do fast-reroute techniques,
>>>>     
>>>>
>>>>        
>>>>
>>>depending on the
>>>   
>>>
>>>      
>>>
>>>>convergence time requirements.  Given SPTs and a link-state
>>>>     
>>>>
>>>>        
>>>>
>>>protocol
>>>   
>>>
>>>      
>>>
>>>>are being used,
>>>>I believe that the work in rtgwg could apply.
>>>>
>>>>Alia
>>>>
>>>>On 8/29/05, *Wojtek Paprowicz* <quasarus at gazeta.pl
>>>><mailto:quasarus at gazeta.pl>> wrote:
>>>>
>>>>   Hi everybody,
>>>>
>>>>   I was wondering if convergence is a case in RBRIDGE idea. Taking
>>>>   into concideration, that currently RBRIDGEs run ISIS, I think it
>>>>   should be. How do you think should be the timers set in order to
>>>>   achieve results similar to SDH? The default timers will
>>>>     
>>>>
>>>>        
>>>>
>>>not do the
>>>   
>>>
>>>      
>>>
>>>>   trick. On the other hand, we cannot lower e.g. helloInterval too
>>>>   much. The timers are also crucial for node/link
>>>>     
>>>>
>>>>        
>>>>
>>>failures and failure
>>>   
>>>
>>>      
>>>
>>>>   recovery times. Be grateful for your opinions.
>>>>
>>>>   Regards,
>>>>   Wojtek Paprowicz
>>>>
>>>>
>>>>
>>>>   _______________________________________________
>>>>   rbridge mailing list
>>>>   rbridge at postel.org <mailto: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
>>>>
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>_______________________________________________
>>>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
>>
>> 
>>
>>    
>>
>_______________________________________________
>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
>
>  
>