Subject: Re: WG Review: IPv6 Operations (v6ops)

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 03 Sep 2002 16:49:11 -0700

Comments on the new proposed charter follow:

>     * To: IETF-Announce: ;
>     * Subject: WG Review: IPv6 Operations (v6ops)
>     * From: Steve Coya <[email-masked]>
>     * Date: Tue, 27 Aug 2002 10:05:36 -0400
>     * Cc: [email-masked]
> 
> A new IETF working group has been proposed in the Operations and
> Management Area.  The IESG has not made any determination as yet.
> 
> The following Description was submitted, and is provided for
> informational purposes only:
> 
> 
> IPv6 Operations (v6ops)
> -----------------------
> 
>  Current Status: Proposed Working Group
> 
> Description of Working Group:
> 
> The global deployment of IPv6 is underway, creating an IPv4/IPv6
> Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and
> nodes. This deployment must be properly handled to avoid the division
> of the Internet into separate IPv4 and IPv6 networks while ensuring
> global addressing and connectivity for all IPv4 and IPv6 nodes.
> 
> The IPv6 Operations Working Group (v6ops) develops guidelines for the
> operation of a shared IPv4/IPv6 Internet and provides guidance for
> network operators on how to deploy IPv6 into existing IPv4-only
> networks, as well as into new network installations.
> 
> The v6ops working group will:
> 
> (1) Solicit input from network operators and users to identify 
>     operational or security issues with the IPv4/IPv6 Internet,  and
>     determine solutions or workarounds to those issues.  This includes

The term "operational" needs to be defined. The above could
be interpreted as implying that sub-optimal solutions are
satisfactory, as long as they work in some fashion. I would
like to see the term "operational" defined in such a way that
the best solution for the problem space is considered; not
just a one-size-fits-all solution that may be sub-optimal.

> (7) Identify open operational or security issues with the deployment
>     solutions documented in (5) and fully document those open
>     issues in Internet-Drafts or Informational RFCs. Work to find
>     workarounds or solutions to basic, IP-level deployment issues
>     that can be solved using widely-applicable transition mechanisms,
>     such as dual-stack, tunneling or translation.
> 
>     If the satisfactory resolution of a deployment issue requires
>     the standardization of a new, widely-applicable transition
>     mechanism that does not properly fit into any other IETF WG or
>     area, the v6ops WG will standardize a transition mechanism
>     to meet that need.

I find the above wording biased, since "widely-applicable" seems to
be the only selection criteria mandated for the standardization of
new mechanisms. I would like to see the above changed to allow for
standardization of the best mechanism for a particular scenario;
not just a one-size-fits-all.

By way of analogy, four-door sedans are "widely-applicable"
vehicles. But:

   - minivans are a better choice for large families
   - pick-ups are a better choice for hauling large loads
   - 4wd's are a better choice for off-road driving
   - etc.

Summary - the wording in sections (1) and (7) seems to mandate
lowest-common-denominator solutions and ignore solutions that
provide a better fit.

Fred Templin
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Sep 2002 13:00:17 +0200

"Fred L. Templin" wrote:
...
> lowest-common-denominator solutions and ignore solutions that

It's hard to avoid special pleading (since the transition solution
with my name on it is in the list), but I do think that there is a strong
argument for concentrating on LCD solutions for the first wave.

We might contemplate a separate IETF activity for advanced transition
solutions.

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Wed, 4 Sep 2002 14:15:59 +0300 (EEST)

> We might contemplate a separate IETF activity for advanced transition

I agree with Brian.

People already have problems trying to choose which cars to buy.  Guides
and expert knowledge help a bit but it's still difficult. It's quite much
simpler if you don't have all that many choices to make.  People don't get
stuck on details, and we can concentrate better on really pressing matters
(if any).

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

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 04 Sep 2002 12:58:17 -0700

Brian,

> argument for concentrating on LCD solutions for the first wave.

I'm sorry; the text of sections (1) and (7) I was commenting on refers
to selection criteria for *new* mechanisms - I had no intention of
labeling the set of solutions already accepted to the wg as "LCD".

Fred
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Sep 2002 12:13:18 +0200

> labeling the set of solutions already accepted to the wg as "LCD".

LCD may be a wrong characterisation of them, but one assumes they
were chosen because they were believed to be relatively simple
and universal.

   Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 06 Sep 2002 00:47:53 -0400

Hi Fred,

>lowest-common-denominator solutions and ignore solutions that

It was our intention to write a charter that limits the v6ops 
WG to work on the minimal required set of IPv6 transition
tools/mechanisms, and Itojun and I plan to be fairly conservative
about enforcing the requirements of the charter in this area.

It is our goal for v6ops to primarily focus on the operational 
and security issues that arise in the deployment of IPv6, not on 
anticipating transition issues and developing a transition toolkit.

This does not mean that we won't standardize any new transition
tools.  However, we will only standardize a new tool if it solves
a well-defined, general IPv6 deployment problem that cannot be 
satisfactorily addressed using other means (such as existing 
transition tools and/or operational practices).

The IETF may also develop transition tools for IPv6 deployment
problems related to specific application and/or transport protocols,
but that work would be done in the proper WGs/areas, not within
v6ops.

Margaret

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 9 Sep 2002 14:56:44 -0700

Brian E Carpenter wrote:
> > lowest-common-denominator solutions and ignore solutions 
> that provide 
> > a better fit.
> 
> It's hard to avoid special pleading (since the transition 
> solution with my name on it is in the list), but I do think 
> that there is a strong argument for concentrating on LCD 
> solutions for the first wave.

If you look at the sequence of work done in ngtrans you will see that it
started with a strong focus on LCD approaches, but moved on to address
the reality that one size does not fit all. Debates about what is useful
or necessary will be useless until we complete the environment
description documents. Once we get a set of problem statements in front
of the whole group it will be easier to see from the diverse
requirements that there is no LCD. It is a nice fantasy to believe that
a core-out approach will be simple and easy, but when the deployment
hits CPE that can't be replaced or upgraded (or in the case of cable
modems there is not even a plan for upgrading the fundemental docsis
standard to consider IPv6), whats next? 

The charter of the new WG will need to evolve once the current set of
documents are written, as they will form the real problem statement. In
their absence, the charter is limited to the viewpoint of core network
providers and the operational challenges in getting that environment
running. 

> 
> We might contemplate a separate IETF activity for advanced 
> transition solutions.

That is unlikely since the group that would look at those is being shut
down. 

Tony