Subject: Re: [v6ops] v6ops Digest, Vol 8, Issue 1

From: 孙琼 <[email-masked]>
Date: Sat, 2 Apr 2011 07:42:57 +0800

Hi Roberta,

Thank you very much for your comments. I'm Sun Qiong and the co-author of
this slides.

I agree with you that the allocation of the address for AFTR could be
seperated from address allocation process. But as a common problem for
tunnel-based solution, we should find a reasonable way to pass that address
to B4, either by static configuration, TR-069 based configuration, or a new
DHCPv6 option. Maybe the best way is to pass the address via DHCPv6 which
would also need to take some changes in DHCPv6 server.

I personally think that flexible addressing is good from addressing
assignment aspect. However, current stateful solution would also bring a lot
of burden for session-based state management, traffic logging, etc. And it
would also have scalability problem to deal with massive concurrent sessions
especially for large SPs. As a result, we think stateless solutions with
flexible addressing ability should be recommended .

BTW, we have proposed a solution called LAFT6 (
http://tools.ietf.org/id/draft-sun-v6ops-laft6-01.txt), which aims to
achieve lightweight state-management (largely reduce the number of state
entries) and lightweight addressing (flexible addressing with no address
format). It is a tradeoff between current session-based stateful solution
and totally stateless solution. We would be appreciated to have your
comments as well.

Best regards

Qiong

---------- Forwarded message ----------
> From: Maglione Roberta <[email-masked]>
> To: "[email-masked]'" <[email-masked]>
> Date: Fri, 1 Apr 2011 09:56:33 +0200
> Subject: [v6ops] comments on stateless mechanism presentation
> Hello,
>   I would like to try to clarify the comment I made yesterday on slide 6.
> The third bullet of this slide says:
> "ISPs may adopt flexible address rules, no extra requirements on address
> format and address allocation"
>
> My understanding of this is that the purpose of this slide is to compare
> the impacts of the different transition mechanisms have on the address
> allocation scheme that the ISP has to use.
>
> dIVI uses a specific format to build the IPv6 address, made by
> concatenating an IPv6 prefix with an IPv4 + a port, thus it introduces some
> constrains on the addresses scheme to be used in the network
>
> While DS-Lite does not have any specific requirement on the IPv6 prefix
> delegated to the customers.
>
> The table in slide 6 in the first column for DS-LIte says:
> "Address of the tunnel end to be passed"
>
> This sentence refers to the address of the AFTR that needs to be
> provisioned on the B4 in order to allow the B4 to setup the IPv4 over IPv6
> tunnel.
>
> This is a provisioning issue (and BTY it solved by DHCPv6 option specified
> in draft-ietf-softwire-ds-lite-tunnel-option, now in RFC queue).
> This point is NOT related to the address allocation scheme to be used by
> the ISP, thus I don't think it should appear in this table.
>
> If you want to compare the provisioning aspects of the different techniques
> I would suggest adding a separate slide for them.
>
> Going to your slide 11: Flexible addressing
> In my opinion DS-Lite has some advantages compared to dIVI on Flexible
> addressing point because, as I said before, DS-Lite does not requires a
> specific format for the IPv6 prefix.
>
> Thanks,
> Regards,
> Roberta
>
>
>
>
>
>