> On Jul 10, 2015, at 22:34 , Mel Beckman <m...@beckman.org> wrote: > > Owen, > > I never said it was a greenfield deployment. Someone else tagged it with that > term. > > My understanding of the term "greenfield" WRT wifi is that there are no > interfering signals to contend with. I don't know of any U.S. airport that > meets that definition. First you have all the wifi of concessionaires, the > airlines' passenger clubs and operations, and service organizations for > food, fuel, and FAA. You can't control those users, thanks to the FAA's > recent decisions restricting wifi regulation to itself.
I suppose if you’re going to use that definition, there’s no such thing. However, as a general rule when I talk about a greenfield deployment of a network (of any form), I, and I suspect most people, are referring to a network that is not yet saddled with any legacy deployment issues. E.g. a building that has not yet been designed. A situation where you can start from scratch with a fresh design and specify everything from the ground up, at least in terms of the major design factors in the network. > Acceptance testing is straightforward once it's been designed and scripted. > You bring in a wifi traffic generator (from a professional test services > company) that can simulate 1000 or more wifi clients to impose a known > traffic load on the network. You then use sample passenger devices of each > type -- smartphone, tablet, and laptop -- as well as various popular OS's to > run pre-engineered regression test scripts, recording performance via a wifi > sniffer. The sniffer capture then goes through offline analysis to compare > actual throughout and response times with the original design metrics. You do > this for selected sub areas having typical characteristics, such as a gate, > security queue, baggage or dining area, at a time when it's empty. > > The testing process takes a day or two per airport terminal. Yes, the > acceptance test needs to be revised and repeated for deploying IPv6. That is > a small cost compared to the already-expended months of deployment planning > and rollout. The incremental IPv6 acceptance test cost is in the noise, > dwarfed even by the price of conduit. Right, but if you’re starting fresh with a new design, why not design IPv6 in from the start? There’s really no incremental cost to doing so and your long-term savings can be substantial. > I do agree that there are potential performance gains with IPv6, through > avoiding NAT. But those benefits will still be there in a year or two, and > will be much larger then than they are today. Moreover, the user population > is not growing rapidly, and can easily fit into simple NAT with the airport's > existing IPv4 space. Let me guess… You’re still running on a computer with 640k of RAM. Owen > > -mel > >> On Jul 10, 2015, at 9:55 PM, Owen DeLong <o...@delong.com> wrote: >> >> How can it be a large, complex deployment if it’s greenfield. >> >> In that case, you need to acceptance test the IPv4 just as much as IPv6. >> >> The difference is that you don’t have to rerun your acceptance tests >> 6-months later when you have to implement IPv6 in a rush because you >> suddenly learned that your major client gets major suckage on IPv4 due to >> their provider having put them behind the worst CGN on the planet. >> >> Owen >> >>> On Jul 10, 2015, at 15:08 , Mel Beckman <m...@beckman.org> wrote: >>> >>> There is most certainly a cost to IPv6, especially in a large, complex >>> deployment, where everything requires acceptance testing. And I'm sure you >>> realize that IPv6 only is not an option. I agree that it would have been >>> worth the cost, which would have been just a small fraction of the total. >>> The powers that be chose not to incur it now. But we did deploy only IPv6 >>> gear and systems, so it can probably be turned up later for that same >>> incremental cost. >>> >>> -mel via cell >>> >>>> On Jul 10, 2015, at 3:03 PM, Mark Andrews <ma...@isc.org> wrote: >>>> >>>> >>>> In message <a24f7cf2-0cd8-4eba-a211-07bc36988...@beckman.org>, Mel Beckman >>>> writ >>>> es: >>>>> Limited municipal budgets is all I can say. IPv6 has a cost, and if they >>>>> can put it off till later then that's often good politics. >>>>> >>>>> -mel via cell >>>> >>>> IPv4 has a cost as well. May as well just go IPv6-only from day one and >>>> not pay the IPv4 tax at all. >>>> >>>> The cost difference between providing IPv6 + IPv4 or just IPv4 from >>>> day 1 should be zero. There should be no re-tooling. You just >>>> select products that support both initially. It's not like products >>>> that support both are more expensive all other things being equal. >>>> >>>> Mark >>>> >>>>>> On Jul 10, 2015, at 2:42 PM, Mark Andrews <ma...@isc.org> wrote: >>>>>> >>>>>> >>>>>> In message >>>>> <cal9jlaba5no6yq99crhdgrthtsb0vgp3gdneu-vu2-4r_1_...@mail.gmail.com> >>>>>> , Christopher Morrow writes: >>>>>>>> On Thu, Jul 9, 2015 at 11:04 AM, Mel Beckman <m...@beckman.org> wrote: >>>>>>>> I working on a large airport WiFi deployment right now. IPv6 is >>>>> "allowed = >>>>>>> for in the future" but not configured in the short term. With less >>>>> than 10,= >>>>>>> 000 ephemeral users, we don't expect users to demand IPv6 until most >>>>> mobile= >>>>>>> devices and apps come ready to use IPv6 by default. >>>>>>> >>>>>>> 'we don't expect users to demand ipv6' >>>>>>> >>>>>>> aside from #nanog folks, who 'demands' ipv6? >>>>>>> >>>>>>> Don't they actually 'demand' "access to content on the internet" ? >>>>>>> >>>>>>> Since you seem to have a greenfield deployment, why NOT just put v6 in >>>>>>> place on day0? retrofitting it is surely going to cost time/materials >>>>>>> and probably upgrades to gear that could be avoided by doing it in the >>>>>>> initial installation, right? >>>>>> >>>>>> +1 and you will most probably see about 50% of the traffic being IPv6 if >>>>>> you do so. There is lots of IPv6 capable equipment out there just >>>>> waiting >>>>>> to see a RA. >>>>>> >>>>>> Mark >>>>>> -- >>>>>> Mark Andrews, ISC >>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>>>> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >>>> >>>> -- >>>> Mark Andrews, ISC >>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >>
