RE : Recent navel gazing - we need to stop wasting cycles on FUD

["BAUDOT Alain FTRD/DMI/CAE" <alain.baudot@francetelecom.com>]

I agree with Tony's point. I guess, anyway, we have to take care about mechanisms having pieces into different environments, since they may have different requirements. Typical cases are obviously unman & ISP, or enterprise & ISP, assuming that a reasonnable scaled deployment should involve hopefully ISPs.

Alain.
-----Message d'origine-----
De : owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] De la part de Tony Hain Envoyé : vendredi 19 mars 2004 22:14 À : v6ops@ops.ietf.org Objet : 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