[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