RE: WG Review: IPv6 Operations (v6ops)

["Bound, Jim" <Jim.Bound@hp.com>]

also DSTM will not stop in the market that I gurantee.

/jim

> -----Original Message-----
> From: Bound, Jim 
> Sent: Tuesday, September 10, 2002 12:00 AM
> To: Pekka Savola
> Cc: Jun-ichiro itojun Hagino; Brian E Carpenter; Fred L. Templin;
> v6ops@ops.ietf.org
> Subject: RE: WG Review: IPv6 Operations (v6ops) 
> 
> 
> Hi Pekka,
> 
> > -----Original Message-----
> > From: Pekka Savola [mailto:pekkas@netcore.fi]
> > Sent: Sunday, September 08, 2002 1:14 PM
> > To: Bound, Jim
> > Cc: Jun-ichiro itojun Hagino; Brian E Carpenter; Fred L. Templin;
> > v6ops@ops.ietf.org
> > Subject: RE: WG Review: IPv6 Operations (v6ops) 
> > 
> > 
> > Hello,
> > 
> > Getting back to a few points.
> > 
> > On Thu, 5 Sep 2002, Bound, Jim wrote:
> > > > On Wed, 4 Sep 2002, Bound, Jim wrote:
> > > > > I don't hear that from any user in that way.  What I hear 
> > > > is there are
> > > > > several good mechanisms they like and want to apply for 
> > different
> > > > > reasons.
> > > > 
> > > > For (over?) 95% of folks, they're just distraction.  And what 
> > > > we want here
> > > > is to get deployments going.  There's little need for 
> > > > anything fancy if
> > > > you don't require it. 
> > > 
> > > Deployment is going as best it can right now.  See the NTT MSC
> > > announcment that came out yesterday in Malaysia that is 
> > native IPv6.  
> > 
> > Native IPv6 is the proper and easy way.  The press release does not 
> > elaborate on the tunneling mechanisms used though.  And 
> > there's nothing to 
> > suggest v6-only (which was one of my "not of this world" 
> > arguments) there.
> 
> Nothing to suggest it is not v6 only and my impression is 
> that v6 only will be part of the solution.
> 
> > 
> > > I
> > > don't think ISATAP, DSTM, or Teredo are "fancy" but solid 
> mechanisms
> > > that work and for those moving at very fast pace.
> > 
> > Some are more useful than others.  I suppose they work, more 
> > or less, in
> > more or less restricted topologies.  I have doubts about the 
> > stability in
> > the long term or when more people would start to use them.
> >  
> > > The mechanisms I feel are imperative for wide deployment 
> > are as follows:
> > > 
> > > Basic Tunnels
> > > 6to4
> > 
> > Sure.
> > 
> > > ISATAP
> > 
> > May be useful in some scenarios (IMO, especially large 
> > enterprises with 
> > slow and sparse deployment or a lot of internal traffic).
> 
> I agree and to jump start IPv6.
> 
> > 
> > > Teredo
> > 
> > Have you read the latest versions of the draft?  It's a patch 
> > over a patch
> > over a patch against (mis)features of NAT (not a fault of the 
> > author of
> > course).  It's just too complex to work reliably.
> > 
> > I would rephrase this as:
> > 
> > "Some reliable and simple mechanism to provide v6 behind a NAT"
> 
> Yes I have read it and still state what I state.  It is a 
> solution to many customer problems who will adopt v6. 
> 
> > 
> > (Yes, it's possible -- but there are some engineering tradeoffs!)
> > 
> > > DSTM
> > 
> > I'm not yet convinced of this.  Especially I have huge doubts about 
> > temporary address management scalability and robustness.
> 
> There is not other mechanisms that treats IPv4 as DSTM does.  
> Our job here is not to decide if temp addr mgmt is scalable 
> the market will decide that.  Our job here is to decide if 
> the DSTM spec is functional.  I could argue a lot of what we 
> work on here is not scalable.  That is not our job.  The 
> market and vendors won't use it if its not scalable.
> 
> As far as robust?  What does that mean?  Why would you call 
> 6to4 robust?
> And define robust.  What is robust to you may not be robust 
> to my customers?
> And what I call robust may not be robust to your customers? 
> 
> Robust is to subjective we cannot state specs are robust or 
> not in the IETF.
> 
> > 
> > > BIA (in some cases but caution is needed)
> > 
> > May be useful for legacy apps, yes.
> >  
> > > NAT-PT and SIIT should be last resort and not used unless 
> > there is no choice.
> > 
> > Agreed.
> >  
> > > What is happening is that unless vendors, operators, and 
> some other
> > > entities I won't mention begin to make money on IPv6 they 
> > are going to
> > > stop momentum.  Fortuneately we are seeing real purchase 
> > orders for IPv6
> > > and boxes and software be sold at significant levels to warrant
> > > continued engineering and market investments. But those 
> > returns are not
> > > from the large mass that will move with LCD mechanisms or 
> > the 80% that
> > > will do as you say and want universal solutions (as Brian 
> > suggested).
> > > 
> > > So the catch-22 is that the 20% of custom users is where 
> we will all
> > > make our money for the next 3 years.  Then the masses will begin
> > > conversion.  So my issue is that to stop work on what we 
> > are doing that
> > > will make money is crazy in the IETF.  Maybe we need an 
> > advanced Ipv6
> > > transition area as Brian suggested but if that don't 
> happen fast the
> > > vendors and entities that want to deploy this 20% will not 
> > wait for the
> > > IETF and do it out of band and create a storm of defacto 
> > standards for
> > > IPv6 that will compete with the IETF in the market.  They 
> > have no choice
> > > and will not loose the mony waiting on 2 and 3 year 
> > discussions of how
> > > to do transition or settle for universal compromised solutions.
> > 
> > But are those 20% of users such that they *need* a "custom" 
> > transition 
> > mechanism?  Why not e.g. consulting them how to build their 
> > network using 
> > current mechanisms?
> 
> See we don't agree.  DSTM is a current mechanism but now its 
> been stopped by the IETF. It is being deployed and 
> specifically for Mobile IPv6.  See the market is not going to 
> wait for the IETF anymore in several spaces or 3G for that matter.
> 
> DSTM permits a Mobile IPv6 node that is doing mostly IPv6 to 
> get an IPv4 address if it needs one.
> 
> Users with IPv4 address space can use DSTM to leverage their 
> IPv4 address space to deploy IPv6.
> 
> > 
> > > > I don't think all of these non-basic, complex, fringe(?) 
> > > > mechanisms should
> > > > be discarded -- quite the contrary.  But this is probably(?) 
> > > > not the right 
> > > > place.
> > > 
> > > I am not sure yet.  Randy Bush has been saying IPv6 is here 
> > as operator
> > > and I agree. How IPv6 deploy is still TBD.  Why should not 
> > this true 20%
> > > deployment sector recieve the work from v6ops effort?  I 
> > think not doing
> > > it is not wise.
> > 
> > Randy Bush has a network/ISP operator background AFAIK.  
> > Deploying IPv6 
> > there is a much more simple task than deploying it properly in 
> > organizations.
> > 
> > There's much more to 'IPv6 is here' than having it enabled on 
> > dual-stack
> > routers.
> > 
> > > > I could say probably over 99% of folks doing this are not 
> > living in 
> > > > today's world.
> > > 
> > > This is simply not true I hope my above mail helps change 
> > your mind on
> > > this statement above as its as far as I can take to 
> convince you and
> > > others.
> > 
> > See comment above, I don't think v6-only is really here yet.
> 
> We will have to agree to disagree.  Thats ok it is two 
> distinct views of the market I guess.  As a product engineer 
> I know its working for my work and making money.
> 
> > > 
> > > > 
> > > > IPv4 just isn't ready to be "as-needed" at the moment, or 
> > > > you're probably
> > > > using it in very simple ways (e.g. www browsing only 
> > which works quite
> > > > well with NAT too :-).  It's IMO very questionable to 
> > approach IPv4 
> > > > needs with an "ad-hoc" ways when clearly the requirements for 
> > > > IPv4 are 
> > > > not, in reality, ad-hoc.
> > > 
> > > Ad hoc means the use of IPv4 is dicouraged as a policy 
> and used only
> > > when necessary.  So maybe adhoc was wrong term on my part.
> > 
> > And if it's necessary for a node to use it, 10, 100, 1000 
> > times a day?  Is 
> > Ad-hoc really the best way to go?
> 
> OK.  But you have not provided one technical argument against 
> DSTM nor has anyone else since the last draft-08 because the 
> working group did their job and the authors did their job 
> with updates.
> 
> All your arguments are a "gut" feeling against DSTM and "your 
> OPINION" of how IPv6 will be deployed.
> 
> Hardly an argument to not move forward with DSTM.  This is 
> not a club or social group it is the Internet Engineering 
> Task Force and DSTM performed that process and is being used 
> as all the mechanisms above.  Just because you don't like it 
> is not a fair way to stop it from being move forward.  In 
> fact if that happens it proves all I am beginning to dislike 
> about the IETF processes of late.
> 
> regards,
> /jim
> 
> >  
> > -- 
> > Pekka Savola                 "Tell me of difficulties surmounted,
> > Netcore Oy                   not those you stumble over and fall"
> > Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
> > 
> > 
> > 
> 
>