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 2743421F1D2 for ; Sun, 25 Jan 2015 12:17:29 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp13.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 3E1EE1000D5; Sun, 25 Jan 2015 15:17:28 -0500 (EST) X-Virus-Scanned: OK Received: from app20.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp13.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 1BD641000A0; Sun, 25 Jan 2015 15:17:28 -0500 (EST) X-Sender-Id: dpreed@reed.com Received: from app20.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.4.2); Sun, 25 Jan 2015 20:17:28 GMT Received: from reed.com (localhost.localdomain [127.0.0.1]) by app20.wa-webapps.iad3a (Postfix) with ESMTP id 06C9A80041; Sun, 25 Jan 2015 15:17:28 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Sun, 25 Jan 2015 15:17:28 -0500 (EST) Date: Sun, 25 Jan 2015 15:17:28 -0500 (EST) From: dpreed@reed.com To: "David Lang" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20150125151728000000_45326" 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> X-Auth-ID: dpreed@reed.com Message-ID: <1422217048.025611275@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: Sun, 25 Jan 2015 20:17:58 -0000 ------=_20150125151728000000_45326 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0ADisagree. See below.=0A=0A=0AOn Saturday, January 24, 2015 11:35pm, "Dav= id Lang" said:=0A=0A=0A=0A> On Sat, 24 Jan 2015, dpreed@ree= d.com wrote:=0A> > A side comment, meant to discourage continuing to bridge= rather than route.=0A> >=0A> > There's no reason that the AP's cannot have= different IP addresses, but a=0A> > common ESSID. Roaming between them wou= ld be like roaming among mesh subnets.=0A> > Assuming you are securing your= APs' air interfaces using encryption over the=0A> > air, you are already r= e-authenticating as you move from AP to AP. So using=0A> > routing rather t= han bridging is a good idea for all the reasons that routing=0A> > rather t= han bridging is better for mesh.=0A> =0A> The problem with doing this is th= at all existing TCP connections will break when=0A> you move from one AP to= another and while some apps will quickly notice this and=0A> establish new= connections, there are many apps that will not and this will cause=0A> not= icable disruption to the user.=0A> =0A> Bridgeing allows the connections to= remain intact. The wifi stack re-negotiates=0A> the encryption, but the en= capsulated IP packets don't change.=0A=0A=0AThere is no reason why one cann= ot set up an enterprise network to support roaming, yet maintaining the pro= perty that IP addresses don't change while roaming from AP to AP. Here's a= simple concept, that amounts to moving what would be in the Ethernet bridg= ing tables up to the IP layer.=0A =0AAll addresses in the enterprise are as= signed from a common prefix (XXX/16 in IPv4, perhaps). Routing in each acc= ess point is used to decide whether to send the packet on its LAN, or to re= flect it to another LAN. A node's preferred location would be updated by t= he endpoint itself, sending its current location to its current access poin= t (via ARP or some other protocol). The access point that hears of a new = node that it can reach tells all the other access points that the node is a= ttached to it. Delivery of a packet to a node is done by the access point = that receives the packet by looking up the destination IP address in its lo= cal table, and sending it to the access point that currently has the destin= ation IP address.=0A =0AThis is far better than "bridging" at the Ethernet = level from a functionality point of view - it is using routing, not bridgin= g. Bridging at the Ethernet level uses Ethernet's STP feature, which doesn= 't work very well in collections of wireless LAN's (it is slow to recalcula= te when something moves, because it was designed for unplug/plug of actual = cables, and moving the host from one physical location to another).=0A =0AI= MO, Ethernet sometimes aspires to solve problems that are already well-solv= ed in the Internet protocols. (for example the 802.11s mess which tries to = do a mesh entirely in the Ethernet layer, and fails pretty miserably).=0AOf= course that's only my opinion, but I think it applies to overuse of bridgi= ng at the Ethernet layer when there are better approaches at the next layer= up. ------=_20150125151728000000_45326 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Disagree. See below.

= =0A=0A



On Saturday, January 24, 2015 11:35pm, "David Lang= " <david@lang.hm> said:

=0A
=0A

> On Sat, 24 Jan 2015, dpreed@reed.com wrote:=
> > A side comment, meant to discourage continuing to bridge ra= ther than route.
> >
> > There's no reason that the A= P's cannot have different IP addresses, but a
> > common ESSID. = Roaming between them would be like roaming among mesh subnets.
> &g= t; Assuming you are securing your APs' air interfaces using encryption over= the
> > air, you are already re-authenticating as you move from= AP to AP. So using
> > routing rather than bridging is a good i= dea for all the reasons that routing
> > rather than bridging is= better for mesh.
>
> The problem with doing this is that = all existing TCP connections will break when
> you move from one AP= to another and while some apps will quickly notice this and
> esta= blish new connections, there are many apps that will not and this will caus= e
> noticable disruption to the user.
>
> Bridgein= g allows the connections to remain intact. The wifi stack re-negotiates
> the encryption, but the encapsulated IP packets don't change.
<= br />

=0A

There is no reason why one cannot set up an e= nterprise network to support roaming, yet maintaining the property that IP = addresses don't change while roaming from AP to AP.  Here's a simple c= oncept, that amounts to moving what would be in the Ethernet bridging table= s up to the IP layer.

=0A

 

=0A

 

=0A

This is far bette= r than "bridging" at the Ethernet level from a functionality point of view = - it is using routing, not bridging.  Bridging at the Ethernet level u= ses Ethernet's STP feature, which doesn't work very well in collections of = wireless LAN's (it is slow to recalculate when something moves, because it = was designed for unplug/plug of actual cables, and moving the host from one= physical location to another).

=0A

 

=0A

IMO, Ethernet sometimes aspires to solve problems that are alre= ady well-solved in the Internet protocols. (for example the 802.11s mess wh= ich tries to do a mesh entirely in the Ethernet layer, and fails pretty mis= erably).

=0A

Of course that's only my opinion, but I th= ink it applies to overuse of bridging at the Ethernet layer when there are = better approaches at the next layer up.

=0A
 ------=_20150125151728000000_45326--