Re: [Softwires] Motivation draft for stateless v4 over v6 solution
Hi, On 2011/05/27, at 3:19, Behcet Sarikaya wrote: You mean after merging with draft-chen-softwire-4v6-motivation-00.txt? then +1 from me. The authors of both drafts are now co-working to integrate unified version so we'll submit it soon. We would like to invite your comments. Any feedback for current version of both draft are also welcome. Best regards, --satoru ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Motivation draft for stateless v4 over v6 solution
On Thu, May 26, 2011 at 4:36 PM, Ole Troan otr...@employees.org wrote: I like the draft and I think it covers the motivational points well. as a general comment, I do think the document is too wordy. could the authors make the next revision terser or do you want me to propose text changes? Jacni: Yes, a little. Too many operational issues, is there any order of priority? Or just point out what you concern the most? I felt lost after reading it. :-) I would also suggest that you reference the sections in rfc1958 on state. we don't have a good success record in gleaning state in the middle of the network (NAT, N:1 VLANs, DHCP...), since the protocols we 'glean' from aren't designed to maintain softstate in the network. I see no reason why this document shouldn't be adopted as a working group document immediately. Jacni: +1 Cheers, Jacni cheers, Ole ___ 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
Re: [Softwires] Motivation draft for stateless v4 over v6 solution
On May 26, 2011, at 10:36 AM, Ole Troan wrote: I like the draft and I think it covers the motivational points well. as a general comment, I do think the document is too wordy. could the authors make the next revision terser or do you want me to propose text changes? I would also suggest that you reference the sections in rfc1958 on state. we don't have a good success record in gleaning state in the middle of the network (NAT, N:1 VLANs, DHCP...), since the protocols we 'glean' from aren't designed to maintain softstate in the network. I see no reason why this document shouldn't be adopted as a working group document immediately. I support this becoming a WG document, and agree with Ole that the next version should cut back on text. We want to give the IESG something as clear and concise as possible. If there is reasonable consensus (not that the document is complete, but that it will be the basis for the final document), all it takes is an OK by the chairs and a submission by the authors with the WG title. - Mark cheers, Ole ___ 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
Re: [Softwires] Motivation draft for stateless v4 over v6 solution
Dear Ole, For sure, the text can be shortened whenever possible. If you point me to sections you think it need to be re-worded, this would be appreciated. Thank you. Cheers, Med -Message d'origine- De : Ole Troan [mailto:ichiroumak...@gmail.com] De la part de Ole Troan Envoyé : jeudi 26 mai 2011 10:36 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Rémi Després; Satoru Matsushima; Yiu Lee; Olaf Bonness; Isabel Borges; Softwires-wg Objet : Re: [Softwires] Motivation draft for stateless v4 over v6 solution I like the draft and I think it covers the motivational points well. as a general comment, I do think the document is too wordy. could the authors make the next revision terser or do you want me to propose text changes? I would also suggest that you reference the sections in rfc1958 on state. we don't have a good success record in gleaning state in the middle of the network (NAT, N:1 VLANs, DHCP...), since the protocols we 'glean' from aren't designed to maintain softstate in the network. I see no reason why this document shouldn't be adopted as a working group document immediately. cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Motivation draft for stateless v4 over v6 solution
On May 26, 2011, at 10:36 AM, Ole Troan wrote: I like the draft and I think it covers the motivational points well. as a general comment, I do think the document is too wordy. could the authors make the next revision terser or do you want me to propose text changes? I would also suggest that you reference the sections in rfc1958 on state. we don't have a good success record in gleaning state in the middle of the network (NAT, N:1 VLANs, DHCP...), since the protocols we 'glean' from aren't designed to maintain softstate in the network. I see no reason why this document shouldn't be adopted as a working group document immediately. I support this becoming a WG document, and agree with Ole that the next version should cut back on text. We want to give the IESG something as clear and concise as possible. If there is reasonable consensus (not that the document is complete, but that it will be the basis for the final document), all it takes is an OK by the chairs and a submission by the authors with the WG title. You mean after merging with draft-chen-softwire-4v6-motivation-00.txt? then +1 from me. Behcet ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Motivation draft for stateless v4 over v6 solution
Remi-san has simply pointed out that the service use case section of the draft assumes same implication in the ds-lite draft. I think that it would be no problem, and better to just remove the use case section, because the draft already expressed it as target space table in the introduction. Best regards, --satoru On 2011/05/10, at 14:57, mohamed.boucad...@orange-ftgroup.com wrote: Hi Rémi, I understand your point but, and speaking as individual author of the draft, my organization does not recommend for the mobile context for instance any transition solution requiring specific functions in the host (this is also the position of the 3GPP IPv6 SI). The main reason is, unlike the CPE case, we don't control the host. Cheers, Med -Message d'origine- De : Rémi Després [mailto:remi.desp...@free.fr] Envoyé : lundi 9 mai 2011 18:37 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Satoru Matsushima; Yiu Lee; Olaf Bonness; Isabel Borges; Softwires-wg Objet : Re: [Softwires] Motivation draft for stateless v4 over v6 solution Le 9 mai 2011 à 15:37, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : ... Med: For the sake of easing the readability of the document, I added Within this document port set and port range are used interchangeably. instead of repeating each time both terms. Port set throughout would IMHO have been better, but what you added is good enough. Thanks. 2. Sec 3. IPv4 Service Use case While the Host based model is out of scope, it would be IMHO good to note that: The model can however apply to any host that includes a CPE function. Med: I prefer having the explicit statement to say the host-based model is out of scope. Same view. The intended proposal wasn't to delete this sentence (sorry if it wasn't clear enough). It is just to add the new sentence after it. Med: One can consider a host embedding a CPE function as a router, no? Some clarification may be needed for a common understanding. In the DS-lite draft, we have, concerning the host-based architecture: This architecture is targeted at new, large scale deployments of dual-stack capable devices implementing a dual-stack lite interface. I don't see why the stateless solution couldn't have a host-based variant targeted at new, large scale deployments of dual-stack capable devices implementing the CPE router function. Just saying host-based models are out of scope seems to me more negative than needed. The host-based DS-lite architecture is illustrated by: +---+ | | | Host 192.0.0.2 | |+++| ||B4 || |+++| +|||+ |||2001:db8:0:1::1 ||| |||-IPv4-in-IPv6 softwire ||| ---|||--- /|||\ | ISP core network | \|||/ ---|||--- ||| |||2001:db8:0:2::1 +|||+ | AFTR| |+++| || Concentrator || |+++| | |NAT| | | +-+-+ | +-|-+ |192.0.2.1 | | / | \ | Internet | \ | / | | |198.51.100.1 +-+-+ | IPv4 Host | +---+ The host-based stateless-IPv4/IPv6 architecture can similarly be illustrated by. +---+ | Host| | RFC 1918 address | |+++| || Stateless v4/v6 || || CPE function || || (incl. NAPT44) || |+++| +|||+ |||2001:db8:0:1::1 ||| |||-IPv4-in-IPv6 stateless ||| ---|||--- /|||\ | ISP core network | \|||/ ---|||--- ||| |||2001:db8:0:2::1 +|||+ | Stateless | |IPv4/IPv6 | | interconnection | | function
Re: [Softwires] Motivation draft for stateless v4 over v6 solution
Re-, Just to confirm it, only 4-4 and 6-6 are covered, no 4-6, right? Cheers, Jacni On Tue, May 10, 2011 at 2:27 PM, Satoru Matsushima satoru.matsush...@gmail.com wrote: Remi-san has simply pointed out that the service use case section of the draft assumes same implication in the ds-lite draft. I think that it would be no problem, and better to just remove the use case section, because the draft already expressed it as target space table in the introduction. Best regards, --satoru ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
