[rbridge] Proposal to make VLAN mapping work

[Radia Perlman]

I think I understand what Caitlin is saying, and let me say it in 
different words.
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 
can simply
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 
"X". East
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. 
Any packets
in the core tagged with "A" would be East's A. No confusion. And indeed 
this seems
like something the owner of the network ought to ultimately do. VLAN 
mapping seems
really scary to me, especially with the possibility of misconfiguration.

But I was told that some customers want to take the two clouds, not 
reconfigure
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 
works, there
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. 
(this is
how the current spec reads)
b) allow for support by changing the spec to include information in 
IS-IS Hellos
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 4.2.3.1.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 
Hello indicates
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 
indicating that
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 
the case
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,
>
> Dinesh
>