[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
- [v4tov6transition] V0.4 Agenda for WebEx meeting … Tina TSOU
- Re: [v4tov6transition] V0.4 Agenda for WebEx meet… Joel Jaeggli
- Re: [v4tov6transition] V0.4 Agenda for WebEx meet… Tina TSOU
- Re: [v4tov6transition] V0.4 Agenda for WebEx meet… Joel Jaeggli
- Re: [v4tov6transition] V0.4 Agenda for WebEx meet… Tina TSOU
- Re: [v4tov6transition] V0.4 Agenda for WebEx meet… jouni korhonen
- Re: [v4tov6transition] V0.4 Agenda for WebEx meet… Ronald Bonica
- Re: [v4tov6transition] V0.4 Agenda for WebEx meet… Joel Jaeggli
- [v4tov6transition] a few quick reviews of the doc… Jari Arkko
- Re: [v4tov6transition] a few quick reviews of the… Yiu L. Lee
- [v4tov6transition] draft-carpenter-v4v6tran-frame… Brian E Carpenter
- Re: [v4tov6transition] a few quick reviews of the… Joel Jaeggli