[rbridge] Ambition with different VLAN configurations

[Anoop Ghanwani]

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> Sent: Tuesday, September 18, 2007 6:12 PM
> To: Dinesh G Dutt
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Ambition with different VLAN configurations
> 
> Dinesh G Dutt wrote:
> >
> > Will it need to support both (three if you include the currently 
> > dominant model, Cisco's) spanning tree protocols, IEEE STP and MSTP 
> > (Cisco's PVST is IEEE's STP run per VLAN).
> How different are these? How much trouble is it to listen to 
> all the variants? I assumed they were all interoperable. What 
> happens if there is a bridged network with bridges that 
> support different of these variants?
> 
>  From what I remember of "original STP" and "RSTP", listening 
> to them should be identical.
> RSTP uses the same message formats, and is the same protocol 
> other than adding loop prevention messages. So I'd assume if 
> you are listening, it wouldn't matter if it was STP vs RSTP.

This is correct.

> MSTP, if I understand it correctly, involves noticing that 
> different bridges are root for different VLANs. However, 
> maybe we can ignore that, and only listen to messages for the 
> spanning tree for VLAN 1. I'm assuming we can do that -- 
> someone should correct me if I'm wrong. The other plausible 
> alternative is to listen to all the spanning trees, and if 
> you're doing load splitting of DRBs (one for VLANs 1-50, and 
> the other for VLANs 51-79, say), then in the pseudonode 
> representing VLANs 1-50, you'd list the root bridges for the 
> spanning tree associated with each of the VLANs 1 through 50.

And so is this.  Basically, from the perspective of what
we are trying to accomplish with MSTP, we could just listen
to the messages for the CIST (common and internal spanning
tree) which is the spanning tree that goes across all
spanning tree regions and forwards traffic to VLANs that is
not mapped to any of the other instances.
 
> As for your description of "PVST" -- again, the implication 
> might be that if you have a pseudonode representing all the 
> VLANs, you'd have to list, in that pseudonode, a different 
> bridge ID since (if I understand what PVST is from your one 
> phrase above), there might be a different root bridge ID for 
> each of those.
>
> But...I *thought* that the spanning tree is guaranteed not to 
> be partitioned, so listing just the root of the spanning tree 
> corresponding to VLAN 1 should be all you need in order to 
> detect that there's an RBridge on the same link that you're 
> not hearing Hellos from, right?
> 
> *****************
> And as for allowing configuration to be some other VLAN other 
> than 1 -- that makes things complicated, because what do you 
> do if some of the RBridges on a cloud are configured 
> differently from others?

The only problem with using VLAN 1 only is that it
may require an operator to renumber their VLAN 
configuration if VLAN 1 is being used for something
other than what we would like it to be used for.

One way to handle misconfiguration would be to 
say that, if this condition is detected, then we
use the lower numbered VLAN and the one with the
higher numbered VLAN logs a misconfiguration error
and goes silent.  A misconfiguration is detected
if the root/VLAN combination reported for the same
pseudonode by 2 RBridges is different.

Anoop