From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp121.iad3a.emailsrvr.com (smtp121.iad3a.emailsrvr.com [173.203.187.121]) (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 69E2821F200 for ; Sun, 25 Jan 2015 19:18:00 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp16.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id A546718026C; Sun, 25 Jan 2015 22:17:59 -0500 (EST) X-Virus-Scanned: OK Received: from app44.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp16.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 838B3180267; Sun, 25 Jan 2015 22:17:59 -0500 (EST) X-Sender-Id: dpreed@reed.com Received: from app44.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 03:17:59 GMT Received: from reed.com (localhost.localdomain [127.0.0.1]) by app44.wa-webapps.iad3a (Postfix) with ESMTP id 711D118004A; Sun, 25 Jan 2015 22:17:59 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Sun, 25 Jan 2015 22:17:59 -0500 (EST) Date: Sun, 25 Jan 2015 22:17:59 -0500 (EST) From: dpreed@reed.com To: "Dave Taht" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20150125221759000000_55780" 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> <1422237076.005718796@apps.rackspace.com> X-Auth-ID: dpreed@reed.com Message-ID: <1422242279.46066942@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 03:18:29 -0000 ------=_20150125221759000000_55780 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0ALooking up an address in a routing table is o(1) if the routing table is= a hash table. That's much more efficient than a TCAM. My simple example = just requires a delete/insert at each node's route lookup table.=0A =0AMy p= oint was about collections of WLAN's bridged together. Look at what happen= s (at the packet/radio layer) when a new node joins a bridged set of WLANs = using STP. It is not exactly simple to rebuild the Ethernet layer's bridge= routing tables in a complex network. And the limit of 4096 entries in man= y inexpensive switches is not a trivial limit.=0A =0ARouters used to be mem= ory-starved (a small number of KB of RAM was the norm). Perhaps the thinki= ng then (back before 2000) has not been revised, even though the hardware i= s a lot more capacious.=0A =0ARemember, the Ethernet layer in WLANs is impl= emented by microcontrollers, typically not very capable ones, plus TCAMs wh= ich are pretty limited in their flexibility.=0A =0AWhile it is tempting to = use the "pre-packaged, proprietary" Ethernet switch functionality, routing = gets you out of the binary blobs, and let's you be a lot smarter and more s= calable. Given that it does NOT cost more to do routing at the IP layer, b= uilding complex Ethernet bridging is not obviously a win.=0A =0ABTW, TCAMs = are used in IP layer switching, too, and also are used in packet filtering.= Maybe not in cheap consumer switches, but lots of Gigabit switches implem= ent IP layer switching and filtering. At HP, their switches routinely did = all their IP layer switching entirely in TCAMs.=0A=0A=0AOn Sunday, January = 25, 2015 9:58pm, "Dave Taht" said:=0A=0A=0A=0A> On Su= n, Jan 25, 2015 at 6:43 PM, David Lang wrote:=0A> > On Sun,= 25 Jan 2015, Dave Taht wrote:=0A> >=0A> >> To your roaming point, yes this= is certainly one place where migrating=0A> >> bridged vms across machines = breaks down, and yet more and more vm=0A> >> layers are doing it. I would c= ertainly prefer routing in this case.=0A> >=0A> >=0A> > What's the differen= ce between "roaming" and moving a VM from one place in=0A> > the network to= another?=0A> =0A> I think most people think of "roaming" as moving fairly = rapidly from one=0A> piece of edge connectivity to another, and moving a vm= is a great deal more=0A> permanent operation.=0A> =0A> > As far as layer 2= vs layer 3 goes. If you try to operate at layer 3, you are=0A> > going to = have quite a bit of smarts in the endpoint. Even if it's only=0A> > connect= ed vi a single link. If you think about it, even if your network=0A> > rout= ing tables list every machine in our environment individually, you still=0A= > > have a problem of what gateway the endpoint uses. It would have to chan= ge=0A> > every time it moved. Since DHCP doesn't update frequently enough t= o be=0A> > transparent, you would need to have each endpoint running a rout= ing=0A> > protocol.=0A> =0A> Hmm? I don't ever use a dhcp-supplied default = gateway, I depend on the routing=0A> protocol to supply that. In terms of e= ach vm running a routing protocol,=0A> well, no, I would rely on the underl= ying bare metal OS to be doing=0A> that, supplying=0A> the FIB tables to th= e overlying vms, if they need it, but otherwise the vms=0A> just see a "def= ault" route and don't bother with it. They do need to inform the=0A> bare m= etal OS (better term for this please? hypervisor?) of what IPs they own.=0A= > =0A> static default gateways are evil. and easily disabled. in linux you= =0A> merely comment=0A> out the "routers" in /etc/dhcp/dhclient.conf, in op= enwrt, set=0A> "defaultroute 0" for the=0A> interface fetching dhcp.=0A> = =0A> When a box migrates, it tells the hypervisor it's addresses, and then = that box=0A> propagates out the route change to elsewhere.=0A> =0A> >=0A> >= This can work for individual hobbiests, but not when you need to support= =0A> > random devices (how would you configure an iPhone to support this?)= =0A> =0A> Carefully. :)=0A> =0A> I do note that this stuff does (or at leas= t did) work on some of the open=0A> source variants of android. I would rat= her like it if android added ipv6=0A> tethering soon, and made it possible = to mesh together multiple phones.=0A> =0A> >=0A> >=0A> > Letting the layer = 2 equipment deal with the traffic within the building and=0A> > invoking la= yer 3 to go outside the building (or to a different security=0A> > domain) = makes a lot of sense. Even if that means that layer 2 within a=0A> > buildi= ng looks very similar to what layer 3 used to look like around a city.=0A> = =0A> Be careful what you wish for.=0A> =0A> >=0A> >=0A> > back to the topic= of wifi, I'm not aware of any APs that participate in the=0A> > switch pro= tocols at this level. I also don't know of any reasonably priced=0A> > swit= ches that can do anything smarter than plain spanning tree when=0A> > conne= cted through multiple paths (I'd love to learn otherwise)=0A> >=0A> > David= Lang=0A> =0A> =0A> =0A> --=0A> Dave T=C3=A4ht=0A> =0A> thttp://www.bufferb= loat.net/projects/bloat/wiki/Upcoming_Talks=0A> ------=_20150125221759000000_55780 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Looking up an address in= a routing table is o(1) if the routing table is a hash table.  That's= much more efficient than a TCAM.  My simple example just requires a d= elete/insert at each node's route lookup table.

=0A

&nb= sp;

=0A

My point was about collections of WLAN's bridge= d together.  Look at what happens (at the packet/radio layer) when a n= ew node joins a bridged set of WLANs using STP.  It is not exactly sim= ple to rebuild the Ethernet layer's bridge routing tables in a complex netw= ork.  And the limit of 4096 entries in many inexpensive switches is no= t a trivial limit.

=0A

 

=0A

R= outers used to be memory-starved (a small number of KB of RAM was the norm)= .  Perhaps the thinking then (back before 2000) has not been revised, = even though the hardware is a lot more capacious.

=0A

&= nbsp;

=0A

Remember, the Ethernet layer in WLANs is impl= emented by microcontrollers, typically not very capable ones, plus TCAMs wh= ich are pretty limited in their flexibility.

=0A

 =

=0A

While it is tempting to use the "pre-packaged, pro= prietary" Ethernet switch functionality, routing gets you out of the binary= blobs, and let's you be a lot smarter and more scalable.  Given that = it does NOT cost more to do routing at the IP layer, building complex Ether= net bridging is not obviously a win.

=0A

 

=0A<= p style=3D"margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wr= ap: break-word;">BTW, TCAMs are used in IP layer switching, too, and also a= re used in packet filtering.  Maybe not in cheap consumer switches, bu= t lots of Gigabit switches implement IP layer switching and filtering. &nbs= p;At HP, their switches routinely did all their IP layer switching ent= irely in TCAMs.

=0A=0A



On Sunday, January 25, 2015 9:5= 8pm, "Dave Taht" <dave.taht@gmail.com> said:

=0A
=0A

> On Sun, Jan 25, 2015 a= t 6:43 PM, David Lang <david@lang.hm> wrote:
> > On Sun, 2= 5 Jan 2015, Dave Taht wrote:
> >
> >> To your roam= ing point, yes this is certainly one place where migrating
> >&g= t; bridged vms across machines breaks down, and yet more and more vm
&= gt; >> layers are doing it. I would certainly prefer routing in this = case.
> >
> >
> > What's the difference be= tween "roaming" and moving a VM from one place in
> > the networ= k to another?
>
> I think most people think of "roaming" a= s moving fairly rapidly from one
> piece of edge connectivity to an= other, and moving a vm is a great deal more
> permanent operation.<= br />>
> > As far as layer 2 vs layer 3 goes. If you try to = operate at layer 3, you are
> > going to have quite a bit of sma= rts in the endpoint. Even if it's only
> > connected vi a single= link. If you think about it, even if your network
> > routing t= ables list every machine in our environment individually, you still
&g= t; > have a problem of what gateway the endpoint uses. It would have to = change
> > every time it moved. Since DHCP doesn't update freque= ntly enough to be
> > transparent, you would need to have each e= ndpoint running a routing
> > protocol.
>
> Hmm= ? I don't ever use a dhcp-supplied default gateway, I depend on the routing=
> protocol to supply that. In terms of each vm running a routing p= rotocol,
> well, no, I would rely on the underlying bare metal OS t= o be doing
> that, supplying
> the FIB tables to the overly= ing vms, if they need it, but otherwise the vms
> just see a "defau= lt" route and don't bother with it. They do need to inform the
> ba= re metal OS (better term for this please? hypervisor?) of what IPs they own= .
>
> static default gateways are evil. and easily disable= d. in linux you
> merely comment
> out the "routers" in /et= c/dhcp/dhclient.conf, in openwrt, set
> "defaultroute 0" for the> interface fetching dhcp.
>
> When a box migrates, = it tells the hypervisor it's addresses, and then that box
> propaga= tes out the route change to elsewhere.
>
> >
> = > This can work for individual hobbiests, but not when you need to suppo= rt
> > random devices (how would you configure an iPhone to supp= ort this?)
>
> Carefully. :)
>
> I do not= e that this stuff does (or at least did) work on some of the open
>= source variants of android. I would rather like it if android added ipv6> tethering soon, and made it possible to mesh together multiple pho= nes.
>
> >
> >
> > Letting the la= yer 2 equipment deal with the traffic within the building and
> >= ; invoking layer 3 to go outside the building (or to a different security> > domain) makes a lot of sense. Even if that means that layer 2= within a
> > building looks very similar to what layer 3 used t= o look like around a city.
>
> Be careful what you wish fo= r.
>
> >
> >
> > back to the topi= c of wifi, I'm not aware of any APs that participate in the
> > = switch protocols at this level. I also don't know of any reasonably priced<= br />> > switches that can do anything smarter than plain spanning tr= ee when
> > connected through multiple paths (I'd love to learn = otherwise)
> >
> > David Lang
>
> >
> --
> Dave T=C3=A4ht
>
> thttp:= //www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
>

=0A<= /div> ------=_20150125221759000000_55780--