Re: [v6ops] I-D Action: draft-kuarsingh-wireline-incremental-ipv6-00.txt

Victor Kuarsingh <victor.kuarsingh@gmail.com> Thu, 21 July 2011 03:35 UTC

Return-Path: <victor.kuarsingh@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4940321F8906 for <v6ops@ietfa.amsl.com>; Wed, 20 Jul 2011 20:35:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psGTnh5j6U6C for <v6ops@ietfa.amsl.com>; Wed, 20 Jul 2011 20:35:12 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A56F221F88B6 for <v6ops@ietf.org>; Wed, 20 Jul 2011 20:35:12 -0700 (PDT)
Received: by ywp31 with SMTP id 31so464871ywp.31 for <v6ops@ietf.org>; Wed, 20 Jul 2011 20:35:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:content-transfer-encoding; bh=2tRpfgjONJPSTURyUveDmgVjxKoPYAuREvB/2lR0hG4=; b=XXuiHW885ubhIIMCZ3FSDbAzsqRjG4mZCRcxsgkSJcAfEq9NOxip9YWQvjdhYzbg+f dnHlwEXTCnYdon2LWcD8MicCLydHX5aNKQeHfE8gjmMK1oPqNDfoOw+WxK6VRB7GYV50 6YGT92VevC+fQbMNJgTfA5k1oLnieuMtTIEus=
Received: by 10.151.2.1 with SMTP id e1mr68655ybi.375.1311219308230; Wed, 20 Jul 2011 20:35:08 -0700 (PDT)
Received: from [192.168.1.128] (CPEc0c1c0d0d7b7-CM001a666bafe6.cpe.net.cable.rogers.com [99.230.122.203]) by mx.google.com with ESMTPS id y13sm970529ybj.28.2011.07.20.20.35.06 (version=SSLv3 cipher=OTHER); Wed, 20 Jul 2011 20:35:07 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.0.0.100825
Date: Wed, 20 Jul 2011 23:35:02 -0400
From: Victor Kuarsingh <victor.kuarsingh@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, IPv6 Operations <v6ops@ietf.org>
Message-ID: <CA4D1256.101E0%victor.kuarsingh@gmail.com>
Thread-Topic: [v6ops] I-D Action: draft-kuarsingh-wireline-incremental-ipv6-00.txt
In-Reply-To: <4E277F86.6010204@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [v6ops] I-D Action: draft-kuarsingh-wireline-incremental-ipv6-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jul 2011 03:35:13 -0000

Brian,

This draft (which requires more work) was to be a narrow scope option
which can be used by operators if they so choose.  The goal was to provide
a "recipe" that could be used.  In talking with some vendors, it appears
that there are still customers (Operators) which are still confused and/or
on the fence as to how they will approach IPv6 transition (sure I know may
have it figured out - and that's great).

This draft would need to point (rightfully so) to RFC6264 which outlines a
good and boarder scope approach to IPv6 transition and use of CGN.  There
is also a link to the transition framework document
(draft-ietf-v6ops-v4v6tran-framework) which this draft was to also follow.

Due to the rawness of the -00 rev, much of the content I wanted to add is
missing and would make it into a -01 rev.  I am missing much content which
I think is valuable for operator consumption and/or consideration

Included in an updated additional content would be:

- Defining logical waypoints which could be used by operators to move
between phases (I.e. Condition of external content, internal services,
tools/readiness, etc)
- Better explanation for the rationale for choosing this specific mix of
technologies and the phase order
- I had specific reasoning as to what the traffic conditions may be like
at each one of the phases as well (which supports the notion of keeping as
little traffic on the CGN/Relay assist path as possible)
- I would also add in options/suggestions as to how operators could grow
their transition environment (supporting this mix of technologies), deal
with routing etc.

Again, this was to be quite operator focused and I was hoping that this
type of information could help some operators who may be still in the
early analysis phases develop an approach to add in IPv6 (with the obvious
understanding that CGN will likely play a part in many networks - like it
or not).

I would be interesting in your (or others) thoughts.  As I had described
to someone else the other day, I think the IETF and folks have done an
excellent job providing all the "ingredients" for IPv6 transition but
wanted to help promote the "recipe" side now - as noted by
draft-ietf-v6ops-v4v6tran-framework.

Regards,

Victor K


On 11-07-20 9:23 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com>
wrote:

>Hi,
>
>This is an interesting draft. Could the authors comment on whether
>they are suggesting significant differences to the procedures
>suggested in RFC 6264 (the Incremental CGN document)? In any case
>I think you need to refer to that RFC, in a positive or negative way
>at your choice ;-)
>
>Regards
>   Brian Carpenter
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops