[rbridge] Proposal to make VLAN mapping work

[Radia Perlman]

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



Caitlin Bestler wrote:
> 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.
>
>