[182159] in North American Network Operators' Group
Re: Hotels/Airports with IPv6
daemon@ATHENA.MIT.EDU (Owen DeLong)
Sat Jul 11 01:50:26 2015
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <29B817E0-B42A-41FB-A3BA-9A49DBB1232E@beckman.org>
Date: Fri, 10 Jul 2015 22:47:42 -0700
To: Mel Beckman <mel@beckman.org>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
> 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 food, fuel, and FAA. You can't control those =
users, thanks to the FAA's recent decisions restricting wifi regulation =
to itself.=20
I suppose if you=92re going to use that definition, there=92s 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.=20
>=20
> 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=92re starting fresh with a new design, why not design =
IPv6 in from the start? There=92s 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.=20
Let me guess=85 You=92re still running on a computer with 640k of RAM.
Owen
>=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 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.
>>=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. 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.=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 =
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.
>>>>>=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> =
wrote:
>>>>>>>> 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 =
most
>>>>> 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 =
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?
>>>>>>=20
>>>>>> +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.
>>>>>>=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
