Re: [v6ops] comments on stateless mechanism presentation

[Maglione Roberta <[e-mail]>]

Hi Qiong,
   Thanks for your reply, please see inline.
Best regards,
Roberta


________________________________
From: sunqiong [mailto:[e-mail]]
Sent: venerdì 1 aprile 2011 18.14
To: Maglione Roberta; '[e-mail]'
Cc: 解冲锋
Subject: Re: [v6ops] comments on stateless mechanism presentation

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.

[RM] I agree with you that with DS-Lite there is a need to find a way to pass to the B4 the information about the tunnel terminator, but this in my opinion  is just a provisioning issue thus it is not related to the addressing scheme to be used in the Service Provider’s network, that’s why I was suggesting to add a separate slide to talk about provisioning.

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 with massive concurrent sessions especially for large SPs. As a result, we think stateless solutions with flexible addressing ability should be recommended .

[RM] Each solution has its own pros and cons, but we should be careful and use comparable criteria when we try to compare different approaches


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.
[RM] Thanks for the pointer, I’ll take a look at your draft.

Best regards
 Regards,
Roberta
Qiong


________________________________
发件人： Maglione Roberta
发送时间： 2011-04-01  15:56:33
收件人： '[e-mail]'
抄送：
主题： [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
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

[cid:[e-mail]]Rispetta l'ambiente. Non stampare questa mail se non è necessario.