[rbridge] Ambition with different VLAN configurations

[Radia Perlman]

. 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
>