[rbridge] Final outcome of outer VLANtags onRBridge-RBridgepackets?

[Anoop Ghanwani]

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> Sent: Tuesday, October 30, 2007 5:23 PM
> To: Silvano Gai
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Final outcome of outer VLANtags 
> onRBridge-RBridgepackets?
> 
> Silvano Gai wrote:
> >
> > "VLAN 1--nonconfigurable" is a non-starter for me, I hope to have 
> > explained why.
> >
> > "single VLAN per layer 2 cloud" may be workable, but I need 
> to see the 
> > details of the algorithm to see if there are corner cases.
> >
> > If we can agree to concentrate our focus on a "single VLAN 
> per layer 2 
> > cloud" we have made some progress.
> >
> > -- Silvano
> 
> I can live with "single VLAN, configurable, default=1". I'd 
> recommend that regardless of the VLAN you are configured to 
> send a Hello on, you accept Hellos on any VLAN you are 
> capable of receiving traffic on, and that each DRB tells all 
> the other RBridges on that cloud what VLAN to send on, so 
> that they all wind up sending RBridge traffic on the same VLAN.
> 
> I think the only complexity/overhead it adds over "VLAN 1, 
> nonconfigurable is"
> 
> a) something configurable to document and present in the 
> management interface (the VLAN on which to send Hellos)
> b) until a DRB is elected, there might be lots of RBridges 
> transmitting on different VLANs because each might be 
> configured with a different VLAN

The problem with this is that there may be RB's sending
hellos on a VLAN that other RB's don't see.  As a result
the adjacency creation may not be correct.  For example,
RB1 may send its hellos on VLAN 4, RB2 may send its
hellos on VLAN 5, neither RBridge is able to see the
other's hellos because of the way the bridged LAN is
configured.

I think the correct way to solve this is to say that
hellos will be sent on exactly one VLAN for any bridged
LAN - VLAN 1 would be default, but configuration is
allowed.  So in the LSP, along with things like root
bridge for the pseudonode, we advertise the "Rbridge
control VLAN" that is used.  If a conflict is detected
when an LSP is received (same root, different control
VLAN), then the RBridge with higher ID stop being a
DRB and reports a misconfiguration.

A misconfiguration could also be detected by configuring
all RBridges on the LAN to be in a maintenance association
using 802.1ag. (But that would be very configuration
intensive.  802.1ag would cause a trap to be generated
if all Rbridges don't see all the Rbridges they expect 
to see, or if they see extra ones that they haven't
been configured about.)

> c) if there are multiple (say k)  DRBs (because for load 
> splitting each of them is DRB for a different 
> (nonoverlapping) set of VLANs), then there will be k times as 
> many Hellos being sent
> d) I think there might be a slightly higher probability that 
> there will be misconfiguration such as telling each RBridge a 
> different set of VLANs to talk on, but the safeguards that I 
> specified in previous emails (listen to BPDUs, report root 
> bridge in pseudonode LSP, don't decapsulate from an ingress 
> RBridge that you haven't seen all the LSPs from, wait until 
> you've synchrornized LSP databases with your neighbors when 
> you first start up) will prevent loops in these cases, and at 
> worst orphan parts of the layer 2 cloud from the rest of the campus.
> 
> So...can everyone live with this? (Silvano -- as you said 
> above, you promised to think about whether there were any 
> corner cases to worry about. You also said you wanted to see 
> "the whole algorithm specified". I'll do that in a separate email.