[rbridge] seekinginput on abstractfor problemand applicabilitystatement

[Guillermo Ibáñez]

Guillermo Ibáñez wrote:
 
OK. So the designated Rbridge should act as root bridge of that spanning 
tree, for a shortest path to all bridges of spanning trees.


Saikat Ray wrote:

>I see the potential problem you mention with the attachment of spanning 
>tree to /different/ rbridges with broadcast  frames. An rbridge receives 
>the broadcast frame from the spanning tree, encapsulates it with the 
>all_rbridges_multicast address and forwards to all rbridges. The frame 
>is received by an rbridge of the same spanning tree, decapsulated and 
>retransmitted to same spanning tree. Do I miss something?
>Guillermo
>
>[Saikat] Only one of the RBridges would be *designated* to encapsulate the
>packets from and decapsulate the packets to that spanning tree.
>
>  
>
>> 
>>
>>    
>>
>>>The
>>>worst it can do is change the routes because you get two STP trees each
>>>with different root bridges ... which is not always ideal and why I
>>>think you need TRANSPARENT AND BLOCK options at different phases of a
>>>migration ... and possibly even Ships in the Night mode too.
>>>   
>>>
>>>      
>>>
>>SITN assumes some level of manual configuration - you have to know which
>>ship you're on ;-)
>>
>>Joe
>> 
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>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
>
>  
>