[v4tov6transition] a few quick reviews of the documents for today

Jari Arkko <jari.arkko@piuha.net> Tue, 21 September 2010 02:57 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: v4tov6transition@core3.amsl.com
Delivered-To: v4tov6transition@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 211E53A68CD for <v4tov6transition@core3.amsl.com>; Mon, 20 Sep 2010 19:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.793
X-Spam-Level:
X-Spam-Status: No, score=-101.793 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_00=-2.599, MISSING_HEADERS=1.292, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7o2TJcvsMBBn for <v4tov6transition@core3.amsl.com>; Mon, 20 Sep 2010 19:57:45 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 90E903A68D8 for <v4tov6transition@ietf.org>; Mon, 20 Sep 2010 19:57:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 965C62CC43 for <v4tov6transition@ietf.org>; Tue, 21 Sep 2010 05:58:07 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AhXlREExi5n for <v4tov6transition@ietf.org>; Tue, 21 Sep 2010 05:58:07 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 6C5A92CC3C for <v4tov6transition@ietf.org>; Tue, 21 Sep 2010 05:58:06 +0300 (EEST)
Message-ID: <4C981F3D.3010603@piuha.net>
Date: Mon, 20 Sep 2010 19:58:05 -0700
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
CC: "v4tov6transition@ietf.org" <v4tov6transition@ietf.org>
References: <CD756BDD38444037876780C29D1F513B@china.huawei.com> <4C96F89D.7060107@bogus.com> <C15A3C4E5BBB4FAF927C1696520863DE@china.huawei.com> <4C96FF31.7060903@bogus.com> <3E6FF22239E240B787211166EC7129C9@china.huawei.com> <13205C286662DE4387D9AF3AC30EF456B01700C3C0@EMBX01-WF.jnpr.net>
In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B01700C3C0@EMBX01-WF.jnpr.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [v4tov6transition] a few quick reviews of the documents for today
X-BeenThere: v4tov6transition@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <v4tov6transition.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v4tov6transition>
List-Post: <mailto:v4tov6transition@ietf.org>
List-Help: <mailto:v4tov6transition-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Sep 2010 02:57:46 -0000

I am going through the documents in the agenda.

2. Problem Statements of IPv6 Transition of ISP 
draft-lee-v4v6tran-problem-02

Sent separately.


3. Framework for IP Version Transition Scenarios 
draft-carpenter-v4v6tran-framework-00

I think some of the text in Section 1 puts ipv6-only as the highest 
priority deployment model (and I'm saying this as a vendor of some IPv6 
only gear :-) Or am I reading your text wrong, Brian? I think ipv6-only 
is an important model and its importance grows as time goes by. But dual 
stack has not been dismissed just because we no longer have IPv4 
addresses, it is still a very much recommended model, too.

I do like the framework model. Everything we describe in terms of 
transition strategies would be good to describe under this framework.

The other thing that I wanted to say -- and this is consistent feedback 
that I get from various operators and customers -- is that I hope we are 
not developing an infinite stream of new scenarios and transition tools. 
I do recognize that one size does not fit all, but just like with IPv4, 
we need a relatively small set of tools and then the operators can 
deploy these in various combinations. Transition is 90% hard, boring 
work. We engineers, scientists, and vendors need to restrain our natural 
urge to invent new solutions to those cases where there is significant 
demand and a real problem.


4. Use Case For IPv6 Transition For a Large-Scale Broadband Network 
draft-huang-v4v6tran-broadband-usecase-00

Did not have time to read this.


5. IPv6 Transition Guide For A Large ISP Providing Broadband Access 
draft-yang-v4v6tran-ipv6-transition-guide

This is a very interesting document, I like reading about specific 
networks and what you see as the alternatives and pros/cons in your 
specific case. A couple of questions/comments:

Section 1: What's "the existing single transition technology" referred 
from the text?

I like the contrasting of various deployment options in Section 2.1. 
(Does Section 2.1.1 assume that dual stack == simultaneous roll-out of 
IPv6 in all routers in the network? Many networks employ a gradual 
approach to deployment, converting a small number of routers at a time 
and/or acquiring new devices for pure IPv6-only service on a 
case-by-case basis. The pros/cons may be different if you do this 
instead of a one-time rollout.)


6. IPv6 Transition Cable Access Network Use Cases 
draft-lee-v4v6tran-usecase-cable-00

Good stuff. A few comments:

>   According to [I-D.arkko-ipv6-transition-guidelines], native dual-
>    stack is the simplest model for transition.  However, this requires
>    the entire network to be dual-stack.  Moreover, the provisioning
>    system and other support systems must be upgraded to support IPv6.
>    Most operators will need to upgrade the network in phases along with
>    the provisioning system(s) and supporting systems.  During the
>    transition period, there will be IPv4-only islands.  In order to
>    offer dual-stack access to users over IPv4 islands, operators may
>    consider the use of tunneling technologies such as 6rd and MPLS.

I think that is actually consistent with the advice in our draft (but 
maybe we need to change something if that was not clear). On any 
specific part of the network, native and dual stack are preferred if you 
can do them, but it is indeed natural that most networks employ a 
combination of tools in different parts. My own network, for instance, 
has a combination of IPv6-only, dual-stack, and tunneled IPv6 service in 
different routers/links. I would have avoided the tunneled solution in 
one part of the network, but it was not possible at the moment.

More reviews to follow...

Jari