[rbridge] Ambition with different VLAN configurations

[Anoop Ghanwani]

I concur with Radia on all points.

Anoop 

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