Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation

Rémi Després <despres.remi@laposte.net> Wed, 29 February 2012 10:48 UTC

Return-Path: <despres.remi@laposte.net>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D59721F890A for <softwires@ietfa.amsl.com>; Wed, 29 Feb 2012 02:48:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.913
X-Spam-Level:
X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgNWs3vszrul for <softwires@ietfa.amsl.com>; Wed, 29 Feb 2012 02:48:15 -0800 (PST)
Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id 6400821F8907 for <softwires@ietf.org>; Wed, 29 Feb 2012 02:48:15 -0800 (PST)
Received: from [192.168.1.75] ([89.170.204.217]) by mwinf8503-out with ME id fmoA1i00C4hwz7503moA5C; Wed, 29 Feb 2012 11:48:13 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Rémi Després <despres.remi@laposte.net>
In-Reply-To: <CAKcc6AcayvpfJPhbGcqCuo1B-chvQiF1pX01J8eeEg+qwYdNXg@mail.gmail.com>
Date: Wed, 29 Feb 2012 11:48:09 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <941C4201-CC42-4E27-A1E1-7E3970FC6F77@laposte.net>
References: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr> <CAKcc6AcvYxT6DXgg4BvNWNVTkNT2SqfbFD-nPnwDx0+P0t9QWg@mail.gmail.com> <94C682931C08B048B7A8645303FDC9F35D88A1402B@PUEXCB1B.nanterre.francetelecom.fr> <CAKcc6AcN8YQb3rRsHGhGrhztsg4Xh1ET-Fxnw=tfr52rwU01og@mail.gmail.com> <F2C46F4F-6AF9-45C9-B286-2BB4E8F4DA34@laposte.net> <CAKcc6AfFEYU-vEXB6jpxDBUNbYw_CuLu4ztd90z5CN9TVGKUTA@mail.gmail.com> <418FA4E2-7586-4277-ABC6-7025823B6D0D@laposte.net> <CAKcc6AfTa4ueNEOBgZ3WP+Z=QEuJY+NfrB6rV5Q4ZM7+wvZbhw@mail.gmail.com> <A3138136-BB26-45FA-9BEC-8526BEAFE800@laposte.net> <CAKcc6AcayvpfJPhbGcqCuo1B-chvQiF1pX01J8eeEg+qwYdNXg@mail.gmail.com>
To: liu dapeng <maxpassion@gmail.com>
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG <softwires@ietf.org>, Softwire Chairs <softwire-chairs@tools.ietf.org>
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Feb 2012 10:48:29 -0000

Le 2012-02-29 à 10:53, liu dapeng a écrit :

> 2012/2/28, Rémi Després <despres.remi@laposte.net>:
>> 
>> 2012-02-28 15:06, liu dapeng :
>> ...
>>> 2012/2/27, Rémi Després <despres.remi@laposte.net>:
>> ...
>>>> The draft only reflects the wish of an number of operators to have a
>>>> stateless solution standardized, acknowledging that this is in addition
>>>> to
>>>> the more advanced stateful solutions (it doesn't even include the word
>>>> "superior").
>> ...
>>> Thanks for the discussion but the fundamental question is:
>>> 
>>> If we consider [CPE(stateful) + BR(partially stateless maybe)] as a
>>> stateless solution,
>>> 
>>> then, why  [CPE(stateless) + xlate(stateful)] is not a stateless solution?
>> 
>> 
>> What I see as important is that IPv6-only routing can be deployed ASAP
>> without sacrificing a good residual IPv4 service, including where ISPs
>> prefer per-user stateless operation.
>> 
>> The point has already been made that functions are defined in the draft as
>> "stateless" if they don't need (for IPv4 over IPv6) any "per-user" state.
>> A CE can therefore be considered stateless *in the draft* even if it has
>> NAT44 (a function that is purely IPv4, and whose statefulness is per
>> session).
>> Because of that, the draft is self consistent an doesn't need to be
>> modified.
>> 
>> I do hope that, with these additional explanations, and in order to avoid
>> waste of energy, you can accept to join a consensus that it is time to close
>> this discussion and accept the draft.
>> 
>> 
>> Looking forward to further discussions on solutions themselves,
>> Regards,
>> RD
>> 
> Hello Remi
> 
> Firstly, this draft will mis-lead other operators thinking that this
> is a pure stateless solution from the title and the document (maybe
> terminology such as "Maping" is better). IETF WG should not hurry up
> without the correct description on what the document is. For my
> understanding, both of above two solutions are stateful solution. Even
> in the first case of BR' side there are still stateful information for
> control plane.
> 
> Secondly, since this is also stateful solution principally. Then why
> IETF need to invent a second wheel about the same scenario,


> should
> IETF obsolete previous one such as DS-Lite, then start to work on
> this?

Surely not.
This debate has been finished when it was decided that Softwire would work ALSO on solutions that are stateless, at least in ISP gateways to the IPv4 Internet.

You may have not been personally part of this consensus, which is obviously your right, but the consensus remains.
Since no one prevents you from using stateful solutions of you choice, trying to prevent those who want a more stateless solution to have a specification isn't, IMHO, fair contribution to standardization.

RD  
  
> 
> Thanks
> 
> -Dapeng
> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>