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

Hello Peng,

Some comments inline...

On 11/3/11 5:12 AM, "Peng Wu" <peng-wu@foxmail.com> wrote:

> 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.

Per-session NAT is not needed if:

- the B4 performs NAT or
- Each host has a unique IP and a known port space.

Our implementation performs NAT without any per session state.

> 
> 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.

I think ALG is an application issue and can only be fully solved when all
applications make use of PCP.

> In ds-lite with static concentrator
> port allocation, the subscriber still doesn't know its public IPv4
> address/port 
> without per-session PCP process.

Yes, that is a good point. We devised an extension to PCP to return the
public IP and port range. Therefore a single message would be needed.

>> 
>> 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
>> 
>> 
>> 
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires