Mark you can always reach out to me. I can help make sure the correct technical requirements are outlined. I also have been working closely on BnB so there may be some overlap we can help avoid.
========================================= John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozow...@cable.comcast.com o) 609-377-6594 w) www.comcast6.net ========================================= -----Original Message----- From: Mark Townsley <m...@townsley.net> Date: Friday, February 22, 2013 9:24 AM To: John Jason Brzozowski <john_brzozow...@cable.comcast.com> Cc: Dave Taht <dave.t...@gmail.com>, Michael Richardson <mcr+i...@sandelman.ca>, Jari Arkko <jari.ar...@piuha.net>, "homenet@ietf.org Group" <homenet@ietf.org>, David Lamparter <equi...@diac24.net>, Lorenzo Colitti <lore...@google.com> Subject: Re: [homenet] Running code in Orlando > >On Feb 21, 2013, at 5:57 PM, Brzozowski, John wrote: > >> Since BnB is one night can we make provisions for the home net lab area >>to >> be open all week? Mark? Ray? > >Let's give it a shot! > >But... the chairs can only make the request. Allocating IETF space is >something only the ADs are authorized to do. In Atlanta, I asked for >space and was turned down (citing too short notice, specs not mature >enough, etc.). IPSO graciously gave us some squatting room, but we were >not able to get what we needed from the IETF NOC in that particular >location. So, while good work was done, it came with support headaches >(e.g., ISP uplinks were simulated via tunnels sourced from a router than >joined the IETF network like any other wireless host). > >> Seems like it would be worth it. I am thinking all week would be ideal. >> ;) > >I think that's a necessity. The request I sent in January to the list >included: "Note that this isn't for 'showcasing', but for working... so >be expected to configure, reconfigure, and change code on the fly >accordingly." I think that is very important, and in order for that to >happen, we need more than a couple of hours here or there. > >What I am hearing is that we currently have requests to provide workspace >for: > >1. draft-grundemann-homenet-hipnet-00 >2. perhaps CeroWRT? >3. perhaps draft-arkko-homenet-prefix-assignment and >draft-ietf-ospf-ospfv3-autoconfig again? > >Last time, we were asked from the ADs things like: > >- How many implementations existed and how many would be present on site >to test. >- What drafts or RFCs would be tested >- How much space, and for how long >- Power and network requirements >etc... > >John B, Dave T, are the two of you the right folks for us to work offline >with in order to try and put together the right ask? > >Thanks, > >- Mark > > >> >> ========================================= >> John Jason Brzozowski >> Comcast Cable >> m) 484-962-0060 >> e) john_brzozow...@cable.comcast.com >> o) 609-377-6594 >> w) www.comcast6.net >> ========================================= >> >> >> >> >> >> >> >> -----Original Message----- >> From: Dave Taht <dave.t...@gmail.com> >> Date: Thursday, February 21, 2013 9:35 AM >> To: John Jason Brzozowski <john_brzozow...@cable.comcast.com> >> Cc: David Lamparter <equi...@diac24.net>, Michael Richardson >> <mcr+i...@sandelman.ca>, "homenet@ietf.org Group" <homenet@ietf.org>, >>Mark >> Townsley <m...@townsley.net>, Jari Arkko <jari.ar...@piuha.net>, Lorenzo >> Colitti <lore...@google.com> >> Subject: Re: [homenet] Running code in Orlando >> >>> >>> >>> >>> I am primarily focused on demonstrating solutions to bufferbloat in my >>> portion of bit's and bytes. >>> >>> But I note that the present CeroWrt build appears to have working >>>dhcp-pd >>> (I've successfully got /56 /60, /61/ /62 subnets from it), and >>>assigning >>> that to the 6+ internal interfaces, support for every other form of >>>ipv6 >>> tunneling, the latest dnsmasq which has >>> some good ways of bonding dns names to ipv6 AAAAs, support for routing >>> ipv4 and ipv6 subnetworks over the quagga babel protocol (the two >>>routers >>> I'm demoing are meshed together at 5ghz) >>> >>> We had to fix a few nasty instruction traps in the ipv6 stack last >>>month, >>> but after doing that, I'm pretty pleased with the over-all performance >>> and reliability - it survived the "thc" ipv6 tests handily, for >>>example. >>> Could use some more exaustive real-world >>> testing, so, get it (for the wndr3700v2 and 3800 series) >>> >>> http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.7.5-2/ >>> >>> We also have specialized builds for the ubiquity nanostation m5 and >>> picostation m2hp products deployed in the campground testbed. >>> >>> We still haven't done anything with distributing prefixes inside the >>>home >>> beside ahcp, and I still find the dynamicism required by renting ipv6 >>> addresses to so impact in so many aspects of the "sane usage of stuff >>> like printers", and naming, and the security >>> model as to *demand* ipv6 nat in the home... but I did not get around >>>to >>> implementing npt66 in this release!! >>> >>> >>> (so those that would flame me for this opinion can hold off (pretty >>> please!?) until perhaps I can go into the implementation details of all >>> the many things that break today... with those that care. ) >>> >>> In terms of interop, besides dhcp-pd and bufferbloat fixes, I'd rather >>> like to see if these release can be made to work with ospfv6 on other >>> devices. What else will be shown? The original homenet code was far too >>> large to be usable on such a small device, but >>> perhaps at least the ospf layer could be tried. >>> >>> And all that said, I'm rather totally buried with tests for, >>>processing a >>> ton of data from the field, and testing nfq_codel/bufferbloat. I just >>> finished giving talks on that at MIT and Stanford on that stuff >>> >>> What's wrong with wifi? >>> >>> http://www.youtube.com/watch?v=Wksh2DPHCDI&feature=youtu.be >>> >>> Intro to codel and fq_codel: >>> >>> http://netseminar.stanford.edu/ >>> >>> >>> >>> On Thu, Feb 21, 2013 at 8:14 AM, Brzozowski, John >>> <john_brzozow...@cable.comcast.com> wrote: >>> >>> Statically assigning prefixes may enable testing but is not how homes >>>will >>> be provisioned in reality. >>> >>> ========================================= >>> John Jason Brzozowski >>> Comcast Cable >>> m) 484-962-0060 <tel:484-962-0060> >>> e) john_brzozow...@cable.comcast.com >>> o) 609-377-6594 <tel:609-377-6594> >>> w) www.comcast6.net <http://www.comcast6.net> >>> ========================================= >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> >>> From: David Lamparter <equi...@diac24.net> >>> Date: Wednesday, February 20, 2013 9:41 PM >>> To: John Jason Brzozowski <john_brzozow...@cable.comcast.com> >>> Cc: David Lamparter <equi...@diac24.net>, Lorenzo Colitti >>> >>> <lore...@google.com>, Michael Richardson <mcr+i...@sandelman.ca >>> <mailto:mcr%2bi...@sandelman.ca>>, >>> "homenet@ietf.org Group" <homenet@ietf.org>, Jari Arkko >>> <jari.ar...@piuha.net>, Mark Townsley <m...@townsley.net> >>> Subject: Re: [homenet] Running code in Orlando >>> >>> >>>> On Thu, Feb 21, 2013 at 04:17:06AM +0000, Brzozowski, John wrote: >>>>> David Lamparter wrote: >>>>>> On Thu, Feb 21, 2013 at 12:40:25PM +0900, Lorenzo Colitti wrote: >>>>>>> On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson >>>>>>> <mcr+i...@sandelman.ca <mailto:mcr%2bi...@sandelman.ca>>wrote: >>>>>>> >>>>>>>> Would/could another foot of such a network be on the IETF network? >>>>>>>> >>>>>>> >>>>>>> If the IETF network didn't respond to DHCPv6 PD requests, it >>>>> wouldn't be >>>>>>> much use. >>>>>> >>>>>> Even without DHCPv6 PD on the remainder of the IETF network, it >>>>>>might >>>>> be >>>>>> possible to get a /52../56 and run a DHCPv6 PD ourselves, emulating >>>>> part >>>>>> of the provider network. >>>>> >>>>> Why emulate it? Is the intention here to test the the code on an >>>>> enterprise or corporate network? >>>> >>>> The scope of the plugfest is the interior and border of the homenet. >>>>To >>>> get the border right, we need the service provider side of that border >>>> in some form. If the IETF network runs DHCPv6-PD, that is an usable >>>> approximation. >>>> >>>> My suggestion was for the case that the IETF network won't be running >>>> DHCPv6-PD. In that case, the easiest way to make the IETF network >>>> usable as one uplink for the homenet plugfest is to ask for a /52 to >>>>be >>>> made available for the plugfest in some static way and then provide >>>> DHCPv6-PD from that, running on some random PC box/laptop somewhere. >>>> >>>> Actually - controlling the DHCPv6-PD might be advantageous in order to >>>> allow tinkering with it to see how the testbed reacts. >>>> >>>> >>>> -David >>> >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> Dave Täht >>> >>> Fixing bufferbloat with cerowrt: >>> http://www.teklibre.com/cerowrt/subscribe.html >>> <http://www.teklibre.com/cerowrt/subscribe.html> >> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
