Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG

Peng Wu <pengwu.thu@gmail.com> Tue, 26 June 2012 03:34 UTC

Return-Path: <pengwu.thu@gmail.com>
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 8EFCD21F8549 for <softwires@ietfa.amsl.com>; Mon, 25 Jun 2012 20:34:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.553
X-Spam-Level:
X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 G-KjRnlc8DvU for <softwires@ietfa.amsl.com>; Mon, 25 Jun 2012 20:34:47 -0700 (PDT)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E805321F8551 for <softwires@ietf.org>; Mon, 25 Jun 2012 20:34:46 -0700 (PDT)
Received: by qadz3 with SMTP id z3so1703319qad.10 for <softwires@ietf.org>; Mon, 25 Jun 2012 20:34:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2KxsQm4gHXefn6q7cMiGM+6NQCYUmPlH/UNTRd2rSOw=; b=OoNv0HS3hxzIEsaHp76sAdeVVsNzrHwyPsg+G3ch3w4sXgxICNoZ3xEJYMDeHcPNBA EEggMvhZn3lFFpFPDUIyrCADYWL1ylEQoRNlv7dAeva8lomNZDG8ryfPrIvJJbAOQ28r pH2ORNtSvy+BH0vtN83CffEH0bHM6GFj4O27WGhyegPRqfdSC14v+uYK7MLbxSvJT2Ts KGklV/neUWI1nO62xuNxw2MJzsL9dCw9bvbIqAxPbleWl/SbscZXVqKWSYjmI7BjMUDT qaNWr5/EYQhR1HxLX3+an1FItAUuGxWg3tEXCxf3zO230fqp1+1dhI6K731PLpwsMQ7t 3jXw==
MIME-Version: 1.0
Received: by 10.224.207.4 with SMTP id fw4mr23468757qab.82.1340681686323; Mon, 25 Jun 2012 20:34:46 -0700 (PDT)
Received: by 10.229.216.212 with HTTP; Mon, 25 Jun 2012 20:34:46 -0700 (PDT)
In-Reply-To: <4FE86A26.2030000@joelhalpern.com>
References: <CC0CC5BF.226A9%yiu_lee@cable.comcast.com> <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> <4FE86A26.2030000@joelhalpern.com>
Date: Tue, 26 Jun 2012 11:34:46 +0800
Message-ID: <CAC16W0ABCsgLq9woUfXdv0RU1rKa+mS=Juwc-S29La5qXhkW7Q@mail.gmail.com>
From: Peng Wu <pengwu.thu@gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG
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: Tue, 26 Jun 2012 03:34:47 -0000

Hi Joel,

Thanks for the clarification. Fully agree with the 4 types.

Two additional comments:
1. From implementation view, the 2nd and the 3rd are more close to the
4th because there are binding table lookup procedure in data plane,
while the 1st depends on algorithmic address calculation essentially.
Some may argue that there are mutliple rules even in the 1st case, but
that's a specific feature in IPv4-over-IPv6 scenario with address
sharing demand, only because we want to include port set information
into IPv6 address beside the IPv4 address and there may be not enough
bits in IPv6 address. Generally this is not a necessary feature for
pure stateless solution.(take 6RD and SIIT as example)
2. In this specific context, I quote what is the defined in the
stateless  motivation
draft(http://datatracker.ietf.org/doc/draft-ietf-softwire-stateless-4v6-motivation/):
" Stateless 4/6 solution  (or stateless solution in short): denotes a
solution which does not require any PER-USER state (see Section 2.3 of
[RFC1958]) to be maintained by any IP address sharing function in the
Service Provider's network.  This category of solutions assumes a
DEPENDENCY between an IPv6 prefix and IPv4 address."


On Mon, Jun 25, 2012 at 9:39 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
> This appears to mix different kinds of state.
> In particular, with regard to state in network resident boxes, there can be:
> General state covering all subscribers;
> Per subscriber state provisioned state;
> Per subscriber dynamic, but not flow specific state;
> per flow state.
>
> All are state.
> The first is clearly permitted.
> The fourth is clearly not permitted in a "stateless" solution.
> Some descriptions of "stateless" have allowed for the middle two, while
> others have prohibited it.  I have no opinion on what the WG "agreement" is
> on the scoping.  But we need to be careful about what we mean about "state".
>
> Yours,
> Joel
>
>
> On 6/25/2012 2:51 AM, Qi Sun wrote:
>>
>> Hi Satoru,
>> In MAP 1:1 mode, if there are 10000000 subscribers, there would be
>> 10000000 MAP domains which a BR has to manage. I think that will create
>> a huge mapping table on the BR, which is called 'state' that stateful
>> solutions deal with.
>> Best Regards!
>> Qi Sun
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires