[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Recent navel gazing - we need to stop wasting cycles on FUD
Hi all,
I also agree, as I indicated in the Seoul meeting.
I also will like to have as less mechanism as possible (no idea if 4 is enough or we need 7 or 11), but while we warrantee that a user can ALWAYS, in ANY situation, get IPv6 with any kind of IPv4 connection.
We probably need to fix the specs, yes, and make them as much perfect as possible, yes also, but not if that will take more than 5-6 months (may be is unrealistic ?).
Regards,
Jordi
----- Original Message -----
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Tony Hain" <tony@tndh.net>; <v6ops@ops.ietf.org>
Sent: Saturday, March 20, 2004 5:08 PM
Subject: RE: Recent navel gazing - we need to stop wasting cycles on FUD
I agree with Tony's message. This group should stop the nasty
competition between solutions and recognize that different solutions
have different domains of applications. In particular, we should
recognize that when solutions are deployed and have independent
implementations, they probably meet two key criteria: someone needs
them, otherwise they would not be deployed; and the specification is
reasonably easy to implement, or there would not be interoperability.
It is fairly clear that 6to4, ISATAP, and Teredo meet this bar today.
Some version of tunnel broker should easily meet the bar in the short
term; it certainly meets the deployment bar, but we probably have to
stabilize the spec.
-- Christian Huitema
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
Behalf
> Of Tony Hain
> Sent: Friday, March 19, 2004 1:14 PM
> To: v6ops@ops.ietf.org
> Subject: Recent navel gazing - we need to stop wasting cycles on FUD
>
> Several recent threads are about trying to out-guess the market and
pick
> the
> one-size-fits-all answer to deployment. The entire point of the
scenarios
> documents was to focus the communities on their area of expertise, so
we
> don't continue arguing that 'we don't need X for my environment,
therefore
> we don't need X'. While it is appropriate to point out when specific
> mechanisms are or are not useful, it is not appropriate to force the
> entire
> diverse Internet into a single, or even restricted set, deployment
> approach.
>
>
> We are close to finishing the work on scenarios so we can start
applying
> the
> proposed tools to them. Rather than the continuing efforts to kill off
> technologies out of context, the applicability work needs to be
completed.
> While it is useful to make sure we have minimal duplication and
overlap,
> as
> I look at the proposed tool set I don't see any useful reduction. We
can
> discuss the mechanics of any individual tool, but only in the context
that
> we know exactly what problem we are solving. The continuing FUD is
based
> on
> application of a tool in an environment that it is specifically not
suited
> for.
>
> FWIW as I see the tools and their application;
>
> 6to4
> - Enterprise -> allows multiple subnet deployments behind the tunnel
> endpoint with a public IPv4 address.
> - Unmanaged -> this is both simple, and in common use as an automated
> prefix
> delegation approach.
>
> ISATAP
> - Enterprise -> where the apps & hosts move before the infrastructure
> (this
> is reasonable both from the perspective of demonstrating value, and
from
> the
> perspective that hosts are generally upgraded before infrastructure),
> - ISP -> it has value in the Cable operator environment where the
> management
> side of the gateway is addressed in private IPv4 space, yet the
gateway
> needs to tunnel across older DOCSIS equipment that will take years to
> replace (6to4 would work with public addresses, and manual config is
> always
> an option).
>
> Teredo
> - Unmanaged -> automated single subnet & needed to deal with the NAT
> managed
> by someone else problem (home / hotel / airport ...).
> - ISP -> automated single subnet & needed to deal with the NAT managed
by
> someone else problem (the charging for addresses approach has resulted
in
> customers deploying infrastructure, and getting a service behind that
> device
> is proving to be an issue).
>
> Tunnel brokers as a class
> - ISP -> for the aggressive ISP that wants to take mindshare away from
> local
> competitors, there is an opportunity to offer new applications (this
is
> really no different than the Dial-up ISP case tunneling over the
lethargic
> PSTN).
>
> Translators as a class
> - 3G -> needed if IPv6 only handsets are expected to directly reach
the
> legacy IPv4 Internet or devices that have not reached their economic
end
> of
> life
>
> Application gateways
> - 3G / ISP / Enterprise & Unmanaged -> useful if IPv6-only appliances
> appear
> in mass before infrastructure gets upgraded (see Sony press releases).
>
> Each of these tools solves a different subset of the problem space. It
is
> up
> to the market to decide which have value. The IETF's role is to make
sure
> that the mechanisms are well documented so all implementations have
the
> opportunity to interoperate. If there are operational recommendations
or
> warnings those are also appropriate to document. Attempts to kill off
> technology X because some people think the market will want Y only
ensures
> that technology X will be implemented differently by each vendor. All
of
> these technologies need to be on the standards track, and the recent
> discussion about making them experimental is BS that needs to stop. We
> can't
> have a reasoned discussion about the useful / extraneous features of
any
> technology until we nail the target deployment environments.
>
> Tony
>
>
>
**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.