2012/6/11, Rémi Després <[email protected]>: > > Le 2012-06-11 à 09:32, liu dapeng a écrit : > >> Hello Med, >> >> Yes, we are almost converged on this final update. >> >> As you said here, there still need port translation in the host, that >> still state in the host. > > Note that these states are "per-connection", not "per customer". > Even a host without NAT has to maintain per-connection states for its > sockets.
The state you mentioned here is for application, but we are talking about state on the network layer, they are different. I don't see why we resist on clarifying and helping reader better understanding. Besides, I guess the state referred in this document is not specific to either "per-connection" or "per customer" . AFTR also hold a "per-connection" state, which is treated as a stateful in the document. Best Regards, Dapeng Liu > In this respect, the draft is I think acceptable, and hopefully can now > proceed quickly. > > Regards, > RD > > >> we need clarify that in this document for >> other readers. >> >> Best Regards, >> Dapeng Liu >> 2012/6/11, [email protected] <[email protected]>: >>> Re-, >>> >>> I was answering to your last proposed wording to include the port >>> translation in the host. Except that change, all your proposed changes >>> are >>> included in my local copy: >>> >>> * The title has been updated as your requested >>> * The introduction has been updated. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : liu dapeng [mailto:[email protected]] >>>> Envoyé : lundi 11 juin 2012 09:11 >>>> À : BOUCADAIR Mohamed OLNC/NAD/TIP >>>> Cc : Yong Cui; [email protected] >>>> Objet : Re: [Softwires] WG last call on >>>> draft-ietf-softwire-stateless-4v6-motivation-01 >>>> >>>> Hi Med, >>>> >>>> "end to end argument" is different from" stateful/stateless" >>>> principally, >>>> "end to end argument" recommend state in the end point(host), >>>> but it doesn't say >>>> it is stateless, it is still stateful. >>>> >>>> Based on this, I still believe that we need update the current >>>> document with the last comment. >>>> >>>> Regards, >>>> Dapeng Liu >>>> 2012/6/11, liu dapeng <[email protected]>: >>>>> Hi Med: >>>>> >>>>> 2012/6/8, [email protected] >>>> <[email protected]>: >>>>>> Dear Dapeng, >>>>>> >>>>>> Please see inline. >>>>>> >>>>>> Cheers, >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : liu dapeng [mailto:[email protected]] >>>>>>> Envoyé : vendredi 8 juin 2012 13:49 >>>>>>> À : BOUCADAIR Mohamed OLNC/NAD/TIP >>>>>>> Cc : Yong Cui; [email protected] >>>>>>> Objet : Re: [Softwires] WG last call on >>>>>>> draft-ietf-softwire-stateless-4v6-motivation-01 >>>>>>> >>>>>>>> >>>>>>>> Med: We have already this text in the introduction: >>>>>>>> >>>>>>>> Current standardization effort that is meant to >>>> address this IPv4 >>>>>>>> service continuity issue focuses mainly on stateful >>>>>>> mechanisms that >>>>>>>> assume the sharing of any global IPv4 address that is >>>> left between >>>>>>>> several customers, based upon the deployment of NAT >>>>>>> (Network Address >>>>>>>> Translation) capabilities in the network. Because of >>>>>>> some caveats of >>>>>>>> such stateful approaches the Service Provider community >>>>>>> feels that a >>>>>>>> companion effort is required to specify stateless IPv4 >>>> over IPv6 >>>>>>>> approaches. This document provides elaboration on such need. >>>>>>>> >>>>>>>> Isn't this text sufficient enough? If not, it would helpful >>>>>>> to propose a >>>>>>>> sentence you want to be added to the introduction. >>>>>>> >>>>>>> How about adding the following sentences: >>>>>>> >>>>>>> ------- >>>>>>> In many networks today, NAT44 functions is equipped on >>>>>>> customer-edge device. >>>>>>> It may impact IPv4 over IPv6 solution to be a stateful solution from >>>>>>> end-to-end perspectives. The stateless solution also may subject to >>>>>>> NAT44 state. >>>>>>> In this document, we mainly refer this stateless paradigm to >>>>>>> large-scale address Sharing, i.e. carrier-side stateless IPv4 over >>>>>>> IPv6, which resolve the concern of "stateless" terminology. This >>>>>>> document provides elaboration on such need. >>>>>>> ------- >>>>>>> >>>>>> >>>>>> Med: Thanks for the proposal. I shortened your proposal and >>>> updated the >>>>>> text >>>>>> to: >>>>>> >>>>>> >>>>>> Current standardization effort that is meant to address this IPv4 >>>>>> service continuity issue focuses mainly on stateful >>>> mechanisms that >>>>>> assume the sharing of any global IPv4 address that is >>>> left between >>>>>> several customers, based upon the deployment of NAT >>>> (Network Address >>>>>> Translation) capabilities in the network. Because of >>>> some caveats of >>>>>> such stateful approaches the Service Provider community >>>> feels that a >>>>>> companion effort is required to specify stateless IPv4 over IPv6 >>>>>> approaches. Note stateless IPv4 over IPv6 solutions may >>>> be enabled >>>>>> in conjunction with a port-restricted NAT44 function >>>> located in the >>>>>> customer premises. >>>>>> >>>>>> This document provides elaboration on the need for carrier-side >>>>>> stateless IPv4 over IPv6 solution. >>>>>> >>>>>> >>>>>> Are you OK with this new text? >>>>> >>>>> [Dapeng]==> >>>>> I make a minor change of the last two sentences: >>>>> --------- >>>>> Because of some caveats of such stateful approaches the Service >>>>> Provider community feels that a companion effort is required to >>>>> specify carrier-side stateless IPv4 over IPv6 approaches. Note >>>>> carrier-side stateless IPv4 over IPv6 solutions may be enabled in >>>>> conjunction with a port-restricted NAT44 function located in the >>>>> customer premises or port translation in the host and that is still >>>>> stateful in the whole. >>>>> --------- >>>>> >>>>> Besides, how about changing all the terminology "stateless" to >>>>> "carrier-side stateless" in the document? >>>>> >>>>> >>>>> Thanks, >>>>> Best Regards, >>>>> Dapeng Liu >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> ------ >>>>> Best Regards, >>>>> Dapeng Liu >>>>> >>>> >>>> >>>> -- >>>> >>>> ------ >>>> Best Regards, >>>> Dapeng Liu >>>> >> >> >> -- >> >> ------ >> Best Regards, >> Dapeng Liu >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires > -- ------ Best Regards, Dapeng Liu _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
