[rbridge] VLAN mapping anonmolies...does anyone care?

[Radia Perlman]

The notion of "cloud" was supposed to imply having multiple separate 
TRILL campuses that get hooked together.
Once they are hooked together they are a single TRILL campus, but with 
VLAN mapping.

But if I'm reading your comments correctly, it sounds like you are 
saying that we shouldn't
worry about the corner cases. That basically,
a) you shouldn't map multiple VLANs in "East" to a single VLAN in "West".
b) topologies in which paths go from East to West and back to East, and 
as a result
the VLAN East-A which maps to West-null gets partitioned within East is such
a bizarre topology that we don't care to worry about it.

Am I correct in interpreting what you said? (and if so, I agree, 
especially since
I don't see any good solutions to these weird cases).

Radia



Anil Rijhsinghani wrote:
> Donald,
>
> Local VLANs in a region that have no corresponding VLAN in the other 
> LAN crossing a different region still need to be mapped, but into 
> "oblivion", or you will partition them when shortest paths change? 
> While this is clear as mud, crossing back and forth between randomly 
> connected regions is something that administrators are unlikely to 
>  figure out. VLAN remapping even in 802 is difficult to use unless you 
> have physically separate administrative regions - if they merge with 
> each other at multiple backdoors, all bets are off.
>
> However this ends up getting resolved, it would be good to define 
> terms used in describing forwarding behavior in the draft, such as 
> clouds or regions.
>
> Regards,
> Anil
>
> On Dec 15, 2009, at 11:20 PM, Donald Eastlake wrote:
>
>> Hi Anil,
>>
>> On Tue, Dec 15, 2009 at 9:48 AM, Anil Rijhsinghani <anil at charter.net 
>> <mailto:anil at charter.net>> wrote:
>>
>>     Donald,
>>
>>     > Say that you have two LANs with 3,000 VLANs in common that need to
>>     > be mapped but each having 1,000 local VLANs that have no
>>     > corresponding VLAN in the other LAN. It seems to me that you can't
>>     > make an invertible mapping to do this.
>>
>>     "Invertible" as used in Radia's mail meant to me that if VLAN A
>>     is mapped to VLAN B in one direction, then VLAN B is mapped to
>>     VLAN A in the opposite direction. You don't have multiple VLANs
>>     mapped to a single VLAN.
>>
>>
>> But I don't consider it invertible if you map a VLAN into oblivion. 
>> The discussion started with the possible, but probably rare, case of 
>> the shortest path between two RBridges in one VLAN region going 
>> *through* another region. If you just drop frames that use any of the 
>> hypothetical local VLANs I suggest above, which is what I mean by 
>> mapping into oblivion, then there is no frame to map back if the 
>> shortest path crosses back to the original VLAN region.
>>
>> Perhaps one should say "one-to-one and on-to" but "invertible" seems 
>> simpler...
>>
>>     I may be missing something about how your scenario above makes it
>>     difficult to use "invertible mappings". If some VLANs don't need
>>     to be mapped, don't map them. That would normally be the case
>>     most of the time.
>>
>>
>> If you don't map a VLAN and there is a shortest path that goes from 
>> the region where that VLAN is in use, through a different region, and 
>> then back, by not mapping the VLAN you have partitioned it.
>>  
>>
>>     I just looked at the I-D, and it seems to use the word
>>     "symmetric" to describe the same thing (1-to-1 correspondence.)
>>
>>     BTW the draft also uses the undefined term "L2 clouds" to
>>     describe its operation -- is a cloud the same as a TRILL campus,
>>     or are these clouds in the same campus? Separating "clouds"
>>     within a mesh network and configuring things between them sounds
>>     like an interesting problem.
>>
>>
>> It seems clear to me that the draft is using the term L2 cloud to 
>> mean that same as I did above when I spoke of "VLAN region", namely a 
>> part of the LAN without end stations or routers in which there isn't 
>> any VLAN mapping going on.
>>  
>>
>>     Regards,
>>     Anil
>>
>>
>> Thanks,
>> Donald
>>  
>>
>>     > On Mon, Dec 14, 2009 at 9:28 AM, <Anil_R at 3com.com
>>     <mailto:Anil_R at 3com.com>> wrote:
>>     > I'd say it would be best to define it in such a way that, once
>>     a switch has
>>     > been given a VLAN mapping from one port to another, it either
>>     rejects a
>>     > different mapping or overrides the old one, depending on how
>>     the MIB is
>>     > defined. Which is to say, make it "invertible" always.
>>     >
>>     > I guess I don't understand the first part of what you say above.
>>     > Making it always be invertible sounds safe but it seems to me there
>>     > might be cases where you can't do that.
>>     >
>>     > Say that you have two LANs with 3,000 VLANs in common that need to
>>     > be mapped but each having 1,000 local VLANs that have no
>>     > corresponding VLAN in the other LAN. It seems to me that you can't
>>     > make an invertible mapping to do this. The best you can do is just
>>     > to map most of the local VLANs to oblivion at the border and
>>     arrange
>>     > your networks so the probability is very low that the shortest path
>>     > between any two RBridges in of these LANs goes through the
>>     other LAN.
>>     >
>>     > So, my current thinking it that the mapping SHOULD be invertible.
>>     >
>>     > In practice, this sort of connectivity when desired by
>>     customers is done in
>>     > a way that doesn't require VLAN mapping: you'd define
>>     "overlapping VLANs"
>>     > which allow, in this example, VLAN A as well as VLAN B to reach
>>     the ports
>>     > of VLAN C, but do not allow VLAN A and VLAN B to talk to each
>>     other (if
>>     > that were the requirement.)
>>     >
>>     > That sounds like VLAN groups, which are touched on in Section 4.8.3
>>     > of the -14 version of the base protocol draft. I don't see it as
>>     > having much to do with VLAN mapping (also known as VLAN ID
>>     translation).
>>     >
>>     > In another scenario, you may have 3 different sites East, West
>>     and South,
>>     > where West wants its VLAN A to be translated to VLAN C in the
>>     East and
>>     > South wants its VLAN B to be translated to the same VLAN C in
>>     the East
>>     > (vice versa for the opposite direction). In such a case you
>>     would have 3
>>     > switches (connecting East, West and South), each of which have
>>     invertible
>>     > mappings. This is a much more common application of VLAN
>>     mapping: site
>>     > administrators define their own VLANs, then their edge switches
>>     translate
>>     > when necessary to connect into VLANs in a different site.
>>     >
>>     > Sure, handling N different regions isn't a problem.
>>     >
>>     > Regards,
>>     > Anil
>>     >
>>     > Thanks,
>>     > Donald
>>     _______________________________________________
>>     rbridge mailing list
>>     rbridge at postel.org <mailto:rbridge at postel.org>
>>     http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>