Subject: RE: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 as WG item]

From: "Christian Huitema" <[email-masked]>
Date: Sat, 15 Nov 2003 11:44:20 -0800

> On Fri, 14 Nov 2003, Fred Templin wrote:
> > Then, let's have ISATAP as a WG item; it's been around for three
> > years and there is nothing premature about that. (Better yet would
> > be to just go ahead and publish it NOW.)
> 
> We don't yet know whether we need ISATAP.

Correction. We very well know we do. In fact, we know it so much that
there is actual deployment at many sites, and interoperable
implementations by several vendors. You can only write that "we don't
know" if you define knowledge in the very narrow sense of "we do not
have a requirement document that explains why we absolutely cannot do
without it."

Let's go back to April 2002, when the IESG decided to close NGTRANS and
to put a temporary stop to the definition of transition mechanisms. The
feeling at the time was that having too many mechanisms would create
confusion, and that we should only develop those mechanisms that
correspond to a clear scenario. 

That sounded logical, but the implementation of that idea in NGTRANS
turned out to be terrible. The WG embarked in an exercise of defining a
set of transition scenarios for various deployment areas, and the
exercise proved both contentious and cumbersome. It took us about a year
to agree on the first scenarios (3GPP and unmanaged), and we have yet to
complete the ISP and enterprise scenario. The obvious explanation is
that the world is very diverse, and trying to have a single document
reflect everybody's ideas of a transition requires lengthy negotiations.
The negotiations continue with the requirement documents, which may be
even more contentious.

The example of ISATAP is quite telling. It would be very easy to write a
simple 2 paragraph document explaining how ISATAP can be used to provide
IPv6 connectivity in an enterprise network as an overlay over the
existing IPv4 infrastructure. We may not unanimously approve that this
is needed, but we should never require unanimity in such cases. If there
is a substantial constituency that approves the requirement, the IETF
tradition is to acknowledge that the requirement exists.

The V6OPS working group is a prime example of the current IETF decease:
expanding a lot of energy to achieve no result. The symptom is very
clear: vendors are shipping products based on internet drafts, without
getting the benefits of IETF peer review. 

I would propose one simple way to meet the "describe your scenario"
requirement: ask anyone who proposes a transition technology to include
in the draft a two paragraph description of what scenario the proposal
is supposed to facilitate. The WG should then verify that there is some
demand for the scenario, but should not require unanimity or even "rough
consensus": just because someone believes I don't need something does
not change my need for it. The role of the working group should be peer
review: make sure that the proposal is well engineered and meets it
stated requirement without causing harm.

We must break the current analysis/paralysis.

-- Christian Huitema

---

From: Tim Chown <[email-masked]>
Date: Sat, 15 Nov 2003 20:13:08 +0000

> stated requirement without causing harm.

I agree with Christian's general sentiments.

The 18 month navel-inspecting period has served no purpose other than to 
ensure that ISATAP, DSTM and Teredo have been commercially implemented and 
deployed, but without the IETF standardisation process behind them to help 
ensure interoperability between those implementations or indeed with other 
transition tools.

This isn't a criticism of the design teams.  Indeed the deployment scenarios
are so broad (esp. for enterprise) that it is no surprise that only the
most narrow of scenarios (3GPP) has been (nearly) completed.   

I don't see any reason why ISATAP, DSTM and Teredo could not be adopted
as WG items and standardised using all the expertise of the V6 Ops WG minds, 
rather than being forced into implementation and deployment outside of the 
IETF, without WG input.

Christian's solution seems sound.  I would venture that we could consider
accepting DSTM, ISATAP and Teredo as WG items (if the WG members agree)
independently of the analysis, and then once finalised only put them to 
Proposed Standard once the need is agreed by analysis or by the WG.   At 
least that way the mechanisms would be on the WG table, in the open for all 
to see and work on. 

I think it is the WG that should agree adoption of a mechanism.   The problem 
has been that for 18 months the IESG has denied the WG that choice.

Tim

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Sat, 15 Nov 2003 14:22:00 -0600

Probably I don't need to say that I fully agree ... but I can't shut up, sorry ;-)

In fact, I feel that will be good to heard in this list as many voices as they support this.

Regards,
Jordi

----- Original Message ----- 
From: "Christian Huitema" <[email-masked]>
To: "Pekka Savola" <[email-masked]>; "Fred Templin" <[email-masked]>
Cc: "JORDI PALET MARTINEZ" <[email-masked]>; <[email-masked]>
Sent: Saturday, November 15, 2003 1:44 PM
Subject: RE: spending time on analysis [Re: draft-palet-v6ops-proto41-nat-03 as WG item]

-- Christian Huitema

**********************************
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.

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Sat, 15 Nov 2003 14:25:26 -0600

I'm not sure if the problem has been the IESG, the AD, the chairs or the WG itself, probably all of us.

Now the WG at least has the option to speak up (some of us are already doing it) ... so what are you waiting for folks ?

Regards,
Jordi

---

From: Pekka Savola <[email-masked]>
Date: Mon, 17 Nov 2003 12:45:06 +0200 (EET)

Senthil Sivakumar already replied about the same way I will but I'll try 
to respond anyway..

> have a requirement document that explains why we absolutely cannot do

The latter is pretty close to what's written in our charter.  We're not 
there to find uses for transition mechanisms.  We're here to do only what 
must be done.
 
> getting the benefits of IETF peer review. 

Achieving no result is probably considered a bug rather than feature if
one believes the IETF exists to provide peer review of the technologies
the vendors wish to standardize.  I don't.

> stated requirement without causing harm.

You can devise a use for every tool out there, and more besides.   Writing 
such an applicability statement is trivial; a couple of years I made the 
case myself in a paper I wrote.  But that doesn't mean those methods are 
necessary or useful.

The main point of v6ops (AFAICS) is to show the folks how to start
deploying IPv6 in the most common scenarios.  It'd both act as a guide how
to go on with it ("look, you can do X, you don't need Y"), and as a way to
identify required transition mechanisms which will be necessary.
 
> We must break the current analysis/paralysis.

It would be much easier if more people did the work, instead of complained 
about the work not having any result...

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Tim Chown <[email-masked]>
Date: Mon, 17 Nov 2003 13:40:16 +0000

> case myself in a paper I wrote.  But that doesn't mean those methods are 

I agree some level of analysis is very useful, both for specifics of the
mechanisms, and how they interact with other mechanisms.   But also the
requirements on the whole architecture are important, e.g. Teredo and 6to4 
both like talking to other Teredo or 6to4 systems respectively and would 
require a heavy investment in relays if they are to communicate with native 
IPv6 systems.

I agree that ideally the WG needs to decide if certain tools are required
from the analysis.   But that result will depend on how the scenario 
document is phrased.  For example, a scenario of dual-stack hosts in an 
IPv6-only infrastructure could quite reasonably lead to a DSTM-like solution.
Likewise, the device-behind-a-NAT scenario could lead to a Teredo-like 
solution.  The question then becomes what are valid scenarios, as any scenario 
can lead to a certain best (or only) solution.   And how do we judge those
solutions in the big picture (e.g. the requirement of wide-spread deployment 
of Teredo or 6to4 relays in ISP networks?).

> identify required transition mechanisms which will be necessary.

I think the basic transition mechanism doc is fine, and we have basic
tools for "structured" deployment - native, dual-stack, and (though loosely 
specified) tunnel brokers.   It seems some of the reluctance to adopt certain 
tools has a tension between the "perfect transition" and the "reality now", 
as was reflected in the IAB/IESG Minneapolis presentation - do we define 
standards for the Internet, or standardise what is on the Internet?   The
"reality now" has quite widespread use of 6to4 (which is standardised) and
Teredo (which is not), although both have loosely similar architectural
implications.

> about the work not having any result...

But as Christian and others point out, this is a potentially complex task,
most especially for enterprise.  One could see now where ISATAP provides
a unique solution for a certain sparse deployment in an enterprise, for
example.   Enterprise is the hardest of all four to nail down.

One could foresee that ISPs would need to deploy system(s) that act as
combined tunnel broker, Teredo relay and 6to4 relay as a "migration broker"
if we do ultimately end up going down those paths.   That's quite a price.
But I don't see the big archiecture discussion happening - I would have
thought this might be independent of the four (ISP/3GPP/unman/ent) scenarios?

Tim

---

From: Fred Templin <[email-masked]>
Date: Mon, 17 Nov 2003 10:11:03 -0800

>the vendors wish to standardize.  I don't.

In the specific instance of ISATAP, I take exception to this remark.
ISATAP was originally developed under government contract and
institutional funding during my employment at SRI International
and therefore *is not* the product of any particular vendor.

What ISATAP *is* is a superior technical approach at solving
real-world needs for IPv6 deployment. This falls squarely under
the auspices of the IETF if only we choose to recognize it and
get on board before the real world passes us by.

The IETF I have known is an organization of brilliant technologists
who are not afraid to push through new technologies to further the
advancement of the Internet. That is why we have an IP-based network
today, and not OSI or any of the other approaches that have fallen by
the wayside over the years.

Pekka, I appeal to you as one of our finest such technologists to get
this train back on the tracks under the IETF auspices so we can go
forward together as it should be.

Fred Templin
[email-masked]