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

[Eric Gray (LO/EUS)]

JR,

	I agree.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: J. R. Rivers [mailto:jrrivers at nuovasystems.com] 
> Sent: Monday, April 02, 2007 6:52 PM
> To: Eric Gray (LO/EUS); Radia Perlman; rbridge at postel.org
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] Shared VLAN learning: What is it and 
> why should wecare?
> Importance: High
> 
>  
> These are issues that are commonly dealt with today when 
> routers (either
> stand alone or "merged L3 switches") face this situation today.  I
> suggest focusing TRILL on retaining compatibility with today's
> expectations rather than altering them in any way.
> 
> JR
> 
> 
> > -----Original Message-----
> > From: rbridge-bounces at postel.org 
> > [mailto:rbridge-bounces at postel.org] On Behalf Of Eric Gray (LO/EUS)
> > Sent: Monday, April 02, 2007 1:50 PM
> > To: Radia Perlman
> > Cc: rbridge at postel.org
> > Subject: Re: [rbridge] Shared VLAN learning: What is it and 
> > why should wecare?
> > 
> > Radia,
> > 
> > 	There is an interesting problem that might arise out of
> > a router receiving VLAN tagged frames without being aware that
> > they are tagged.  
> > 
> > 	A router is a MAC termination point - i.e. - it is an 
> > end-station at the MAC layer.  But it is also a forwarding
> > device.  Hence the slack that might apply to a host receiving
> > a MAC frame with "stuff" in the header it doesn't understand,
> > shouldn't be allowed for a router.
> > 
> > 	Also, many routers do understand that it is possible to
> > have the same IP subnet connected to multiple logical interfaces.
> > That was where the original "Bridging Router" (or BRouter) came
> > from.
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson  
> > 
> > > -----Original Message-----
> > > From: Radia Perlman [mailto:Radia.Perlman at sun.com] 
> > > Sent: Monday, April 02, 2007 4:10 PM
> > > To: Eric Gray (LO/EUS)
> > > Cc: rbridge at postel.org
> > > Subject: Re: [rbridge] Shared VLAN learning: What is it and 
> > > why should we care?
> > > Importance: High
> > > 
> > > My understanding is that shared VLANs assume
> > > IP routers are not aware of VLANs.
> > > 
> > > My understanding is that the way it would work if the IP 
> > > router R *was* 
> > > aware of
> > > VLANs, is that R would treat the link as 4 separate links 
> (by using 
> > > VLANs), and then the IP addresses
> > > on the 4 different links (VLANs A, B, C, and D) would 
> have to have 
> > > different IP prefixes.
> > > 
> > > So therefore, I am assuming that the IP router is not 
> > > supposed to know 
> > > that the link is subdivided into VLANs.
> > > 
> > > So my understanding of the problem in this case is:
> > > 
> > > a) single IP address block shared by different communities
> > > b) desire to isolate these communities from layer 2 
> > broadcast traffic 
> > > from each other
> > > c) desire to share some services (like DHCP and IP 
> > routers), without 
> > > those services being aware
> > > that the communities are separate
> > > 
> > > As for my question about proxy ARP, to further add
> > > to the confusion -- some people are assuming the 
> > > bridge/RBridge will be 
> > > doing
> > > the proxy ARP, and some others are assuming the router is.
> > > 
> > > And actually, after talking offline with Joel Halpern, I'll 
> > > send another 
> > > note with two different proposals
> > > (one just a cleanup of what I originally wrote, and the other a 
> > > different approach) for solving
> > > that vaguely stated problem.
> > > 
> > > Radia
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Eric Gray (LO/EUS) wrote:
> > > 
> > > >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
> > > >>
> > > >>    
> > > >>
> > > 
> > > 
> > 
> > _______________________________________________
> > rbridge mailing list
> > rbridge at postel.org
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
>