Re: [Softwires] Fw: New Version Notification fordraft-cui-softwire-b4-translated-ds-lite-04.txt

"Peng Wu" <peng-wu@foxmail.com> Thu, 03 November 2011 12:12 UTC

Return-Path: <peng-wu@foxmail.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 7FD891F0C70 for <softwires@ietfa.amsl.com>; Thu, 3 Nov 2011 05:12:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.073
X-Spam-Level:
X-Spam-Status: No, score=0.073 tagged_above=-999 required=5 tests=[AWL=-1.177, BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495, J_CHICKENPOX_52=0.6, MIME_BASE64_TEXT=1.753]
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 3+D8Nveq9k-C for <softwires@ietfa.amsl.com>; Thu, 3 Nov 2011 05:12:51 -0700 (PDT)
Received: from smtpbg52.qq.com (smtpbg52.qq.com [64.71.138.43]) by ietfa.amsl.com (Postfix) with SMTP id CE19B1F0C5F for <softwires@ietf.org>; Thu, 3 Nov 2011 05:12:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907; t=1320322361; bh=E/ytHH0H2aUuVMi+ob9ZB3yN+0Y8v3q8Pvc8ujdJV8I=; h=X-QQ-mid:Received:X-QQ-SSF:Date:From:To:Reply-To:Subject: References:X-Priority:X-Mailer:Mime-Version:Message-ID: Content-Type:Content-Transfer-Encoding; b=LPilrqcWq3VU7Q62GeePEFPJOWVzqynYB3sF6nRkfoSMPWrXZduDiYiw2D9XC44P3 oChkApKDIClzw4TYJ/UkyygzAnRbab4Ls2rTj0M3I4Tic2iWnxIPm982VPoScRC
X-QQ-mid: esmtp4t1320322359t994t30589
Received: from PengWU-PC (unknown [115.231.56.19]) by esmtp4.qq.com (ESMTP) with id ; Thu, 03 Nov 2011 20:12:38 +0800 (CST)
X-QQ-SSF: 00000000000000F0FwF000000000000
Date: Thu, 03 Nov 2011 20:12:39 +0800
From: Peng Wu <peng-wu@foxmail.com>
To: Olivier Vautrin <ovautrin@juniper.net>, softwires <softwires@ietf.org>
References: <CAD71BA9.173C2%ovautrin@juniper.net>
X-Priority: 3
X-Mailer: Foxmail 7.0.1.82[cn]
Mime-Version: 1.0
Message-ID: <2011110320123984925532@foxmail.com>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Subject: Re: [Softwires] Fw: New Version Notification fordraft-cui-softwire-b4-translated-ds-lite-04.txt
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: peng-wu <peng-wu@foxmail.com>
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: Thu, 03 Nov 2011 12:12:52 -0000

Hi Olivier,

see inlines :)
--------------
Peng Wu
>Hello, thanks for this interesting draft.
>
>In your use case, could you explain if every CPE/Host need to reach
>Internet? That would be the case in a typical Broadband deployment but
>perhaps not in your deployment scenario.
Could be every CPE/Host.
>
>If all CPE needs Internet access, all of them with an IP@ need a dedicated
>"bucket of ports" installed in the Concentrator. Which means that we could
>just have a static allocation of ports in the Concentrator instead of
>DHCP/PCP mechanism as described in your draft.
Well, we've thought of this.
There're two differences here.

The first and the major one is that, if we just take ds-lite and have static 
port set allocation in the concentrator, the concentrator still has to keep 
the per-session NAT table and perform the translation, while in lightweight 
4over6, NAT happens on CPE and the concentrator just perform 
encapsulation/decapsulation, with a per-subscriber mapping table.

The second one is that in lightweight 4over6, with one-time DHCP/PCP,
the subscriber learns its public IPv4 address. This brings convenience and 
eases the ALG problem to a certain extent. In ds-lite with static concentrator 
port allocation, the subscriber still doesn't know its public IPv4 address/port 
without per-session PCP process.
>
>My point is we could have a Stateless mechanism in the Concentrator as
>described in SD-NAT (draft-penno-softwire-sdnat-01) and just use regular
>DHCP/Radius on the CPE to get a dynamic address allocation with the same
>result.
>
>What do you think?
>
>Cheers,
>Olivier
>
>
>On 11/2/11 8:06 AM, "peng-wu@foxmail" <peng-wu@foxmail.com> wrote:
>
>>Hi all,
>>
>>We've submitted a -04 version of the b4-translated-ds-lite draft.
>>It describes the per-user-state IPv4-over-IPv6 mechanism with port set
>>support, which can be achieved through some extensions to ds-lite.
>>There are discussions going on upon this topic during and after the
>>Interim meeting.
>>We've received quite a lot offline comments/suggestions, and made
>>progresses accordingly.
>>
>>The draft is available on
>>http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-04
>>Please provide your valuable comments. And hopefully we'll present it in
>>Taipei.
>>
>>
>>
>>
>>
>>
>>
>>u---
>>A new version of I-D, draft-cui-softwire-b4-translated-ds-lite-04.txt has
>>been successfully submitted by Qiong Sun and posted to the IETF
>>repository.
>>
>>Filename:	 draft-cui-softwire-b4-translated-ds-lite
>>Revision:	 04
>>Title:		 Lightweight 4over6 in access network
>>Creation date:	 2011-10-30
>>WG ID:		 Individual Submission
>>Number of pages: 24
>>
>>Abstract:
>>   The dual-stack lite mechanism provide an IPv4 access method over IPv6
>>   ISP network for end users.  Dual-Stack Lite enables an IPv6 provider
>>   to share IPv4 addresses among customers by combining IPv4-in-IPv6
>>   tunnel and Carrier Grade NAT.  However, in dual-stack lite, CGN has
>>   to maintain active NAT sessions, which could become the performance
>>   bottom-neck due to high dynamics of NAT entries, memory cost and log
>>   issue.  This document propose the lightweight 4over6 mechanism which
>>   moves the translation function from tunnel concentrator (AFTR) to
>>   initiators (B4s), and hence reduces the mapping scale on the
>>   concentrator to per-customer level.  For NAT44 translation usage, the
>>   mechanism allocates port restricted IPv4 addresses to initiators in a
>>   flexible way independent of IPv6 network in the middle.
>>
>>                  
>>        
>>
>>
>>The IETF Secretariat
>>
>>_______________________________________________
>>Softwires mailing list
>>Softwires@ietf.org
>>https://www.ietf.org/mailman/listinfo/softwires
>
>
>