[rbridge] Ambition with different VLAN configurations

[Silvano Gai]

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