On Jul 10, 2015, at 22:34 , Mel Beckman <mel@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 <owen@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 <mel@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 <marka@isc.org> wrote:
In message <A24F7CF2-0CD8-4EBA-A211-07BC36988A87@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 <marka@isc.org> wrote:
In message <CAL9jLabA5nO6YQ99CRhDgRTHTSB0VgP3GDNeu-VU2-4R_1_pLQ@mail.gmail.com> , Christopher Morrow writes: >> On Thu, Jul 9, 2015 at 11:04 AM, Mel Beckman <mel@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: marka@isc.org
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org