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
