[161319] in North American Network Operators' Group
RE: What Should an Engineer Address when 'Selling' IPv6 to Executives?
daemon@ATHENA.MIT.EDU (Vinod K)
Thu Mar 7 14:57:24 2013
From: Vinod K <vinod408@hotmail.com>
To: <nanog@nanog.org>
Date: Thu, 7 Mar 2013 19:57:11 +0000
In-Reply-To: <5137ADAB.3030809@matthew.at>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Matthew=2C I am sorry to offend=2C but I don't think the Skype development =
"agile" when u say IPv6 is not needed or important in 2013. Microsoft hs s=
trong thought leaders like VJ Gill and Najam Ahmad who bring v6 to Bing and=
GFS. You should follow their example.
Regards
Vinod
> Date: Wed=2C 6 Mar 2013 12:57:15 -0800
> From: matthew@matthew.at
> To: cb.list6@gmail.com
> Subject: Re: What Should an Engineer Address when 'Selling' IPv6 to Execu=
tives?
> CC: nanog@nanog.org
>=20
> On 3/6/2013 9:20 AM=2C Cameron Byrne wrote:
> > On Tue=2C Mar 5=2C 2013 at 10:29 PM=2C Matthew Kaufman <matthew@matthew=
.at> wrote:
> >> On 3/5/2013 8:20 PM=2C Owen DeLong wrote:
> >>> On Mar 5=2C 2013=2C at 7:55 PM=2C Matthew Kaufman <matthew@matthew.at=
> wrote:
> >>>
> >>>> On 3/5/2013 7:15 PM=2C Owen DeLong wrote:
> >>>>> On Mar 5=2C 2013=2C at 6:46 PM=2C Mukom Akong T. <mukom.tamon@gmail=
.com>
> >>>>> wrote:
> >>>>>
> >>>>>> On Wed=2C Mar 6=2C 2013 at 12:34 AM=2C Mike. <the.lists@mgm51.com>=
wrote:
> >>>>>>
> >>>>>>> I would lean towards
> >>>>>>>
> >>>>>>> f) Cost/benefit of deploying IPv6.
> >>>>>>>
> >>>>>> I certainly agree=2C which is why I propose understanding you
> >>>>>> organisation's
> >>>>>> business model and how specifically v4 exhaustion will threaten th=
at.
> >>>>>> IPv6
> >>>>>> is the cast as a solution to that=2C plus future unknown benefits =
that
> >>>>>> may
> >>>>>> result from e-2-e and NAT elimination.
> >>>>>>
> >>>>>> I have no clue how to sell 'benefit' of IPv6 in isolation as right=
now
> >>>>>> even
> >>>>>> for engineers=2C there's not much of a benefit except more address=
space.
> >>>>> I'm not so sure about that=85
> >>>>>
> >>>>> Admittedly=2C most of these are too technical to be suitable for
> >>>>> management consumption=2C but:
> >>>>>
> >>>>> 1. Decreased application complexity:
> >>>> Yeah. After IPv4 goes entirely away. Which is a long=2C long=2C LONG=
time
> >>>> from now. Until then=85
> >>>>
> >>> I don't think so. I think IPv4's demise as a supported internet proto=
col
> >>> is certainly less than 10 years away and likely less than 5. I say th=
is
> >>> because IPv6 deployment is a bit of a variable here and we're faced w=
ith one
> >>> of two outcomes as a result:
> >>
> >> Two unsubstantiated suppositions deleted.
> >>
> >> They suggest that IPv4 support is needed *in conjunction with* IPv6 su=
pport
> >> for 5-8 years.
> >>
> >> That's a long time if you're developing software... so=2C basically=2C=
no... no
> >> cost or effort saving if you were to do this work today. In fact=2C >2=
x the
> >> effort if you were to start today.
> >>
> >> So again=2C why try to sell it to the engineers that way? Either sell =
it as 1)
> >> If you don't start doing a lot more work now you'll be screwed at the
> >> transition or 2) You should just wait until you can single-stack on IP=
v6.
> >>
> >>
> >>> Why? I doubt any software vendor will continue to maintain NAT traver=
sal
> >>> code much after IPv4 is no longer the common inter-domain protocol of
> >>> choice.
> >>
> >> Sure. In 5 to 8 years=2C as you claimed.
> >>
> >>
> >>> Doubt it all you want. Once it's gone=2C it stops generating support =
calls=2C
> >>> or they become very short:
> >>>
> >>> C: "Hi=2C my application isn't working through my NAT."
> >>> TSR: "Hi=85 Get IPv6=2C we don't support NAT any more."
> >>> TSR: "Is there anything else I can help you with today?"
> >>
> >> C: "Hi=2C my application isn't working between me and my grandmother"
> >> TSR: "Hi... Get IPv6=2C we don't suppotr NAT any more."
> >> C: "Screw you guys... my grandmother isn't served by an ISP that is of=
fering
> >> IPv6 and her old operating system barely supports it anyway. Please re=
fund
> >> my money."
> >>
> >> The point being that for some applications=2C *both ends* need to be o=
n IPv6
> >> before any of this complexity can go away.
> >>
> >> For the rest=2C they're just talking to web services... and until the =
places
> >> those are hosted run out of IPv4 addresses=2C nobody cares.
> >>
> > So=2C your position=2C which is substantiated my Microsoft's / Windows
> > Phone's / Skype's lack of IPv6 support =2C is that "nobody cares" until
> > we "run out of IPv4".
>=20
> No. While you've cleverly quoted something I did say=2C Skype is an=20
> example of an application where=2C as I mentioned in the paragraph above=
=2C=20
> until both ends of a call are always guaranteed to be on IPv6=2C there is=
=20
> *more* complexity involved in supporting both IPv4 and IPv6 than in=20
> supporting IPv4 alone.
>=20
> This entire discussion started with "how should I sell IPv6 to=20
> executives" and Owen claimed that switching to IPv6 represents less=20
> engineering effort. I simply claim that isn't true. In fact the amount=20
> of engineering effort required to make an application like Skype work=20
> (both development effort and testing required) where the users who might=
=20
> want to call each other are on an unknown mixture of IPv4=2C IPv4/IPv6=20
> dual-stack=2C IPv6 w/NAT64 for IPv4=2C and IPv6 single-stack is *tremendo=
us*=20
> compared to the effort required to make it work with IPv4 and end-user=20
> NAT devices.
>=20
>=20
>=20
> > But=2C Matthew=2C your division of Microsoft is really a bunch of "Free
> > Riders" that is honestly holding back the rest of us.
>=20
> My division of Microsoft is currently engaged in a massive amount of=20
> engineering... work to add features that customers are demanding=2C work=
=20
> to make Skype work better on mobile devices=2C work to make Skype=20
> interoperate with Lync=2C and yes=2C work to make Skype work in the huge=
=20
> explosion of new network connectivity situations it will find itself in=20
> as IPv6 is deployed and especially as those IPv6 users stop getting=20
> native IPv4 alongside it.
>=20
> And we're using Agile and Scrum as our engineering methodology=2C and I=20
> can tell you that it is very very hard to get IPv6 work to rise to the=20
> top in any organization=2C including ours=2C given that the short-term=20
> return on that investment is nil and the engineering and testing effort=20
> is huge.
>=20
> But again=2C the only reason I even brought this up here is that there ar=
e=20
> people like Owen running around trying to tell engineers that when the=20
> whole world is IPv6 everything will be so much easier... and while that=20
> might be true=2C there are at least 5 more years and probably more where=
=20
> the necessary engineering effort required to support *both*=2C especially=
=20
> for applications like Skype=2C is crazy hard compared to IPv4-only=2C and=
so=20
> trying to sell the execs on the idea that we'll deploy some IPv6=20
> internally and write some IPv6 code and our QE and Dev budget can go=20
> *down* is frankly ridiculous.
>=20
>=20
>=20
> Matthew Kaufman
>=20
> p.s. As I pointed out privately last night=2C if doing IPv4+IPv6 was=20
> really easier than doing IPv4-only=2C we wouldn't see other smart=20
> collections of engineers with bugs like this one:=20
> https://code.google.com/p/webrtc/issues/detail?id=3D1406 (because=20
> *clearly* there's no reason to have taken the "extra effort" to make it=20
> IPv4-only=2C right?)
>=20
=
