[rbridge] Final outcome of outer VLAN tags onRBridge-RBridgepackets?

Dinesh G Dutt ddutt at cisco.com
Tue Oct 30 21:01:32 PDT 2007


Radia,

I've been swamped at work and have been travelling as well. Most of my 
issues were related to sending Hello on a single VLAN only, be it VLAN 1 
or configurable. I'll get back to you in the next couple of days after I 
have caught up on the discussions,

Dinesh
Radia Perlman wrote:
> 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
> 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.
>
> Radia
>
>
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan


More information about the rbridge mailing list