Subject: [rbridge] Proposal to make VLAN mapping work

From: Radia Perlman <[email-masked]>
Date: Mon, 15 Sep 2008 22:10:39 -0700

Some people expressed a desire to make "VLAN mapping" work with 
RBridges, since it
does work with bridges. The current version of the spec attempts to 
detect VLAN
mapping on a layer 2 cloud (caused
by bridge configuration within a cloud), and declare it a misconfiguration.
Some people objected (privately to me) to treating VLAN mapping as an 
error case,
and said that customers actually use it with bridges and might be unhappy if
the feature were removed in RBridges. So this note is proposing what we 
might do
to the RBridge spec to allow the VLAN mapping feature.

First, What is VLAN mapping? It is when a packet marked as VLAN A turns into
a VLAN B packet. Bridges can do it explicitly ("If something tagged as 
VLAN-A
comes in on port p1, change the tag to VLAN-B if forwarding onto port p2").
Or, a bridge B1 might be configured to emit packets on port p1 with no 
tags, so
B1 removes the VLAN-A tag, and
B2 (on the same link) might be configured to assume that untagged packets
are assumed to be VLAN-B.

Second, why would anyone want this (obviously scary if misconfigured) 
feature?

Here are two examples:

a) two companies, say "East" and "West" merge, and join their networks 
into one big layer 2 network.
Both have used the tag "VLAN A" for
one of their VLANs, but do not want the East VLAN-A nodes in the same VLAN
as the West VLAN-A nodes. The "right" solution is to change all the 
bridges (and
any nodes that actually are emitting tagged packets)
in, say, East, to renumber "A" to some other unused tag. But for 
whatever reason,
the customer might not want to do that, and instead wants all the work 
to be done by bridges
on the "cut set" between East and West (where "cut set" means the 
bridges that connect
East and West).

b) second example: a company decides it wants to partition VLAN A into 
two separate
VLANs, say A1 and A2, and they are lucky enough that all the A1 links are
in a different location within their bridged Ethernet from all the A2 links.

A goal is that the only bridges (RBridges in our case) that need to do 
anything
special for the VLAN mapping are the ones on the cut set.

*******************************************
So here's a proposal.

First, how to deal with VLAN mapping on a layer 2 cloud within the campus.
If VLAN A maps to VLAN B, the only real problem is if there is a 
different appointed
forwarder for the two VLANs. So the only thing we need to do is put the 
original
VLAN tag of a Hello inside the Hello (as the spec already says to do), and
decide what to do as a result (which the spec does not currently say).
If R1 is the appointed forwarder for VLAN-A, it must transmit a Hello tagged
with VLAN A (this is already specified). And VLAN-A is inside the packet 
as well
as being in the outer Ethernet header, where a VLAN mapping bridge might 
muck with it.
If R2 receives a packet with tag VLAN-B, with "A" inside, R2 must inform 
the Designated
RBridge "VLAN A maps to B", and the DRB must make sure that the same 
RBridge is
appointed forwarder for A and B. If we are worried about there being too 
many VLANs
being mapped to report it, I'd be happy with a single bit "VLAN mapping 
is going on",
in which case the DRB must appoint only a single appointed RBridge 
forwarder for the
entire cloud. So the only issue is how to encode "VLAN mapping is going on".

Second, how to deal with VLAN mapping within the campus. Let's simplify the
example and assume
no bridges. Let's assume that two clouds, East and West, are being 
merged and we
want to differentiate East-VLAN-A from West-VLAN A.

------------------------
First issue: data packets:

Let's say that R1, R2, and R3 each are connected to both East and West. 
The only
RBridges that will need to be configured are R1, R2, and R3.

-------------                  -----------------
|            |                 |               |
|            |------R1---------|               |
|    West    |                 |  East         |----R6
|            |------R2---------|               |     |
|            |                 |               |  VLAN y
|            |------R3---------|               |     |
-------------                  -----------------     D
     |          East-A = X             |
     R4         West-A = Y             R5
     |                                 |
   VLAN A                            VLAN A
     |                                 |
     S                                 S1

*********
Hmm. My beautiful ASCII art picture seems to have gotten mangled when I 
moved
the text from notepad into my email send buffer. In case it is mangled 
as you
receive it, the picture is supposed to indicate two clouds, "East" and 
"West",
with three RBridges; R1, R2, R3 connecting the clouds, and VLAN-A on East
is translated to VLAN-X in West, and VLAN-A in West is translated to VLAN-Y
on East, and R4, in West, is connected to VLAN-A endnode S,
and R6 in East is connected to VLAN-Y endnode D (where S and
D, due to remapping, should be in the same VLAN).
********

Both East and West have used VLAN A, but you
don't want to merge the two VLAN A's. Choose two unused VLAN numbers, 
say X and Y.
R1, R2, and R3 are all configured to change the tag of a VLAN-A tagged 
packet
they see on their East port to VLAN X when forwarding to West.
Also, to change the tag of a VLAN-A tagged packet they see on their West 
port
to VLAN Y.

R1, R2, and R3 all claim, in their LSP, to be connected to A, X, and Y.
Suppose S tries to talk to D. First assume R4 does not know where D is.
R4 injects a VLAN-A tagged unknown destination packet.
Since R1, R2, and R3 all claim to be connected (in their LSP) to VLAN A,
they all receive the multicast. Assuming they are on the distribution
tree, they change the tag from "A" to "Y" when forwarding from
West to East. R6 receives the packet. R6 learns that "S" on
VLAN Y is connected to R4. Now when D replies to S, there is
no problem. The packet, tagged with VLAN Y is sent to R4, and
along the way, one of R1, R2, or R3 change the tag to "VLAN-A".
R4 learns that VLAN-X endnode "D" is connected to R6.

I believe that all works. Even if a path goes from West to East and back to
West. The data packet's inner Ethernet header tag would get translated each
time the packet traverses one of the border RBridges.

------------------
The next thing is how LSPs work ("core" LSPs). I don't think there is any
complication. R4 will see that R5 also claims to be connected to VLAN A,
but that is actually irrelevant, as long as R4 is learning endnodes based
on received traffic.

However, what about endnode advertisements (which the spec currently
calls ESADI, for End System Advertisement Instance). R4 will
issue an ESADI about R4's attacked VLAN-A endnodes. I believe the
ESADI is known as a VLAN-A advertisement based solely on the tag on
the inner Ethernet header of the encapsualted ESADI packet.
Assuming that is true, then all that has to happen is that R1, R2, and R3
do their VLAN translation of the inner Ethernet header tag as they would
for any data packet, and when a VLAN-A ESADI moves from West to East, it
magically turns into a VLAN-Y tag. Note that R1, when it translates the
tag, is *not* messing with the contents of R4's LSP -- just the tag
in the Ethernet header.

****************
In summary, I think very little has to change in the spec. I think the only
changes are:
a) make sure there is a way of notifying the DRB, in your Hello, if you
detect VLAN mapping within a layer 2 cloud
b) make sure that the only indication that an ESADI belongs to VLAN-A is 
based on
the tag in the Ethernet header, and not anything in the body of the LSP.

I think a separate document should specify the behavior of a VLAN 
mapping RBridge.
And my preference would be that there would be a way of reporting in 
your (core)
LSP "I'm mapping VLAN A to VLAN X", just for management purposes, but 
RBridges
should ignore the field.

Comments?

Radia
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Caitlin Bestler" <[email-masked]>
Date: Tue, 16 Sep 2008 17:54:58 -0400

My first inclination is that supporting VLAN remapping is something
that RBridges should support. One of the strengths of RBridge
as compared to proposals such as Shortest Path Bridging (SPB)
is that RBridges can be added at the edges and use the existing
L2 network as is.

Most 802.1 defined enhancements, in contrast, are only defined
over the scope of a cloud consisting solely of bridges and
end stations that are advertise their awareness of the
enhanced protocol.

But given that objective, I did not follow why a simpler
solution would not work. Basically, we could require that
there be a consistent set of VLANs that is used for all
interactions between RBridges. But then we could specifically
allow RBridges to do VLAN mapping when encapsulating or
decapsulating.

Essentially the VLAN Mapping could be a feature of the
802.1Q bridge co-located with the RBridge.

The main defect I can see with this is that a frame
originating in Universe A would be translated on ingress,
sent to the destination RBridge and then translated back
for delivery. If the destination was also in Universe
A then the double translation was unnecessary.

But it would work.

---

From: Radia Perlman <[email-masked]>
Date: Tue, 16 Sep 2008 22:06:28 -0700

Not sure I understand what you said, but my understanding was that 
people wanted
to be able to take two clouds (say "East" and "West") and not do any 
configuration of
any of the RBridges inside either of the clouds, but only have the 
intelligence about
VLAN mapping in the RBridges that connect the two clouds.

It sounds like you are suggesting that every ingress/egress RBridge 
associated with a mapped
VLAN would need to be configured. What I was suggesting would only require
the three RBridges in my picture that connect East and West to know 
about VLAN mapping.

Also, if there really is a difference between "East-VLAN-A" and 
"West-VLAN-A", I'm not
sure how the egress RBridge can know whether the packet originated from 
"East" or "West".
It couldn't even be based on the identity of the ingress RBridge ("R1 is 
in East") because an RBridge
could have some ports in East and some in West.

But it's certainly possible I misunderstood your note.

What I think I did understand is that you are supporting us making sure 
that we do allow
for VLAN mapping.

Thanks,

Radia

---

From: "Caitlin Bestler" <[email-masked]>
Date: Wed, 17 Sep 2008 03:41:11 -0400

Yes, the solution solution I was suggesting puts the burden of VLAN mapping
on the RBridges that act as ingress/egress to subnets that have "alternate"
VLAN maps.

In some scenarios this would indeed mean that more RBridges had to be
configured. But the configurations would be purely local. There would be
zero impact on RBridge interactions.

It's more of an administrative burden, but keeps the protocols simpler.

But I fully agree on the main point. A key strength of RBridges is that
they can be deployed from the edges on an incremental basis rather
than being forced to build out from a set of enhanced Bridges that
all talk directly to each other.

When you are building from the center out, it is not that unreasonable
to state that as the enhanced cloud grows each addition has to adhere
to the same set of VLANs.

But if you're just plopping down RBridges and letting them discover
each other through an existing network then it makes more sense to
try to work with any network that actually works, and not just those
that are configured the way we would prefer.

I suppose what I am suggesting is that "special needs" networks should
be supported, but not necessarily with a zero-configuration option.
Explicit administrative action may be required, but we should not
require reconfiguring existing bridges and end stations. But requiring
that the RBridges be configured manually to deal with unique 
deployments does not strike me as being that onerous.

---

From: Dinesh G Dutt <[email-masked]>
Date: Wed, 17 Sep 2008 08:19:00 -0700

Caitlin,

I was of the same opinion, until I realized that VLAN pruning in the 
broadcast trees and multicast pruning requires us to modify the control 
protocol, especially since the Rbridges that are doing the mapping are 
sort of in the core of the network when the networks are merging.

Dinesh
Caitlin Bestler wrote:
> ------------------------------------------------------------------------
>

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

---

From: "Caitlin Bestler" <[email-masked]>
Date: Wed, 17 Sep 2008 13:17:38 -0400

> -----Original Message-----
> From: Dinesh G Dutt [mailto:[email-masked]]
> Sent: Wednesday, September 17, 2008 8:19 AM
> To: Caitlin Bestler
> Cc: Radia Perlman; [email-masked]
> Subject: Re: [rbridge] Proposal to make VLAN mapping work
> 
> Caitlin,
> 

Dinesh,

Are you saying that in the "merged network" scenario, that there would
essentially be an "East Core" and a "West Core", and that each needs
to do its own VLAN pruning separate  from the East/West VLAN Mapping
Bridges are considered?

That would be a justification for the more complex solution.

But just to kick the tires one more time, why can't the end stations
and bridges operating with legacy non-integrated VLAN Maps be
partitioned at the edges?

---

From: Dinesh G Dutt <[email-masked]>
Date: Wed, 17 Sep 2008 10:28:08 -0700

Hi Caitlin,

I don't think doing everything at the edge works. Consider a ARP request 
originating in the East Cloud in VLAN X. It must hit all end stations in 
VLAN X in the East Cloud and all end stations in VLAN Y in the West 
Cloud (assuming X is mapped to Y going from E->W). If I don't change the 
VLAN mapping at the RBridge connecting the two clouds, then it'll reach 
the wrong set of stations in the total cloud.

Was that clear ?

It's not that each core needs to do its own VLAN pruning. Consider a 
simple 3 switch network where VLAN 1 is mapped to VLAN 4 going from E->W 
and VLAN 1 is mapped to VLAN 3 going from W->E. R2 is doing the mapping 
(though in this trivial case, the edge mapping works fine, but add 
another switch to either side of R2 and edge mapping doesn't work).

                                        R1 -- R2 -- R3

Since there are no endstations in VLAN 1, VLAN 3 or VLAN 4 connected to 
R2, if R2 doesn't express an interest in at least VLAN 1, neither R1 nor 
R3 will send it any multi-destination VLAN 1 frames and R2 can therefore 
not really propagate the frames from one side to another.

Dinesh
Caitlin Bestler wrote:
>> broadcast trees and multicast pruning requires us to modify the
>>     
> control
>

---

From: "Caitlin Bestler" <[email-masked]>
Date: Wed, 17 Sep 2008 14:23:30 -0400

> Sent: Wednesday, September 17, 2008 10:28 AM
> To: Caitlin Bestler

My assumption was that the ingress RBridge would map legacy VLAN X
to common VLAN Z and distribute it to the other RBridges. The egress
RBridges would translate back to legacy VLAN X or legacy VLAN Y 
according to their own edge configurations.

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.
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.

Do you see a problem with this solution working?

Independent of whether it works, there is a second question
of how common these steps would be and exactly how onerous
they are compared to the cost of making the core protocols
slightly more complex.

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.

---

From: Dinesh G Dutt <[email-masked]>
Date: Wed, 17 Sep 2008 12:01:41 -0700

Hi Caitlin,

>    VLAN Maps must be manually configured to do the mapping to
How do you achieve this by only VLAN mapping at the edges and not 
touching any other device ?
>    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.
> scenario is something that zero configuration has to
I agree that it is not a common scenario,

Dinesh

---

From: Radia Perlman <[email-masked]>
Date: Wed, 17 Sep 2008 13:24:18 -0700

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:
> renumbering (in addition to mapping at the edges) my entire network. 
> If I have to renumber, I won't remap.

---

From: Dinesh G Dutt <[email-masked]>
Date: Wed, 17 Sep 2008 13:40:38 -0700

> renumbering the VLAN that needs to change.
I understood the same. That's unfortunately not always the choice,
> 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
That is fine by me. That is why I believe you suggested documenting the 
other changes in a separate draft.

Dinesh

---

From: Radia Perlman <[email-masked]>
Date: Wed, 17 Sep 2008 21:28:10 -0700

Dinesh, which of the alternative approaches to b) do you prefer, namely:

1) If RB1 notices X maps to Y, RB1 reports "X maps to Y" in its Hello,
and there must only be one forwarder for the set {X,Y}, but all the 
other VLANs
can be divvied out to lots of other forwarders

2) If RB1 notices that any VLAN maps to any other VLAN, it simply
sets a flag in its Hello saying "VLAN mapping is occurring on this cloud",
and there must be only one appointed forwarder for all VLANs on that link.

I personally prefer 2). I would have preferred only the DRB forward to/from
the link (simpler, safer) in all cases, but certainly if we say that 
there can
only be a single forwarder in the (hopefully rare) case where VLANs are
being mapped within the link, that seems like not a big restriction.

If we do 2), that means a whole lot information to encode in a Hello. Just
a flag "I've detected VLAN mapping". The alternative (1) requires encoding
which VLANs map to which other VLANs.

Radia

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Thu, 18 Sep 2008 00:06:58 -0700

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dinesh G Dutt
> Sent: Thursday, September 18, 2008 5:41 AM
> To: Radia Perlman
> Cc: [email-masked]; Caitlin Bestler

Considering all the issues being brought up, and the fact
that "VLAN translation" (that's the 802.1 term for this) is
not a standard function for C-tags, this is the option I
prefer -- we detect it and do something to make sure nothing
nasty happens, rather than try to actually make it all work.

Anoop

---

From: Dinesh G Dutt <[email-masked]>
Date: Thu, 18 Sep 2008 08:38:24 -0700

Option 2 is fine with me, Radia. We can extend it later, if need be.

Dinesh
Radia Perlman wrote:
>>> a) explicitly not support VLAN mapping. Declare it a 
>>> misconfiguration if it is detected, and
>> That is fine by me. That is why I believe you suggested documenting 
>> the other changes in a separate draft.
>>
>> Dinesh
>>
>>   
>
>

---

From: "Caitlin Bestler" <[email-masked]>
Date: Thu, 18 Sep 2008 13:13:41 -0400

> and there must be only one appointed forwarder for all VLANs on that

My understanding of the problem being solved is as follows:

- An existing campus has at least two "zones". There are VLANs
  that exist in both zones, but different VLAN IDs are used.
- Existing Bridges translate VLAN IDs on frames that cross
  between the zones.
- If RBridges are added in multiple zones, the existing
  VLAN-translating bridges will not know to translate
  the RBridge encapsulated frame.

Ultimately the required solution is that only RBridges
that are aware of the required VLAN translation will send
RBridge encapsulated frames across a zone boundary. How
a specific RBRidge supports VLAN Translation would be
outside the scope of the specification. The only thing
being specified is identifying when the problem exists.

Is that correct?

Is the assumption that the single appointed forwarder
for the link will do the VLAN Translation?

Is that truly required, or is that merely *a* method
of achieving the goal? Could the response of RB1 be
merely to state "based on your HELLO there is clearly
a VLAN Translation occurring that you are unaware of.
Please try again once you've fixed this problem."

I am also assuming the following:

- Requiring administrative configuration of RBridges
  that forward across zone boundaries is acceptable
  given that "multi-zone" campuses are the exception.
- Nothing in the standard will require an RBridge to
  be capable of doing VLAN Translations to enable
  inter-zone forwarding, merely that it must not do
  inter-zone forwarding incorrectly.

---

From: Radia Perlman <[email-masked]>
Date: Thu, 18 Sep 2008 19:50:29 -0700

No. I don't think you and I are thinking of the same problem scenario.
Let me
try to explain my understanding of the problem.

*******
First, forget bridges for a moment, and assume we only have RBridges. 
The problem is
that you have two zones, East and West, with a different number for a 
particular VLAN in
East vs West. (because you want to join what is called "VLAN A" on one 
side with "VLAN X"
on the other side.

The desire is to accomplish this by putting RBridges connecting East and 
West, so that VLAN-aware
nodes in either zone are not aware of any mapping going on. When East 
sends a broadcast to "VLAN A",
it magically gets received by all nodes in VLAN X in West.

I believe we can provide for this without changing anything in the spec, 
and perhaps how to
build the RBridges that connect the two zones and translate VLANs should 
be fully described
in another document.

So as long as there are two clear zones, East and West, and all the 
RBridges connecting the two
zones are properly configured, and there is no ambiguity about whether a 
port is in East or West,
it all works.

************

Now assume that we have East and West, and instead of having the zones 
connected
by, say, three VLAN-mapping RBridges R1, R2, and R3, instead we replace, 
say, R1
with a bridged cloud that does VLAN mapping.

R4 ---- VLAN-mapping-cloud ------R5

instead of

West ---------------R1--------------East

R4 and R5 are not doing any VLAN mapping. R4 acts just like an RBridge 
in West
in the upper scenario, and R5 acts like an RBridge in East.

We already have hooks in the Hellos so that when R5 issues a Hello with
tag VLAN A, R4 notices that it receives it with VLAN X. (because bridges
between R4 and R4 are translating VLAN A to VLAN X).

The current spec says "panic if you notice mapping going on on your link 
and don't forward
on behalf of any VLANs that are getting mapped".

But really, the only way VLAN mapping can cause a loop is if you have a 
different appointed
forwarder for one VLAN than another. So I'm proposing that instead of 
"panic",
that link is constrained to have just a single appointed forwarder for 
all VLANs.

Then I think that customers can do whatever VLAN mapping they want with
either bridges or with special VLAN-mapping RBridges, that we should specify
in a separate document. But all we need to make sure we can add on
VLAN-mapping RBridges is a bit in the Hello saying "VLAN mapping is 
going on",
and a rule that if the DRB sees that flag in anyone's Hello, it must 
have a single
appointed forwarder for the link.

Radia

Hope this is clearer.

Radia