[182161] in North American Network Operators' Group
Re: Hotels/Airports with IPv6
daemon@ATHENA.MIT.EDU (Mel Beckman)
Sat Jul 11 02:01:46 2015
X-Original-To: nanog@nanog.org
From: Mel Beckman <mel@beckman.org>
To: Owen DeLong <owen@delong.com>
Date: Sat, 11 Jul 2015 06:01:40 +0000
In-Reply-To: <04193AF2-3B53-4D74-8651-00AD909B8654@delong.com>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
Owen,
Lol. No, I'm a Mac guy. We think different :)
I suppose when an airport is first built, that would be greenfield. But th=
is airport already has a legacy wifi system that we are replacing, incremen=
tally. I agree that a case exists for building in IPv6 from the start, but =
this deployment already has enough new features, such as 802.11ac and a sle=
w of new applications, that the customer wanted to remove ipv6 as a variabl=
e. =20
-mel beckman
> On Jul 10, 2015, at 10:47 PM, Owen DeLong <owen@delong.com> wrote:
>=20
>=20
>> On Jul 10, 2015, at 22:34 , Mel Beckman <mel@beckman.org> wrote:
>>=20
>> Owen,
>>=20
>> I never said it was a greenfield deployment. Someone else tagged it with=
that term.=20
>>=20
>> 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 fo=
od, fuel, and FAA. You can't control those users, thanks to the FAA's recen=
t decisions restricting wifi regulation to itself.
>=20
> I suppose if you=92re going to use that definition, there=92s no such thi=
ng.
>=20
> 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 ne=
twork that is not yet saddled with any legacy deployment issues. E.g. a bui=
lding 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 l=
east in terms of the major design factors in the network.
>=20
>> Acceptance testing is straightforward once it's been designed and script=
ed. You bring in a wifi traffic generator (from a professional test service=
s company) that can simulate 1000 or more wifi clients to impose a known tr=
affic load on the network. You then use sample passenger devices of each ty=
pe -- smartphone, tablet, and laptop -- as well as various popular OS's to =
run pre-engineered regression test scripts, recording performance via a wif=
i sniffer. The sniffer capture then goes through offline analysis to compar=
e actual throughout and response times with the original design metrics. Yo=
u 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.=20
>>=20
>> The testing process takes a day or two per airport terminal. Yes, the ac=
ceptance 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, dw=
arfed even by the price of conduit.
>=20
> Right, but if you=92re starting fresh with a new design, why not design I=
Pv6 in from the start? There=92s really no incremental cost to doing so and=
your long-term savings can be substantial.
>=20
>> 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 populatio=
n is not growing rapidly, and can easily fit into simple NAT with the airpo=
rt's existing IPv4 space.
>=20
> Let me guess=85 You=92re still running on a computer with 640k of RAM.
>=20
> Owen
>=20
>>=20
>> -mel=20
>>=20
>>> On Jul 10, 2015, at 9:55 PM, Owen DeLong <owen@delong.com> wrote:
>>>=20
>>> How can it be a large, complex deployment if it=92s greenfield.
>>>=20
>>> In that case, you need to acceptance test the IPv4 just as much as IPv6=
.
>>>=20
>>> The difference is that you don=92t have to rerun your acceptance tests =
6-months later when you have to implement IPv6 in a rush because you sudden=
ly learned that your major client gets major suckage on IPv4 due to their p=
rovider having put them behind the worst CGN on the planet.
>>>=20
>>> Owen
>>>=20
>>>> On Jul 10, 2015, at 15:08 , Mel Beckman <mel@beckman.org> wrote:
>>>>=20
>>>> 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. T=
he powers that be chose not to incur it now. But we did deploy only IPv6 ge=
ar and systems, so it can probably be turned up later for that same increme=
ntal cost.=20
>>>>=20
>>>> -mel via cell
>>>>=20
>>>>> On Jul 10, 2015, at 3:03 PM, Mark Andrews <marka@isc.org> wrote:
>>>>>=20
>>>>>=20
>>>>> In message <A24F7CF2-0CD8-4EBA-A211-07BC36988A87@beckman.org>, Mel Be=
ckman 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.
>>>>>>=20
>>>>>> -mel via cell
>>>>>=20
>>>>> IPv4 has a cost as well. May as well just go IPv6-only from day one =
and
>>>>> not pay the IPv4 tax at all.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> Mark
>>>>>=20
>>>>>>> On Jul 10, 2015, at 2:42 PM, Mark Andrews <marka@isc.org> wrote:
>>>>>>>=20
>>>>>>>=20
>>>>>>> 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> wr=
ote:
>>>>>>>>> I working on a large airport WiFi deployment right now. IPv6 is
>>>>>> "allowed =3D
>>>>>>>> for in the future" but not configured in the short term. With less
>>>>>> than 10,=3D
>>>>>>>> 000 ephemeral users, we don't expect users to demand IPv6 until mo=
st
>>>>>> mobile=3D
>>>>>>>> devices and apps come ready to use IPv6 by default.
>>>>>>>>=20
>>>>>>>> 'we don't expect users to demand ipv6'
>>>>>>>>=20
>>>>>>>> aside from #nanog folks, who 'demands' ipv6?
>>>>>>>>=20
>>>>>>>> Don't they actually 'demand' "access to content on the internet" ?
>>>>>>>>=20
>>>>>>>> Since you seem to have a greenfield deployment, why NOT just put v=
6 in
>>>>>>>> place on day0? retrofitting it is surely going to cost time/materi=
als
>>>>>>>> and probably upgrades to gear that could be avoided by doing it in=
the
>>>>>>>> initial installation, right?
>>>>>>>=20
>>>>>>> +1 and you will most probably see about 50% of the traffic being IP=
v6 if
>>>>>>> you do so. There is lots of IPv6 capable equipment out there just
>>>>>> waiting
>>>>>>> to see a RA.
>>>>>>>=20
>>>>>>> Mark
>>>>>>> --
>>>>>>> Mark Andrews, ISC
>>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>>>>> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
>>>>>=20
>>>>> --=20
>>>>> Mark Andrews, ISC
>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>>> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
>=20
