[v4tov6transition] draft-yang-v4v6tran-ipv6-transition-guide-00

Rémi Després <remi.despres@free.fr> Tue, 28 September 2010 08:58 UTC

Return-Path: <remi.despres@free.fr>
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 E45393A6D31 for <v4tov6transition@core3.amsl.com>; Tue, 28 Sep 2010 01:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.081
X-Spam-Level:
X-Spam-Status: No, score=-0.081 tagged_above=-999 required=5 tests=[AWL=-0.732, BAYES_50=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
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 zfUkgaq++7yy for <v4tov6transition@core3.amsl.com>; Tue, 28 Sep 2010 01:58:59 -0700 (PDT)
Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.22]) by core3.amsl.com (Postfix) with ESMTP id AB62A3A6C94 for <v4tov6transition@ietf.org>; Tue, 28 Sep 2010 01:58:58 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2301.sfr.fr (SMTP Server) with ESMTP id 29C477000084; Tue, 28 Sep 2010 10:59:38 +0200 (CEST)
Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2301.sfr.fr (SMTP Server) with ESMTP id AFC2C7000086; Tue, 28 Sep 2010 10:59:37 +0200 (CEST)
X-SFR-UUID: 20100928085937720.AFC2C7000086@msfrf2301.sfr.fr
From: Rémi Després <remi.despres@free.fr>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 28 Sep 2010 10:59:37 +0200
Message-Id: <9AEB7593-D51C-4AB4-BBD2-57820C6816C0@free.fr>
To: YangGL <iamyanggl@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Cc: v4tov6transition@ietf.org
Subject: [v4tov6transition] draft-yang-v4v6tran-ipv6-transition-guide-00
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, 28 Sep 2010 08:59:00 -0000

Hi YangGL,

Thank you for the detailed and clear explanation about the view of China Telecom on v4tov6transition.

Here are various comments.

a) Sec. 2.2 (Transition of Metro IP network): Solution 2
"The existing access method does not need change, so China Telecom  does not need to provide home gateway to users" looks contradictory with "the newly added BRAS support IPv6 only". 

b) Sec 2.2 (Transition of Metro IP network): A 5th solution based on 6rd should be listed here.
It is mentioned in sec. 2.4.3 (solution 3 for Subscriber Access modes) as "deployed in the metro network").
It only takes 6rd Border Routers to be provisioned beside Core or Service routers. (Or just an upgrade of core routers if they can support 6rd, as already proposed at least by Cisco).
Pros include:
- All routed-mode CPEs provided by the operator deliver dual-stack service to customers.
- Customers can use their own 6rd compatible CPEs when they support RFC 5969. (It specifies the 6rd DHCPv4 option). 
- Hosts that eventually support RFC 5969, will get dual-stack service in single host sites.
- Deployment cost is extremely low (NEITHER metro-network routers NOR access networks need to be modified for this phase)
- The solution, already deployed, is simple and well understood.
Like the 6PE solution for core networks, of sec. 2.1.3 for core networks, it "is suitable for the first phase of IPv6 transition".

c) Sec 2.3 (Transition of Access network) Solution 2
Among the cons, the fact that home gateways that don't support DS-lite have to be modified or replaced seems to be missing.  

d) Sec 2.3 - Solution 3
- "There is no need to upgrade BRAS" and "BRAS needs to be upgraded to support 6RD" are contradictory. (The first sentence is the right one).
- "The network should be modified and upgraded when the network migrates to Native IPv6 in the future which leads to repeating investment of network", isn't quite right: the investment cost in the access network is not REPEATED since, in the access network, it is NULL. It is simply DEFERRED (which is more a pro than a con).  

Kind regards,
RD