From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp97.iad3a.emailsrvr.com (smtp97.iad3a.emailsrvr.com [173.203.187.97]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id A862921F1CF for ; Sun, 25 Jan 2015 17:51:17 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp21.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 372CE18024F; Sun, 25 Jan 2015 20:51:16 -0500 (EST) X-Virus-Scanned: OK Received: from app30.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp21.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 1739C18024B; Sun, 25 Jan 2015 20:51:16 -0500 (EST) X-Sender-Id: dpreed@reed.com Received: from app30.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.4.2); Mon, 26 Jan 2015 01:51:16 GMT Received: from reed.com (localhost.localdomain [127.0.0.1]) by app30.wa-webapps.iad3a (Postfix) with ESMTP id 01D7480012; Sun, 25 Jan 2015 20:51:16 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Sun, 25 Jan 2015 20:51:16 -0500 (EST) Date: Sun, 25 Jan 2015 20:51:16 -0500 (EST) From: dpreed@reed.com To: "David Lang" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20150125205116000000_39485" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <54B5D28A.3010906@gmail.com> <7B1EA8F0-FCB6-4A37-950F-2558FC751DE8@gmail.com> <54C038D0.1000305@gmail.com> <54C0BD22.3000608@gmail.com> <54C13F47.1010203@gmail.com> <1422111577.328132080@apps.rackspace.com> <1422217048.025611275@apps.rackspace.com> X-Auth-ID: dpreed@reed.com Message-ID: <1422237076.005718796@apps.rackspace.com> X-Mailer: webmail/11.3.10-RC Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] =?utf-8?q?Recording_RF_management_info_=5Fand=5F_?= =?utf-8?q?associated_traffic=3F?= X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 01:51:47 -0000 ------=_20150125205116000000_39485 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AIf you are using Ethernet bridging, your Ethernet switches are doing exa= ctly this at the Ethernet layer... they have large tables of MAC addresses = that are known throughout the network, and for each MAC address in the Ente= rprise, they have the next hop destination.=0A =0ASo IP routing tables, one= IP address per destination in the Enterprise, would occupy no more space t= han do the Ethernet routing tables.... so any argument about space efficie= ncy is mooted.=0A =0AThis is why bridging is no better than routing - you h= ave to solve the same problem at one layer or the other. The Ethernet layer= 's "solution" is actually very suboptimal, especially when roaming is going= on.=0A=0A=0AOn Sunday, January 25, 2015 6:57pm, "David Lang" said:=0A=0A=0A=0A> On Sun, 25 Jan 2015, dpreed@reed.com wrote:=0A> =0A> = > Disagree. See below.=0A> >=0A> >=0A> > On Saturday, January 24, 2015 11:3= 5pm, "David Lang" =0A> said:=0A> >=0A> >=0A> >=0A> >> On Sat= , 24 Jan 2015, dpreed@reed.com wrote:=0A> >> > A side comment, meant to dis= courage continuing to bridge rather than=0A> route.=0A> >> >=0A> >> > There= 's no reason that the AP's cannot have different IP addresses,=0A> but a=0A= > >> > common ESSID. Roaming between them would be like roaming among mesh= =0A> subnets.=0A> >> > Assuming you are securing your APs' air interfaces u= sing encryption=0A> over the=0A> >> > air, you are already re-authenticatin= g as you move from AP to AP. So=0A> using=0A> >> > routing rather than brid= ging is a good idea for all the reasons that=0A> routing=0A> >> > rather th= an bridging is better for mesh.=0A> >>=0A> >> The problem with doing this i= s that all existing TCP connections will=0A> break when=0A> >> you move fro= m one AP to another and while some apps will quickly notice=0A> this and=0A= > >> establish new connections, there are many apps that will not and this= =0A> will cause=0A> >> noticable disruption to the user.=0A> >>=0A> >> Brid= geing allows the connections to remain intact. The wifi stack=0A> re-negoti= ates=0A> >> the encryption, but the encapsulated IP packets don't change.= =0A> >=0A> >=0A> > There is no reason why one cannot set up an enterprise n= etwork to support=0A> > roaming, yet maintaining the property that IP addre= sses don't change while=0A> > roaming from AP to AP. Here's a simple concep= t, that amounts to moving what=0A> > would be in the Ethernet bridging tabl= es up to the IP layer.=0A> >=0A> > All addresses in the enterprise are assi= gned from a common prefix (XXX/16 in=0A> > IPv4, perhaps). Routing in each = access point is used to decide whether to=0A> > send the packet on its LAN,= or to reflect it to another LAN. A node's=0A> > preferred location would b= e updated by the endpoint itself, sending its=0A> > current location to its= current access point (via ARP or some other=0A> protocol).=0A> > The acces= s point that hears of a new node that it can reach tells all the=0A> > othe= r access points that the node is attached to it. Delivery of a packet to=0A= > > a node is done by the access point that receives the packet by looking = up the=0A> > destination IP address in its local table, and sending it to t= he access point=0A> > that currently has the destination IP address.=0A> >= =0A> > This is far better than "bridging" at the Ethernet level from a func= tionality=0A> > point of view - it is using routing, not bridging. Bridging= at the Ethernet=0A> > level uses Ethernet's STP feature, which doesn't wor= k very well in=0A> collections=0A> > of wireless LAN's (it is slow to recal= culate when something moves, because it=0A> > was designed for unplug/plug = of actual cables, and moving the host from one=0A> > physical location to a= nother).=0A> >=0A> > IMO, Ethernet sometimes aspires to solve problems that= are already=0A> well-solved=0A> > in the Internet protocols. (for example = the 802.11s mess which tries to do a=0A> > mesh entirely in the Ethernet la= yer, and fails pretty miserably).=0A> >=0A> > Of course that's only my opin= ion, but I think it applies to overuse of=0A> > bridging at the Ethernet la= yer when there are better approaches at the next=0A> > layer up.=0A> =0A> U= nless you are going to have your routing tables handle every address in you= r=0A> network separately (and fix all the software that depends on broadcas= ts) you are=0A> going to have trouble trying to do this at the IP layer.=0A= > =0A> The 'modern Enterprise' datacenter has lots of large machines that g= et sliced=0A> into multiple virtual machines. For redundancy purposes you w= ant to have the=0A> machines used for a particular job to be spread across = as many of these machines=0A> as possible, spread around your datacenter.= =0A> =0A> Switches in this environment are becoming layer 2 routers. They a= re connected=0A> together with multiple links providing redundant paths aro= und the network. This=0A> isn't being done with Spanning Tree because Spann= ing Tree only allows one path=0A> to exist at once, and that is inefficient= and creates bottlenecks. As a result,=0A> they are now keeping all these l= inks live at the same time and using least cost=0A> paths to route the laye= r 2 traffic across the switches.=0A> =0A> It's fair to argue that this is a= buse of layer 2, but the difficulties in having=0A> to change the software = operating at higher layers vs the fact that making these=0A> changes at the= layer 2 level is completely transparent to the higher layers make=0A> it s= o that using this layer 2 capability is pragmantically a far better choice.= =0A> =0A> The Computer Scientist will cringe at the 'hacks' that this intro= duces, but=0A> there is far more progress made when new capabilities can be= added in a way=0A> that's transparent to other layers of the stack then wh= en it requires major=0A> changes to how things work.=0A> =0A> The software = layer is the worst to try and force fundamental changes to. You=0A> would b= e horrified to learn how old some of the software is that's running major= =0A> jobs at large companies. Even if the software is in continuous develop= ment, the=0A> age of the core software frequently shows.=0A> =0A> David Lan= g=0A> ------=_20150125205116000000_39485 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

If you are using Etherne= t bridging, your Ethernet switches are doing exactly this at the Ethernet l= ayer... they have large tables of MAC addresses that are known throughout t= he network, and for each MAC address in the Enterprise, they have the next = hop destination.

=0A

 

=0A

So = IP routing tables, one IP address per destination in the Enterprise, would = occupy no more space than do the Ethernet routing tables....  so any a= rgument about space efficiency is mooted.

=0A

 =0A

This is why bridging is no better than routing - you = have to solve the same problem at one layer or the other. The Ethernet laye= r's "solution" is actually very suboptimal, especially when roaming is goin= g on.

=0A