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

Peng Wu <pengwu.thu@gmail.com> Fri, 08 June 2012 14:02 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 A138F21F86F2 for <softwires@ietfa.amsl.com>; Fri, 8 Jun 2012 07:02:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level:
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 cO3uN8Tz8o3R for <softwires@ietfa.amsl.com>; Fri, 8 Jun 2012 07:02:09 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE7B721F86E2 for <softwires@ietf.org>; Fri, 8 Jun 2012 07:02:00 -0700 (PDT)
Received: by qcsq13 with SMTP id q13so1029523qcs.31 for <softwires@ietf.org>; Fri, 08 Jun 2012 07:02:00 -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=A5WTMChvjK37an1uFaRgGRhYSx2XT/QalidNVp7gAN4=; b=R2HuMtmYwPFrzZ3urZJkLTiAbWLsBDj9cTHfUWD3TcQ4VggF6Ild3GtCdY5AwQ/jKj ggWiOWwLW+IzNd2b9+U6/mArdxlJyFXGQx3CyO2TAIcTirFWe41hi97wrgOcLin50NdA IQZ5eGQt0SXUnSgybn6ckCbOggxwcl8Cf0XtIl48LvMEKXJ/MOr0UBVUG72S7QwVPYNS o4UUK+H50g9dHSFSzp0yNghK3397aljzllafpGVaEn/+4LUOImr+6J2dfzkKXU8HO+25 H1BQAYf2m5ifng5A8TEGSTR0HSy4HcDe2jWNsDZfS9FtZ6R5WuE4TCxXL2Ica169D13s T5XA==
MIME-Version: 1.0
Received: by 10.224.216.7 with SMTP id hg7mr4068794qab.3.1339164120045; Fri, 08 Jun 2012 07:02:00 -0700 (PDT)
Received: by 10.229.30.203 with HTTP; Fri, 8 Jun 2012 07:01:59 -0700 (PDT)
In-Reply-To: <CAFFjW4g_dQAUHCsGagfQf-U2YjKCwCrn99bSFx5-Nz0UvDG6ew@mail.gmail.com>
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> <CAC16W0DHUGDv2hXCgw_ia+FUrcJzBWb6dTN6m0h2EqMzLStWNQ@mail.gmail.com> <CAFFjW4g_dQAUHCsGagfQf-U2YjKCwCrn99bSFx5-Nz0UvDG6ew@mail.gmail.com>
Date: Fri, 08 Jun 2012 22:01:59 +0800
Message-ID: <CAC16W0A_Zp=_bzX_NC92DR_4bv5LSw9V1kgU6S_CxSMqJobt+A@mail.gmail.com>
From: Peng Wu <pengwu.thu@gmail.com>
To: Wojciech Dec <wdec.ietf@gmail.com>
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: Fri, 08 Jun 2012 14:02:09 -0000

Woj,

On Fri, Jun 8, 2012 at 7:44 PM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
> Peng,
>
> On 8 June 2012 11:35, Peng Wu <pengwu.thu@gmail.com> wrote:
>>
>> Ole,
>>
>>
>> > 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...
>>
>> Let me make it more precise.
>>
>> In lw 4over6, It's one DHCPv6 exchange and one DHCPv4 exchange.
>> DHCPv6 exchange to get the concentrator address and DHCPv4 server
>> address, two options at the same time. And of course the DHCPv4 server
>> could be collocated with the concentrator.
>> DHCPv4 exchange to retrieve the address and port-set at the same time.
>>
>> Now compared with MAP:
>> 1) Concentrator address is also needed in provisioning.
>> 2) DHCPv4 server address. This is only used when we want to separate
>> DHCPv4 server from the concentrator (For HA, redundancy...). With MAP
>> you cannot do this separation.
>
>
> Yes, because MAP doesn't require one to use another component like DHCPv4
> which is in itself subject to failure. That said, MAP can also use DHCPv4,
[Peng] PLEASE NOTE that I'm talking about concentrator/BR HA rather
than DHCPv4 server HA. It applies to both lw 4over6 and MAP, as long
as you want to implement per-user stateful mode by MAP

> but quite honestly what's the point of running DHCPv4 when all the useful
> info is available via DHCPv6?
[Peng] You can use DHCPv6 in lw 4over6, too. We list it in the draft
as a provisioning possibility. We explicitly use a DHCPv6 port-set
option, while you use a MAP rule. But that's not the point.

 >
>>
>> 3) DHCPv4 is used to provision the address and port-set to the
>> intiator. Now with MAP you provide this as a rule in DHCPv6. That's
>> the most significant difference
>>
>> So, I don't see lw4over6 provisioning more complicated than MAP...
>
>
> Current MAP = operating DHCPv6
> l24over6 =  operating DHCPv4 and DHCPv6 +  mechanisms to get to the DHCPv4
> server over IPv6
> There appears to be some evident complication there, for no clear benefit.
[Peng] Well, the information amount are the same, with the MAP form a
little difficult to understand from today's view, honestly.
DHCPv4 is chosen because evidently we are provision IPv4 information,
and we keep IPv4 and IPv6 addressing separated.
In my understanding, the story in original MAP/4rd is because of the
algorithmic mapping, you provision IPv4 address/port along with IPv6
address. Now you are talking about provison IPv4 as a rule. That's not
exactly the same.
Another question is that, how do you configure the rules in DHCPv6
now that it's per-user specific, and you do not have address mapping?
Relay all DHCPv6 messages to BR and generate the rules dynamically
there? I guess that's not a feature in original MAP.

I want to say that, please develop your understanding on this problem
from the fundamental per-user stateful feature, rather than directly
from MAP, a solution initially not designed for this case. That's not
fair.
>
> -Woj.
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>
>