[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
>
>
>