[rbridge] Proposal to make VLAN mapping work
Radia.Perlman at sun.com
Wed Sep 17 13:24:18 PDT 2008
I think I understand what Caitlin is saying, and let me say it in
What Caitlin is saying: Avoid VLAN mapping entirely by just
renumbering the VLAN that needs to change.
Suppose we start with VLAN A in both "East" and "West". If there
is a VLAN number, say, X, that is unused in both East and West, then we
rename VLAN A in West to VLAN X. This would involve reconfiguring all
RBridges, bridges, and VLAN-aware endnodes in West to reconfigure "A" to
doesn't need to be renumbered, since it can simply keep using "A".
Indeed, that would solve the problem, and not require any VLAN mapping.
in the core tagged with "A" would be East's A. No confusion. And indeed
like something the owner of the network ought to ultimately do. VLAN
really scary to me, especially with the possibility of misconfiguration.
But I was told that some customers want to take the two clouds, not
anyone in either cloud, and glue them together with magic boxes that
map. If that's what they want to do, then I think you need to do
something like what
I said in the first email on this thread. And assuming what I wrote
is very little implication on the spec, or on RBridges that do not want to
do VLAN mapping.
I would certainly be personally happy if I'd never heard of VLAN
mapping, and if the
problem were always solved by manually reconfiguring all bridges,
RBridges, and VLAN-aware
endnodes connected to the VLAN that needs to be mapped. However, the
claim is that
some customers like the bridge "VLAN mapping" feature that allows gluing
islands together and changing
the VLAN numbers.
So I think our options are:
a) explicitly not support VLAN mapping. Declare it a misconfiguration if
it is detected, and
make the network owner renumber things so no VLAN mapping is occurring.
how the current spec reads)
b) allow for support by changing the spec to include information in
to alert the DRB that VLAN mapping is going on.
So, anyway...I recommend we do "b", namely alert the DRB that VLAN
mapping is going on, and have the DRB make sure there is only one
forwarder for any mapped VLANs, and don't say anything else in the
spec about VLAN mapping. That way there are sufficient hooks so
that someone can implement VLAN mapping if they want.
The wording change from version 8 I'd propose is the following:
In section 126.96.36.199.3, where version 8 currently says
" When a VLAN mapping from X to Y is detected, the RBridge detecting it
disables its appointed forwarder status for both X and Y. The idea is to
produce a clean failure so the network operator will correct the bridged
LAN configuration. "
I'd propose it instead say something like:
"When a VLAN mapping from X to Y is detected by RBridge
RB1, RB1 informs the DRB, RB2, that VLANs X and Y are
mapped on the cloud. If RB1 is appointed forwarder for both X and Y,
then RB1 continues forwarding for both X and Y. However, if the DRB's
a different appointed forwarder than RB1 for VLAN Y, then RB1
disables its appointed forwarder
status for X and Y."
alternatively (if we want to just have a single bit in the Hello
VLAN mapping is going on, rather than
a list of which VLANs map to which other VLANs, and live with requiring
only a single appointed forwarder for all VLANs in that case):
"When any VLAN mapping is detected by RB1, RB1 informs the DRB with
a flag in RB1's Hello saying "VLAN mapping is detected on this link". In
of VLAN mapping on a link, there must be only a single appointed forwarder,
which will forward for all VLANs. If the DRB's
Hello indicates more than one appointed forwarder for the link, then RB1
disables its appointed forwarder status for all VLANs until the DRB's Hello
indicates just a single appointed forwarder for the link."
Dinesh G Dutt wrote:
> Hi Caitlin,
> Caitlin Bestler wrote:
>> The key caveats to this approach are:
>> a) Every RBridge that supports a local sub-cloud using legacy
>> VLAN Maps must be manually configured to do the mapping to
>> from a common map.
> How do you achieve this by only VLAN mapping at the edges and not
> touching any other device ?
>> b) When a frame originates in legacy VLAN X and is destined to
>> legacy VLAN X it will undergo two translations that probably
>> could have been avoided (assuming the entire path was part
>> of either the "East" or "West" campus.
> This is OK for me, but I can't see how to do this without VLAN
> renumbering (in addition to mapping at the edges) my entire network.
> If I have to renumber, I won't remap.
>> My current assumption is that this scenario is relatively
>> rare, and therefore the burdens would have to be very onerous
>> to justify adding a complexity to the protocol that all
>> RBridges would have to deal with all of the time. Of course,
>> that is only an assumption on my part. I haven't done any
>> market survey to confirm this or anything like that.
>> If you change those assumptions, for example by assuming
>> that zero configuration should work even when there are
>> multiple VLAN maps in use, then you would have to conclude
>> that edge remapping is not a viable solution. However, I
>> am not convinced that this "East/West Campus merger"
>> scenario is something that zero configuration has to
>> deal with.
> I agree that it is not a common scenario,
More information about the rbridge