Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01

Qi Sun <sunqi.csnet.thu@gmail.com> Sat, 09 June 2012 03:35 UTC

Return-Path: <sunqi.csnet.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 955A821F85AF for <softwires@ietfa.amsl.com>; Fri, 8 Jun 2012 20:35:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, 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 BLh8c9nQDXx3 for <softwires@ietfa.amsl.com>; Fri, 8 Jun 2012 20:35:44 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6F921F84E7 for <softwires@ietf.org>; Fri, 8 Jun 2012 20:35:32 -0700 (PDT)
Received: by dacx6 with SMTP id x6so3124067dac.31 for <softwires@ietf.org>; Fri, 08 Jun 2012 20:35:31 -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=UsJu0MAiy4pHJu4+qce7+epd+OQB/1e6T+juDjUhNtw=; b=xTfjlnhSSgTtzLbyChOvMKi9NjvmWc6SvtzM4SeE31p6dK3m2fGESTPhoZqr3SVKic zJqk8tBhrLDwcZf5aDDo+zQ++PZ6x4Vxb8Fki80xcBpFtRqGYh7U0erqd4qKHRx8rBXK KfvZ8Sy2/nfWOIYvTwEyXE9eiWYNIRsf64o0IDhvljJZoil80YdxTqZJeANaMvhYGwrk vER4LhIbkkttjB9whn5C2Z+J7sdTCPMCO/3XTKhDXj9I4WQdqVLiIVz9VC+4sRknTIJ6 lC5xgiaIwAu8J9ZZxZBde2toRLYOmcOWI72oWzzVfBaWqj1NpH0blOID2p58NgtaiiO8 4V/A==
MIME-Version: 1.0
Received: by 10.68.195.106 with SMTP id id10mr1902999pbc.116.1339212931753; Fri, 08 Jun 2012 20:35:31 -0700 (PDT)
Received: by 10.142.105.1 with HTTP; Fri, 8 Jun 2012 20:35:31 -0700 (PDT)
In-Reply-To: <98E982A8-4730-46A7-9795-A7BB2162D1DC@employees.org>
References: <CBF23F0B.21901%yiu_lee@cable.comcast.com> <39098095-7D8B-44AA-9492-213283E89A4B@employees.org> <CAH3bfAD1RoE7pqAj-9wLv2L6JJcgWtSH76d3S8vQOB=7HYzJBA@mail.gmail.com> <1D677EF2-C5D8-4007-8F46-756C2A3939C4@employees.org> <CAC16W0A2bF=YhYH5bRY9u2My-E1yH8au2NFrELNRmN+StmtQrQ@mail.gmail.com> <98E982A8-4730-46A7-9795-A7BB2162D1DC@employees.org>
Date: Sat, 09 Jun 2012 11:35:31 +0800
Message-ID: <CAAtO+X=7bmgycfRfB0SGg3UP7O+8Q8HV8RYoMFopgw+=0SXGXw@mail.gmail.com>
From: Qi Sun <sunqi.csnet.thu@gmail.com>
To: Ole Trøan <otroan@employees.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "softwires@ietf.org" <softwires@ietf.org>, Yong Cui <cuiyong@tsinghua.edu.cn>
Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01
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: Sat, 09 Jun 2012 03:35:44 -0000

Hi Ole,

In your previous Email you wrote,
> in MAP you do all of that with one single DHCPv6
option...

IMHO, that's because the one DHCPv6 option contains so many KINDS of
information (e.g. PSID, BR's prefix or address, see draft of
map-dhcp-option ).

And with separate provisoning processes , it's easier to detect
problems if the whole process fails.

Best Regards!

Qi Sun

On 6/8/12, Ole Trøan <otroan@employees.org> wrote:
> Peng,
>
>> Now there are actually 3 directions for IPv4-over-IPv6 mechanisms,
>> they have respective application scenarios, pros and cons.
>> 1)stateless,  4rd, MAP
>> 2)per-flow stateful: DS-Lite
>> 3)per-user stateful: public 4over6, lightweight 4over6
>> As Ole said, the problem is that, do we want serveral simple
>> mechanisms, or one super-compatible mechanism with different modes.
>>
>> Now Given that a) the WG has accomplished DS-lite; b)MAP follows the
>> stateless motivation all along the way; c)The signifcant changes to
>> make MAP super-compatible, I vote for we define the third type,
>> per-user stateful mechanisms independently.
>
> actually there are no significant changes to the MAP specification, the
> per-user stateful mechanism is just intrinsically supported by MAP. it is a
> corner case, and it would be more work in the specification to "ban" this
> operational mode, than to support it.
>
> btw, one thing that appears most complicated is provisioning; currently it
> looks like L4over6 suggests using 2 DHCP sessions and 3 DHCP options to get
> provisioned. firstly a RFC6334 exchange to get the DS-lite tunnel up, then a
> DHCPv6 option for the DHCPv4 server address, and then a DHCPv4 exchange to
> get the IPv4 address, and then a new DHCPv4 option to get the port set. that
> seems to me to be quite a few moving parts, and quiet a few corner cases to
> be specified when one or more of the above fails. in MAP you do all of that
> with one single DHCPv6 option...
>
> cheers,
> Ole
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>