[rbridge] Shared VLAN learning: What is it and why should we care?

[Eric Gray (LO/EUS)]

Radia,

	Let me try to re-state your explanation to see if I understand 
it...

	You believe that the problem that shared VLAN learning is used
to solve is conservation of IP addresses used in a single IP subnet, 
and that it is necessary to use shared VLAN learning to keep routers 
(in the subnet) from having to re-learn MAC+IP associations across a
set of VLANs in that same IP subnet, is that correct?

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> Sent: Thursday, March 29, 2007 2:56 AM
> To: rbridge at postel.org
> Subject: [rbridge] Shared VLAN learning: What is it and why 
> should we care?
> 
> Hopefully this explanation will be clear enough for people to 
> at least 
> figure out whether we
> are all talking about the same thing. Of course, feel free to 
> correct me 
> if my understanding is wrong.
> 
> First we need to understand what problem it is trying to 
> solve. This is 
> my understanding of that:
> 
> THE PROBLEM
> ------------------
> 
> Someone has a block of IP addresses to divvy up among
> a set of different organizations. Let's say the address block has
> 100 addresses, and there are 4 organizations. One strategy might be
> to give each organization 1/4 of the IP addresses each, and then 
> possibly even
> wind up having separate IP subnets (if the addresses can be assigned
> to be in different prefixes).
> 
> The problem, though, is that you don't know in advance how 
> many addresses
> each organization will need. Perhaps even the IP address block is 
> oversubscribed,
> so that there are more potential switch ports than IP 
> addresses, and you
> just hope that not everyone connects at once (or if they do, 
> they don't
> get an IP address).
> 
> So we're going to allow basically random assignment of IP addresses
> within the IP address block to each of the four organizations.
> 
> But you still want to keep the organizations separate, as in, 
> they don't 
> see each other's traffic. They
> don't get bothered with each other's ARPs and so forth. And you don't 
> want to change the IP nodes
> (endnodes or routers)
> to know anything funny is going on.
> 
> So you use VLANs to separate the communities. A particular port
> on a switch/bridge in a L2 cloud
> is configured as to what community the attached endnode belongs to, by
> having it configured with a VLAN ID.
> 
> But you'd like all the IP nodes in the cloud, even though in different
> communities, to share the same IP router, also possibly other 
> services such
> as the DHCP server. And we don't want the IP router
> to have to know about the different communities. The IP router just
> thinks the cloud is one big happy can't-we-all-just-get-along 
> IP subnet.
> 
> But the bridges inside the L2 cloud have to somehow do two things:
> a) enforce some sort of separation between the communities, and
> b) allow them all to talk to the IP router.
> 
> So this is how they are doing this. Assign each of the 4 
> communities a 
> VLAN ID, say
> VLANs A, B, C, and D. Now what VLAN ID should the IP router 
> belong to? 
> You want it
> to be able to talk to nodes in any of the VLANs {A, B, C, or D}.
> 
> The way this is done is to declare a VLAN group known as a 
> FID (filtering
> ID for those that want to see an acronym expanded -- personally, the
> expansion of that acronym didn't help me understand what a FID is).
> So a FID is a group of VLAN IDs, say Z, A, B, C, D, with one 
> of the IDs,
> say Z, being the "primary". The IP router that serves all the 
> communities
> (in this case, A, B, C, D) will be assigned to the "primary" VLAN, in 
> this case, Z. Endnodes
> will be in one of {A, B, C, D}. IP routers serving these 
> communities will
> be assigned VLAN Z.
> 
> To clarify, if there are n communities, there will be n+1 VLANs, one
> for each of the communities, and one for the IP router(s) serving
> the communities in that IP subnet.
> 
> Switches are configured to know that {Z, A, B, C, D} is a special 
> grouping of VLANs, such
> that something transmitted from a VLAN Z port goes to all 
> ports in the 
> group, i.e., all ports in
> Z, A, B, C, and D. However, something transmitted from a VLAN A port 
> goes only to ports in
> VLAN A and VLAN Z. Something from VLAN B goes to ports in 
> VLAN B and VLAN Z.
> 
> *************
> Now a little quiz...
> 
> For those of you that are following-- and in case I actually have 
> captured the concept,
> let me ask a question.
> 
> How do two endnodes in the IP subnet talk to each other?
> The first case is two endnodes in VLAN A, say S and D.
> S, observing that D is in the same subnet, will ARP. Since D 
> is in the 
> same VLAN, it will receive
> the ARP request, and respond. Everything works fine.
> 
> But how do two endnodes in different VLANs, but in the same 
> IP address 
> block communicate? S will
> ARP, like before, because IP nodes are (blissfully) unaware of VLANs. 
> The answer people tell me
> is "in that case communication between S and D has to go 
> through the IP 
> router". OK. So how would
> that work? The
> answer I get is "the switch does proxy ARP on behalf of the 
> IP router". 
> I don't understand that. How does the
> switch know *when* to proxy ARP? The switch doesn't necessarily know 
> which VLAN node D is in.
> 
> *******************
> Well, bravely continuing on...
> 
> 
> 
> Endnode MAC address learning is done by VLAN as before. If a frame is
> received by bridge b on
> port p, with source S, from VLAN A, then bridge b remembers that {S, 
> VLAN A} is on port p.
> 
> Furthermore, a Z-tagged unicast frame is checked against the learning
> tables of Z, A, B, C, D, to determine where to forward it. So 
> if bridge 
> b receives
> a frame with
> destination=D, bridge b checks for D in any of the VLANs Z, 
> A, B, C, D, and
> forwards accordingly.
> 
> 
> 
> &&&&&&&&&&&&&&&&&
> So, that's how bridges work (I hope). So how would we support this 
> functionality in
> RBridges?
> 
> As it turns out, despite the complexity of the concept,
> it will not be that difficult to support this with RBridges, and
> even in a somewhat more optimal way, since RBridges can do multicast
> filtering within the core rather that just at the final port.
> 
> RBridges, like bridges, would have to be configured with FIDs, i.e., 
> VLAN groupings as described above.
> 
> Let's call a FID by the name of the "primary" VLAN; in our example, Z.
> 
> RB1 would be configured that FID Z = {Z, A,B,C, D}, where Z, 
> A, B, C, D are
> all 12-bit VLAN IDs.
> 
> To avoid requiring configuration of all RBridges with these FIDs, and
> still allow multicast filtering, I propose we have RBridges advertise,
> in their IS-IS core instance, FIDs that they are configured 
> with. So at 
> least one RBridge will say "Hey guys,
> I think VLANs Z, A, B, C, and D form a FID with primary=Z" 
> and the other 
> RBridges will, I guess
> believe him.
> 
> What to do if RB1 says that FID Z = {Z, A, B, C, D}, and RB2 says that
> FID Z = {Z,A,D, F} is an interesting question, but at least there is
> enough information to log an error. Lot of possibilities for 
> overlapping 
> FIDs, inconsistent FIDs, etc.
> I assume all those will be errors. If there is a FID called "Z", then 
> everyone better agree about what the
> VLAN membership of Z is, and none of the VLANs in Z better be in any 
> other FIDs.
> 
> Once there is a FID of {Z, A, B, C, D}, there will no longer be
> a VLAN-A instance of IS-IS, or a VLAN-B instance of IS-IS, or C or D. 
> Instead
> the Z-instance will announce VLANs A, B, C, and D membership 
> as well as 
> VLAN Z membership.
> 
> The Z-instance of IS-IS will specify which MAC addresses are 
> in which VLAN.
> So, RB1 might announce, in the Z-instance, {Z; a, b, q, d, f},
> {A; r, n, j}, {B; c, p, o, h}, {C; m,l}, {D;g, x, k}. The lower case 
> letters are endnode MAC
> addresses. The upper case letters are 12-bit VLAN IDs.
> 
> Multicast packets marked as VLAN Z (inner VLAN) will be sent to
> all links in Z, A, B, C, or D. So the LSPs in the VLAN Z instance of 
> IS-IS will
> be delivered to all RBridges in Z, A, B, C, and D.
> 
> That way RBridges with ports in Z, A, B, C, and/or D will 
> learn all the 
> endnode addresses
> in any of those VLANs (all the ports in FID Z).
> 
> If ingress RB1 is attached to Z, and receives a packet with
> destination D tagged as Z, RB1 checks for D in VLANs A, B, C, 
> D, and Z 
> 's endnode
> membership. As soon as RB1 finds it, let's say, as reported by
> RB2 as being in VLAN D, RB1 tunnels the packet in TRILL to RB2,
> leaving the tag as Z. When RB2 decapsulates the packet, I 
> assume it will
> rewrite the inner VLAN tag from "Z" to "D".
> 
> 
> &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
> Conclusions:
> 
> The changes to the spec:
> 
> a) announce in the core instance, FIDs as a set of VLANs, the
> first listed being the "primary".
> 
> b) multicast forwarding: if the packet is (inner) tagged with
> the VLAN ID of a primary VLAN in a FID, forward the packet on
> all in the links in the selected tree that lead to any of the VLANs
> in the FID. If the packet is tagged with the VLAN ID of a non-primary
> VLAN in a FID, forward the packet on all the ports that reach
> links in either that VLAN or in the primary VLAN for that FID.
> 
> c) when ingressing a packet with destination D, tagged with a
> VLAN tag of a primary VLAN in a FID, check the endnode information
> for all the VLANs in the FID to determine the egress RBridge.
> 
> d) when ingressing a packet with destination D, tagged with
> a VLAN tag of a secondary VLAN in a FID, check the endnode
> information for exactly two VLANs; the one the packet is
> currently tagged with, and the primary VLAN for that FID, to
> determine the egress RBridge.
> 
> e) if two RBridges, in the core instance, report inconsistent FID 
> membership, what should we do?
> 
> (Note: There was a fortune cookie program in Unix, one of the 
> fortunes 
> being "Never check for an error
> condition that you don't know how to handle". For the record--I think 
> that's a cute joke but really bad policy.).
> 
> Radia
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>