[rbridge] Ambition with different VLAN configurations

[Dinesh G Dutt]

I agree to Radia's points with the addition of Silvano's points,

Dinesh
Silvano Gai wrote:
> In the spirit of making progress, I am OK with this with the addition
> that:
>
> 1) we don't generate BPDUs trying to become the root of the Spanning
> Tree.
>
> 2) we don't care about temporary loops generated by repeaters (repeaters
> don't exist at 1 and 10 Gb/s), but we avoid all other temporary loops.
>
> 3) Frame duplication is also a big deal, clearly unacceptable in steady
> state, need to be analyzed carefully in transient: better to drop than
> to duplicate.
>
> -- Silvano
>
>
>   
>> -----Original Message-----
>> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
>>     
> On
>   
>> Behalf Of Radia Perlman
>> Sent: Friday, September 14, 2007 12:18 PM
>> To: Erik Nordmark
>> Cc: Developing a hybrid router/bridge.
>> Subject: Re: [rbridge] Ambition with different VLAN configurations
>>
>> . I think we should only make sure that in odd configurations there
>>     
> are
>   
>> no loops. We should
>> not worry about partitions caused by nontransitive connectivity.
>>
>> . I think we should go to some amount of trouble to ensure there are
>>     
> not
>   
>> even temporary loops (not
>> just "no permanent loops".
>>
>> . It would be nice to say "never ever have any loops", but I don't
>>     
> think
>   
>> that's possible, given
>> repeaters coming up, messages getting lost, a bridge or RBridge
>> exhibiting bizarre behavior
>> due to some bug, etc. That has nothing to do with TRILL -- any design
>> might occasionally
>> wind up with a loop in low probability events, and we should make sure
>> that the probability
>> is very low and minimize the length of time/effect if things go wrong.
>>
>> . I prefer a design in which there should be one VLAN tag (the default
>> one) that
>> is not partitioned on a layer 2 cloud, and all RBridge-RBridge
>> communication on that cloud
>> (including Hello messages)
>> should have that VLAN tag on the outside, and if that VLAN is indeed
>> partitioned, then
>> all but one RBridge, even if elected to be DRB on some set of VLANs,
>> will refrain from
>> forwarding data to/from the link.
>>
>> Radia
>>
>> Erik Nordmark wrote:
>>     
>>> The list has had discussions on how to do hellos with VLANs, and the
>>> discussion makes me wonder whether we have agreement on the level of
>>> ambition with various unusual VLAN configuration in the bridged
>>>       
> LANs.
>   
>>> By "ambition" I mean whether in a particular case we should:
>>> 1. Make RBridges provide full connectivity for all the nodes in the
>>> bridged LAN
>>> 2. Make RBridges at least detect that there is something odd about
>>>       
> the
>   
>>> VLAN configuration and ensure that no permanent loops can be formed.
>>>       
> But
>   
>>> it would be ok to orphan some nodes from communicating.
>>>
>>> One can ask that question for different VLAN scenarios.
>>> One interesting case that Donald brought up is when there isn't a
>>>       
> single
>   
>>> VLAN tag on which all the RBridges can communicate.
>>> For instance, RB0 and RB1 can only send and receive using VLAN tag
>>>       
> 3.
>   
>>> RB2 can only send and receive using VLAN tag 4.
>>> RB3 and RB4 can send and receive using both VLAN tag 3 and 4.
>>>
>>> There are different schemes for making hellos detect the
>>>       
> connectivity in
>   
>>> this case. So let's ignore that and instead look at the implications
>>>       
> on
>   
>>> the data plane if we want ambition #1.
>>>
>>> Suppose RB4 has a multicast to send to all RBridges. Which VLAN tag
>>> should it use? There isn't a single VLAN tag that it can use
>>>       
> whichever
>   
>>> reach all RBridge neighbors. But RB4 can't treat the port as two
>>> logically different ports (one for VLAN tag 3 and a separate one for
>>>       
> 4)
>   
>>> either, since RB2 is a neighbor for both VLANs.
>>> Thus if we wanted this case to provide full connectivity it would
>>>       
> seem
>   
>>> like the data plane would need to be able to duplicate packets and
>>>       
> send
>   
>>> some unicast; a possible strategy would be to multicast with tag 3,
>>>       
> and
>   
>>> then unicast a copy to RB2 (with tag 4). That way all the
>>>       
> neighboring
>   
>>> RBridges would receive the frame.
>>>
>>> That sounds complex.
>>>
>>> There might be other examples of odd VLAN configuration (such as
>>>       
> bridges
>   
>>> which untag and then add some other tag when forwarding the frame)
>>>       
> which
>   
>>> are complex to fully support. What level of ambition should we have
>>>       
> for
>   
>>> the odd cases?
>>>
>>>     Erik
>>>
>>> _______________________________________________
>>> rbridge mailing list
>>> rbridge at postel.org
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>
>>>       
>> _______________________________________________
>> rbridge mailing list
>> rbridge at postel.org
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>     
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan